|
|
Users who have roaming user profiles can use these profiles in a mixed environment to log on to both Windows NT 4.0 and Windows 2000. Both operating systems can read and use the same user profile. If you need to use the roaming profile in a mixed environment, proceed as follows:
Create an account for the administrative user on the Windows 2000 Server computer (use Active Directory Users and Computers for this purpose). This user will be the administrator of the user profiles. Also create the shared directory for storing user profiles.
Create a new user account for the roaming user, then open the User Properties window. Go to the Profiles tab and specify the path to the user profile in the following format: \\server name\share name\%user name%, where server name is the name of the server, share name is the name of the shared folder where you intend to store user profiles, and user name is the name of the roaming user.
From the Start menu, select Settings | Control Panel, and launch the System applet.
Go to the User Profiles tab (Fig. 10.5), select the existing local user profile, and click the Copy To button.
Fig. 10.5: The User Profiles tab of the System Properties window
The Copy To window will open (Fig. 10.6). Enter the path to the shared user profile folder into the Copy profile to field. Specify the path using the UNC (Universal Naming Convention) format (for example: \\server name\share name\user profile folder). If the folder doesn't exist, it will be created.
Fig. 10.6: The Copy To window
Select a user whom you'll allow to work with this profile. To copy the profile, click OK. You'll return to the System Properties window. Click OK to confirm the changes.
Logon to the network from the client workstation. From the Start menu, select Settings | Control Panel, then launch the System applet and go to the User Profiles tab. The profile type for the user whom you've assigned the roaming profile will change to Roaming.
Note | Starting with Windows 2000, standard access rights to the roaming profiles have changed in comparison to those in Windows NT 4.0. For example, administrators no longer have Full Control access to all user profiles. Consequently, if an administrator needs access to the contents of the user profile, he'll need to take ownership for the appropriate file system objects (if the user profiles are stored on the NTFS partition). He'll also need to take ownership for the respective registry hives. From a security point of view, this is a wise thing to do, because the operation of taking ownership is an event that can be audited. |
Windows XP introduces several enhancements to the user settings management, including more reliable roaming, improved user profile merge algorithm and several new group policy settings. Let us consider these enhancements in more detail.
First of all, user profile policies in Windows XP have their own node in Group Policy Editor (Fig. 10.7). Furthermore, there are three new policies. To view these policies, proceed as follows:
Click Start, click Run, type mmc, and then click OK.
From the File menu, select the Add/Remove Snap-in command, go to the Standalone tab and click Add.
From the Available Standalone Snap-ins list, select the Group Policy option and then click the Add button. When the Select Group Policy object window opens, select the Local Computer option to edit the local Group Policy object, or click Browse to find the Group Policy object that you want.
Click Finish, then Close, then OK. The Group Policy snap-in opens the Group Policy object for editing. Expand the console tree in the left pane of this window as follows: Computer Configuration | Administrative Templates | System | User Profiles (Fig. 10.7).
Fig. 10.7: User Profile Policies have their own node in Group Policy Editor
The three new policies that have been added with Windows XP are the last ones in the list of the available policies in the right pane of the Group Policy window:
Prevent Roaming Profile Changes From Propagating to the server. As its name implies, this policy specifies whether the changes made by the users to their roaming profiles are merged with the copies of their roaming profiles stored on the server. If you set this policy, the users at login will receive the copies of their roaming profiles, but the changes they introduce will not be merged to their roaming profiles.
Add the Administrator security group to the roaming user profile share. As was aforementioned, starting with Windows 2000, the default permissions for newly created roaming profiles provide full control permissions for the user, and no access to the Administrators group. If you want to reset this behavior in a way compatible to Windows NT 4.0, where the Administrators group has full control of the user's profile directories, you should set this policy.
Do Not Allow users to change profile type. Allows an administrator to control whether a user is allowed to change their profile type from a Roaming Profile to a Local profile.
Besides new policies, Windows XP provides other improvements to roaming profiles management. For example, in Windows 2000 there may be situations, when applications and services keep registry keys open during logoff. This prevents Windows from unloading the user's registry hive and saving the user profiles modifications to the server. As a result, such "locked" user profiles never get unloaded, and take up a large amount of memory on a server that has many users logging on. If such a profile is marked for deletion at logoff in order to clean up the disk space on the server, it also never gets deleted. In Windows XP this problem was not an issue. Now Windows saves the user's registry hive at the end of the 60-second delay and roams the profile correctly. In contrast to Windows 2000, when the application or service closes the registry key that locks the user profile, Windows XP unloads the hive and frees the memory consumed by the user profile. In cases where the application or service never releases the registry key, Windows XP will delete all profiles marked for deletion at the next reboot. |
The way the users get their profiles depends on the profile type configured for them. Let us consider this process in more detail. For local profiles the procedure comprises the following steps:
The user logs on. The operating system checks the list of user profiles located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList (Fig. 10.8) to determine if a local profile exists for the user. If an entry exists, then this local profile is used. If a local profile is not found, and the computer is part of a domain, the operating system checks if a domain-wide default profile exists (it must be located on the domain controller's NETLOGON share in a folder named Default User). If a default domain-wide user profile exists, it will be copied to the following subfolder on the local computer: %SystemDrive%\Documents and Settings\Username. If a default domain-wide user profile does not exist, then the local default profile is copied from the %Systemdrive%\Documents and Settings\Default User folder to the %SystemDrive%\Documents and Settings\Username subfolder on the local computer.
Fig. 10.8: The list of user profiles is stored in the registry under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList key
The user's registry hive (NTUser.dat) is mapped to the HKEY_CURRENT_USER portion of the registry.
When the user logs off, a profile is saved to the local hard disk of the computer.
For roaming profiles this process is as follows:
The user logs on, and Windows checks the list of user profiles stored in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList key to determine if a cached copy of the profile exists. If a local copy of the profile is not found, and the computer is part of a domain, Windows checks to determine if a domain-wide default profile exists in the Default User folder on the domain controller's NETLOGON share. If a default domain-wide user profile exists, it will be copied to the following subfolder on the local computer: %SystemDrive%\Documents and Settings\Username. If a default domain-wide user profile does not exist, then the local default profile is copied from the %Systemdrive%\Documents and Settings\Default User folder to the %SystemDrive%\Documents and Settings\Username subfolder on the local computer.
The user's registry hive (Ntuser.dat) is copied to the local cached copy of their user profile, and is mapped to the HKEY_CURRENT_USER portion of the registry. The contents of the local cached profile are compared with the copy of the profile on the server, and the two profiles are merged.
The user can then run applications and edit documents as normal. When the user logs off, their local profile is copied to the path configured by the administrator. If a profile already exists on the server, the local profile is merged with the server copy.
In Windows NT 4.0, the merge algorithm was based on the Xcopy command with full synchronization support. That means, that there is only one master copy of the profile at any given time. When the user is logged on, the master profile is on the local computer, and when the user is not logged on, the master copy of his or her profile is on the server. This algorithm works fine in most cases, where a user logs on to only a single computer. However, a user who logs on to multiple computers at the same time might experience unexpected behavior. Windows XP eliminates this problem by introducing the profile merging at the file level. When a document or file is updated, the new algorithm compares the timestamp of the destination file with the timestamp of the source file. If the destination file is newer, it is not overwritten. |
As was mentioned earlier, roaming user profiles are copied from the server to the client when the user logs on, and copied back when the user logs off. However, Windows 2000/XP includes the per-user Local Settings folder within the user profile that is not copied during log on or log off sessions. Operating system components and other applications can store non-roaming per-user data in this folder. On the other hand, the IntelliMirror technology includes the Folder Redirection feature that allows administrators to redirect the location of specific user profile folders to a network location (from the user's point of view, this looks just like roaming, but in this case the user settings actually remain on the network share). Folder redirection can be used with all types of profiles, including local, roaming, or mandatory. Combining Folder Redirection with roaming profiles allows you to get all the benefits of roaming profiles and at the same time to minimize network traffic.
Table 10.3. lists the folders that roam with the profile by default, and indicates whether they can be redirected using Group Policy.
Folder Name | Description | Roams with Profile by default | Redirect with Group Policy |
---|---|---|---|
| |||
Application Data | Per-user roaming application data | Yes | Yes |
Cookies | User's Internet Explorer cookies | Yes | No |
Desktop | Yes | Yes | |
Favorites | User's Internet Explorer favorites | Yes | No |
Local Settings | Temporary files and per-user non-roaming application data | No | No |
My Documents | User's documents | Yes | Yes |
NetHood | Yes | No | |
PrintHood | Yes | No | |
Recent | Shortcuts to recently used documents | Yes | No |
Send To | Yes | No | |
Start Menu | User's personal start menu | Yes | Yes |
Templates | Per-user customized templates | Yes | No |
|
|