Enhancements to User Profiles in Windows Server 2003 and Windows XP
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
User data management and user settings management features provide several enhancements that increase the usability, resilience, and performance of user profiles:
New Group Policy settings
Support for Windows XP fast network logon
New System Service profiles
More robust roaming
New Group Policy Settings
User profiles policies have moved to their own node in the Group Policy Object Editor: Administrative Templates\ System\User Profiles. In addition there are three new policies under computer policies:
Prevent Roaming Profile Changes from Propagating to the server. This policy determines if the changes a user makes to their roaming profile are merged with the server copy of their profile. If this policy is set at login, the user will receive their Roaming Profile, but any changes a user makes to their profile will not be merged to their roaming profile at logoff.
Add the Administrator security group to the roaming user profile share. In Windows 2000, the default file permissions for newly generated roaming profiles are full control, or read and write access for the user, and no file access for the administrators group. This policy allows an administrator to choose the same behavior as Windows NT 4.0, and have the administrators group given full control of the user's profile directories.
Only allow local user profiles. This setting determines if roaming user profiles are available on a particular computer. By default, when roaming profile users log on to a computer, their roaming profile is copied down to the local computer. Using this setting, an administrator can prevent users configured to use roaming profiles from receiving their roaming profile on a specific computer.
Support for fast network logon
Fast network logon overview
Windows XP includes new features that provide faster start up of a computer by not waiting for the network during boot and logon.
By default, Windows XP (but not Windows Server 2003) does not wait for the network to be fully initialized at startup and logon. Any existing users logging on are logged on using cached credentials, which results in shorter logon times. Because the computer doesn't wait for the network to be fully started, Group Policy is applied in the background once the network becomes available. This has a number of effects on the logon process:
Changes to some Group Policy extensions can take up to three logons to become effective. Because background refresh becomes the default behavior, some policy extensions such as Software Installation and Folder Redirection may require as many as three logons to apply changes. This is because to be able to operate safely, these extensions require that no users be logged on, so they must be processed in the foreground before users are actively using the computer. In the case of Advanced folder redirection, because policy is evaluated based on security group membership three logons will be required: the first logon to update the cached user object (and security group membership), the second logon for policy to detect the change in security group membership and require a foreground policy application, and the third logon to actually apply folder redirection policy in the foreground.
Changes to some user object properties may take two logons to become effective. Because users are logged on using cached credentials, changes that are made to the user object, such as adding a roaming profile path, home directory, or user object logon script, may take up to two logons to be detected. The user object is updated in the background after the user has logged on, so any changes to its properties will not take effect until the next logon at least. Certain key fields in the user object are also checked at logoff, so if the user is logged on at the time of the change, the change may be detected at logoff.
Changes in roaming user profiles to support fast network logon
When a user logs onto a computer they have not logged onto for some time, the timestamps of the local user registry hives are compared to the server registry hive and the newest wins. Typically this is the server copy of the registry, as the timestamps are checked before the hive is loaded.
However, when Windows XP is operating in fast network logon mode, the user is always logged on with a cached profile. The effect of this is that when the system detects that the user is now a roaming user, the local registry hive has already been loaded and therefore the hive timestamp is always changed. This introduces the possibility that if a user logs onto multiple computers, an older profile can overwrite a newer server profile because the users roaming status is one step behind (due to the cached logon). To avoid this situation, the roaming profile algorithm treats the transition from local to roaming on a given computer as a special case:
At logon, checks are made to see which of the following conditions are true:
Is this is the first roaming logon for a user that previously had a local profile?
Is there a server copy of the users profile?
If all of these conditions are met, then the algorithm is subtly changed, the new algorithm does the following:
The contents of the local profile are merged with the server copy of the profile as normal, with the exception of the user registry hive (ntuser.dat).
The server copy of the user registry is always copied from the server profile to the local profile, regardless of the time stamps on the hives.
In all other cases, the algorithm remains unchanged. Its only the first time that a user becomes roaming on a specific computer that this check is made. Once the user has become a roaming user, the computer always waits for the network (so that the profile can be downloaded) and the behavior is exactly the same as Windows 2000.
With this change, it is recommended that if an administrator removes the profile path from a users user object, that they either rename or delete the corresponding profile folder. If the profile folder is not removed, and the administrator re-adds the same profile path, the user will receive the older server copy of their registry.
New System Service profiles
Windows XP and Windows Server 2003 introduce three new user profiles for the System:
LocalService and NetworkService profiles
The LocalService and NetworkService profiles are automatically created for two new built in user accounts that are used by the Service Control Manager to host services that do not need to run as the local system account. While these two new profiles are normal user profiles, because they are required by the system to run, they are treated slightly differently:
LocalService and NetworkService profiles are not shown in the profiles list on the system properties dialog.
Both LocalService and NetworkService profiles are located in %systemroot%\Documents and Settings by default, but are marked as super hidden so that they are not ordinarily visible.
In Windows 2000, when an application or service used the LoadUserProfile API to load a user profile for a process running as the local system, Windows created a profile named %computername%$ , where %computername% is the name of the local computer. This could cause problems for some applications and services, because depending on whether the system profile was loaded, HKEY_CURRENT_USER could in fact resolve to different registries either HKEY_USERS \S-1-5-18 or HKEY_USERS\.DEFAULT depending on whether another component has loaded the SYSTEM profile.
To avoid this, Windows Server 2003 and Windows XP create a new profile for the system, located in %systemroot%\System32\Config\SystemProfile. This profile is always loaded, and is a link to HKEY_USERS\.DEFAULT. This ensures that system components always have a consistent profile and registry.
More robust roaming
In Windows 2000, an issue exists whereby poorly written applications and services that keep registry keys open during logoff prevent Windows from unloading the user's registry hive. When this occurs, changes that a user has made to their profile are not saved to the server. This has three symptoms:
The user experience is impacted, as users may wonder why changes have not been saved when they log onto another computer.
Since "locked" profiles never get unloaded, they end up using a lot of memory on a terminal server that has many users logging in.
If a profile is marked for deletion at logoff (to cleanup the machine or for temporary profiles), profiles do not get deleted.
The three symptoms are solved as follows:
In Windows 2000 when a user logs off, if the profile is "locked", Windows polls the profile for 60-seconds before giving up. Windows Server 2003 and Windows XP now save the users registry hive at the end of the 60-second delay, and roam the profile correctly.
When the application or service closes the registry key "unlocking" the profile, Windows Server 2003 or Windows XP will unload the users registry, thus freeing the memory consumed by the profile.
If a profile is marked for deletion at logoff, when the reference count drops to zero, it will be unloaded and deleted. In the event that the application never releases the registry key, Windows Server 2003 or Windows XP will delete all profiles marked for deletion at the next machine boot.
Note that if a roaming user logs onto back onto a machine that failed to unload her profile previously, and the profile has still not unloaded, the user will receive the currently loaded profile. If the user has logged onto another computer in the meantime, and made changes to their profile, the changes will not be available on the machine with the locked profile.
Improved Merge Algorithm
This section describes how Windows Server 2003 or Windows XP reconciles local and server copies of a users profile. To improve the experience of users, roaming profiles have a new algorithm to synchronize copies of a profile. This prevents problems from occurring when a user logs into two different computers simultaneously. The Windows NT 4.0 algorithm worked well in the most common cases where users logged on to only a single computer. However, when a user logged onto multiple computers at the same time, the user sometimes experienced unexpected behavior caused by the assumption that each computer had the master copy of the profile.
For Windows Server 2003, Windows XP, and Windows 2000, the algorithm was changed to support the merging of user profiles at the file level and to provide support for last writer wins.
To illustrate the behavior of the new algorithm, several examples are presented that compare the behavior of Windows NT 4.0 to the current model.
Overview of the Windows NT 4.0 Algorithm
In Windows NT 4.0, the algorithm is an Xcopy with full synchronization support, meaning it has the ability to mirror a profile from one location to another, and any extra files or directories in the destination location are removed. The algorithm is based on the concept that there is only one master profile at any one time. When the user is logged on, the master profile is on the local computer. When the user is not logged on, the master profile is on the server.
The user logs on to computer A, the primary computer.
The roaming profile is Xcopied from the server location to the local profile location.
The user creates documents, changes colors, and so on. All of these changes are stored in the local profile location.
As the user logs off the computer, the profile is Xcopied from the local profile location back to the server location.
This is an exact mirroring process. If there are any extra files in the server location, they are deleted to ensure that the server location is a duplicate of the local profile. As mentioned previously, this works well in the majority of cases, where a user logs on to only a single computer; but a user who logs on to multiple computers at the same time might experience unexpected behavior.
Examples of Windows NT 4.0 Merge Algorithm Issues
When using Windows NT 4.0, a problem arises if the user logs on at two or more computers. Building on the preceding example:
The user logs on to computer A.
The user logs on to computer B.
The user creates a document on computer A and stores it in the user profile.
The user logs off of computer A.
The user logs off of computer B.
The document that the user created in step 3 is deleted because, from the perspective of computer B, the master profile is stored locally. The extra files on the server must be deleted so that the local profile is currently the master server profile.
The Windows XP algorithm preserves the document because it is able to compare the time the document was created with the time the profile was loaded. If the document was created or modified after the profile load time, the file must be preserved because it came from a different source.
A similar problem can occur when files are modified. For example, suppose that the user has a document called Document.doc in his or her My Documents folder in the server copy of the profile:
The user logs on to computer A.
The user logs on to computer B.
The user modifies the document on computer A.
The user logs off computer A.
The user logs off computer B.
The changes made to the document on computer A are lost because when the user logged off computer B, the computer overwrote the new version of the document with the old one; the computer is programmed to recognize that it had the master version of the profile.
The current algorithm preserves the changes to the document because it compares the time the document was modified with the time the profile was loaded. This results in a much better experience for the user.
Overview of Windows Server 2003 Merge Algorithm
Windows Server 2003 and Windows XP merge user profiles at the file level. The merged profile contains the superset of files that are in the local computer and server copies of the users profile. In the case where the same file is in both the local and server copy of the profile, the file that was modified most recently is used. This means that new files are not deleted, and updated versions of existing files are not overwritten.
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.
When a user logs on to a computer, the current time is saved; when the user logs off, this timestamp is used to determine which files are new in the server profile and which files have been deleted in the local profile. For example, if the server profile has a document in the My Documents folder called Review.doc and this file does not exist in the local profile, either it is a new file from a different computer, or it was originally in the local profile and the user deleted it. Knowing the time when this new profile was loaded, it is possible to compare it against the timestamp of Review.doc. If Review.doc was created or written to after the profile load time, the file must be preserved because it came from a different source. If the Review.doc timestamp is older than the profile load time, Review.doc must be deleted because it would have been copied to the local computer at load time.
In addition, some files might need to be removed from the local cache so that items that were deleted between sessions remain deleted. For example:
The user logs on to computer A.
The user creates or modifies a document on computer A.
The user logs on to computer B.
The user logs off computer B; computer B has a copy of the document.
The user deletes the document and logs off computer A.
To ensure that the files are deleted, the cached version of the profile is synchronized with the profile on the server when a user logs on. All files in the local cache that are not present in the server and that were not modified since the last logoff time are removed. By using these changes, Windows XP can merge user profiles.
There are several files that will always be copied because the timestamp on those files is changed as part of the profile unloading process. The ntuser.dat and ntuser.ini files will always be copied to the server.
Quotas on Profile Size
Often, over time a roaming user profile may potentially grow to a large size, as the user stores more data on their desktop, installs more applications and increases the complexity of their roaming environment. While much of this enhances the user experience, it may result in greater logon and logoff times for the user, as the data is copied down from or back up to the server.
While excluding some of the profile folders from roaming can reduce profile size, there may be situations in which it is more useful to actively restrict the overall quota size, to prevent it growing to an excessive size. The Proquota.exe program is a tool that you can set to monitor the size of a user's profile. If an individuals user profile exceeds the predetermined file limit, the user cannot log off from the computer until the user reduces the size of files.
Profile quota size is managed using the Group Policy snap-in. You can use the Limit Profile Size policy, available in the User Configuration\Administrative Templates\System\User Profiles node of the Group Policy snap-in to set the maximum size of the roaming user profile and to determine the systems response when the limit is reached. Click the Explain tab of this policy setting for more details.
Deleting cached roaming profiles
If you are concerned with disk size on a multi-user computer for example, a public computer where thousands of users can log on, you can also use the Group Policy setting that removes cached versions of the profile on logoff. The policy is called Delete cached copies of roaming profiles, and it is accessed under the Computer Configuration\Administrative Templates\System\User Profiles node of the Group Policy snap-in.
Changes to the way Guest profiles are handled
Windows 2000 and Windows NT 4.0 always delete the user profile of users belonging to the local Guests security group when users log off. Windows XP and Windows Server 2003, continue to delete the profile of guest users, only when the computer is joined to a domain. When the computer is part of a workgroup, the user profile of users belonging to the local Guests group is not deleted at logoff.
The exception is when the user is a member of the local Guests group AND a member of local Administrators, in this case the profile is NOT deleted when in a domain.
Group Policy Settings for Roaming User Profiles
See the Appendix for a list of policy settings related to roaming user profiles. For details about these policy settings, click the policys Explain tab.