Microsoft Windows Registry Guide, Second Edition

Using Roaming User Profiles

You configure roaming user profiles on the server, so the user must be a member of and log on to the domain to use a roaming user profile. Both Microsoft Windows NT Server 4.0 and Microsoft Windows 2000 Server support roaming user profiles, as do Microsoft Windows XP and Windows Server 2003. The following instructions show you how to configure roaming user profiles in Active Directory on Windows Server 2003:

  1. Create a folder on the server where you want to store user profiles. This is the top-level folder that will contain individual user profile folders.

  2. Share the folder, giving all users full control. (I sometimes reduce users' permissions to read and execute in this folder and then give them full control of their individual profile folders.)

  3. In the Active Directory Users and Computers console, double-click the account that you want to configure to use a roaming user profile.

  4. On the Profile tab of the Name Properties dialog box, shown in Figure 12-4, type the path where you want to store the user's profile in the Profile Path text box. The path is \\Server\Share\ Username, where Server is the name of the server, Share is the share you created in step 2, and Username is the name of the account. Optionally, use %UserName% for Username, and Active Directory will automatically substitute the current account's name in its place.

If you want to configure a lot of accounts to use roaming user profiles, doing the job by hand is a monumental task. Instead, use a third-party tool or write an Active Directory Scripting Interface (ADSI) script to do the job. You access ADSI through Windows Script Host using Microsoft Visual Basic Scripting Edition (VBScript) or JScript.

More Info

This subject is beyond the scope of this book, but you can find more information about ADSI scripting at http://www.microsoft.com/resources/documentation/windows/2000/server/scriptguide/en-us/sas_ads_overview.mspx.

Figure 12-4 Typing a path in the Profile Path box is all that it takes to enable roaming user profiles.

Folder Redirection is a great complement to user profiles, particularly the roaming variety. It enables an IT professional to redirect the location of some profile folders to the network. There's nothing magical about Folder Redirection. Group Policy simply changes the folder's location in the User Shell Folders key so that applications automatically look for the folder on the network. From users' perspectives, redirected folders are similar to roaming user profiles because their documents follow them from computer to computer. Unlike roaming user profiles, however, redirected folders always remain in the same place. You can use redirected folders with or without roaming user profiles. If you use them with roaming user profiles, you can reduce the amount of data that Windows transfers when users log on to and off from the operating system. Furthermore, redirected folders are often useful even when you don't intend to use roaming user profiles; you can allow users' documents to follow them without the complexity and sometimes difficulty of using roaming user profiles. You learn about roaming user profiles in the earlier section “Getting User Profiles.” Table 12-3 indicates for each profile folder whether the folder can roam and whether you can redirect it.

Table 12-3 Roaming and Redirecting Folders

Folder

Can Roam?

Can Redirect?

Application Data

Yes

Yes

Cookies

Yes

No

Desktop

Yes

Yes

Favorites

Yes

No

Local Settings

No

No

My Documents

Yes

Yes

My Recent Documents

Yes

No

NetHood

Yes

No

PrintHood

Yes

No

SendTo

Yes

No

Start Menu

Yes

Yes

Templates

Yes

No

Best Practices for Roaming User Profiles

The following are best practices for roaming user profiles:

More Info

You can get a detailed explanation of loopback processing at http://support.microsoft.com/default.aspx?scid=kb;en-us;231287.

Managing Roaming User Profiles

Group Policy provides a number of policies that you can use to manage how Windows handles user profiles. You can configure these policies in a local Group Policy Object (GPO) or in a network GPO. Chapter 7, “Using Registry-Based Policy,” gives more information. For now, here's a description of policies for user profiles:

The first three policies in this list are per-user and the remaining are per-computer policies; Figure 12-5 shows them in Group Policy Editor. All of the policies are administrative policies in System\User Profiles under User Configuration and Computer Configuration.

Figure 12-5 These policies give you management control of how Windows uses profiles.

Understanding Fast Network Logon

Windows doesn't wait for the network to start before displaying the Logon To Windows dialog box. This substantially improves start time over Windows 2000. Users who've previously logged on to the computer get to their desktops faster because the operating system uses cached credentials and loads Group Policy in the background after the network becomes available. Although fast network logon improves perceived performance, it has effects that you should understand. The most important fact to understand in this section is that Windows doesn't use fast network logon if you use roaming user profiles.

Because background refresh is the default behavior, users might have to log on to Windows up to three times for Group Policy extensions such as Software Installation and Folder Redirection to take effect. Windows must process these types of extensions in the background without any users logged on to it. Also, because advanced Folder Redirection is based on group membership, users must log on to Windows three times: once to update the cached user object and group membership, a second time to detect the change in group membership and require a foreground policy application, and a third time to apply folder redirection policy in the foreground. The operating system might require users to log on two times to update the properties of other Group Policy objects.

Another thing to keep in mind is the effect that fast network logon has on Windows when users' profiles change from local to roaming. When the operating system uses fast network logon, it always uses the locally cached copy of the profile. By the time the operating system detects that the user has a roaming user profile, it's already loaded the local profile hive and changed its time stamp. The result is that if users log on to multiple computers, the operating system can replace newer profile hives with older ones. To handle this scenario, Windows treats the change from local to roaming as a special case. First the operating system checks the following conditions:

If both these conditions are true, then Windows merges the contents of the local user profile with the server copy, without the profile hive NTUSER.DAT. Then the operating system copies the server copy of the profile to the local copy, regardless of the profile hives' time stamps. After the user's profile becomes a roaming profile, Windows always waits for the network so that it can download the user profile. In other words, fast network logon and roaming user profiles don't work together.

CAUTION

Considering the changes that Windows makes to roaming user profiles, if you remove the roaming profile path from a user in Active Directory, you should remove the profile folder from the server. If you reconfigure the user to use roaming user profiles and you use the same path, the user will receive the older server copy of the user profile.

Understanding the New Merge

Many IT professionals are reluctant to use roaming user profiles because they have experience with the merge algorithm that Windows NT 4.0 uses. That algorithm assumes that there is a single master copy of the user profile. When the user logs on to the computer, the operating system assumes that the master profile is on the local computer, and when the user logs off the computer, it assumes that the master profile is on the server. It mirrors the entire profile from the local computer to the server and vice versa, completely replacing the profile at the target location. This works perfectly well when people use a single computer, but it creates havoc when they use multiple computers.

The merge algorithm in Windows is more advanced; it merges user profiles at the file level. In other words, it's a real merge, not a wipe-and-load. The merged profile then becomes a superset of the files in the local and server copies of the user profile, and when a file exists in both copies, the operating system uses the most recent version of the file. New files don't turn up missing, and updated files are not replaced–both of which are symptoms that occur with the merge algorithm in Windows NT 4.0. In the case of the Windows NT 4.0 merge, if a profile changes on two computers, only the last profile copied to the network persists.

Behind the new and improved merge algorithm is the time stamp that Windows saves in the ProfileList key. When a user logs on to the computer, the operating system saves the current time in ProfileList. When the user logs off the computer, the operating system uses the time stamp to determine which files have been added or removed from the server's copy of the user profile. For example, if a file named Example.doc is in the server copy of the user profile but not in the local copy, the time stamp helps Windows determine whether the file was added to the server copy or removed from the local copy. If the time stamp of the file is later than the time stamp of the local user profile, the file was added to the server copy. The result is that Windows doesn't touch the file when it merges the local profile into the server copy. If the time stamp of the file is earlier than the time stamp of the local user profile, the file was removed from the local user profile. The result is that Windows removes the file from the server copy of the profile when the operating system merges the local copy into it. With Windows, if a profile changes on two computers, both of them are merged file by file into the server copy.

NOTE

There is another issue that keeps many IT professionals from using roaming user profiles. Roaming user profiles are terrific when configurations are similar from desktop to desktop. When users log on to different computers with different sets of applications, screen sizes, power management requirements, and so on, roaming user profiles are cumbersome and users' experiences aren't very good. Roaming user profiles are great in scenarios such as call centers and other environments in which configurations are standardized, but they are not very useful when configurations are not standardized in an organization.

Категории