Roaming user profile

A roaming profile that is several years old can contain tens of thousands of cookies, which make network login and logout extremely slow, and contribute to file system fragmentation.

Due to the profile copying at login and logout, a roaming profile set up using the default configuration can be extremely slow and waste considerable amounts of time for users with large amounts of data in their account.

When Microsoft designed Internet Explorer, the programmers made an explicit decision to store cookies and favorites as tiny individual files less than a kilobyte each, rather than storing this data as a single large consolidated file. Microsoft also stores shortcut files in the Recent profile folder, linking to recently opened files and folders.

File servers tend to only transfer large files several megabytes in size at the fastest possible network speed. Hundreds of very small files only a kilobyte per file can reduce network performance by 90%. As a profile ages and accumulates hundreds to thousands of cookies, favorites, and Recent items, the login and logout times become progressively slower, even though these files occupy only a few megabytes of profile data.

Local caching of the user profile on a desktop computer hard drive can reduce and improve login and logout times, but at the penalty of cluttering up the hard drive with profile data from every cached user who logs in. Local caching is more suitable where people tend to use the same computer every day. Local profile caching is not useful where hundreds to thousands of students need to be able to use any computer across a school or university campus—the cumulative cached data from so many different profiles can consume all available lab computer disk space.

Users with a roaming profile can encounter crippling logon delays when logging in over a WAN. If connected to the domain from a remote site, after authentication, Windows will attempt to pull the user's profile from the location specified in Active Directory. If the location happens to be across a WAN link it can potentially slow the WAN down to a crawl and cause the logon to fail (after a very lengthy delay).

Users with a roaming profile working from a remote site should login to the machine before connecting to the network, (so that the machine uses its cached local copy) and connect to the network after logon has completed. Another option is to remove the roaming profile path from Active Directory prior to their departure. This must be done in enough time that the change is replicated to the relevant Domain Controller at the remote site.

Working with large files, such as editing raw videos, can cause excessive login and logout times, as Windows will copy files in the roaming profile to the computer on login and back to the server on logout.

In environments where the large files are not mission-critical and do not absolutely need to be backed up to a server on a per-login basis, the applications requiring such excessively large amounts of user data are instead usually run on a stand-alone local account that does not roam, to bypass these network storage and retrieval problems.

Example of third-party software (Sun Microsystems Java) storing temporary files and software updates in the roaming profile. The bloated roaming profile increases login and logout times. The stored updates shown are unnecessary after installation, yet they are not deleted.

In a school environment, roaming can result in severe network congestion and slowness when an entire classroom of students log off computers at the same time, and then within minutes are attempting to log in somewhere else. Inconsistency in account data can result if the students begin to log into the second location before the profile uploading and log out from the first location has finished.

Some programs installed on desktop computers do not properly release control of the User registry during logoff, and can result in corrupted profiles because the User registry copying never successfully completes. To deal with this, Microsoft created a utility known as the User Profile Hive Cleanup Service which will forcibly remap the file handles for these misbehaving programs so that the profile copying can finish successfully and the account logoff is successful.[1] However, the hung program may remain on the local computer still holding the local cached copy of the User registry in a busy state, until the computer is rebooted.

The most recent version of a file in a roaming profile without redirection is stored only on the local computer, and stays there until the user logs off, whereupon it transfers to the server. If nightly server backups are done, and a roaming user does not log off for days at a time, their roaming account documents are not being included in the nightly backup.

Further, if a roaming user uses standby or hibernation to turn off the computer at night, their profile is still not copied to the network. In this manner it is possible for a roaming account's documents to not be backed up for days to weeks at a time, and there is the potential for considerable data loss if the local hard drive suffers a catastrophic failure during these long periods of not logging off the roaming account from the local computer.

Due to the underlying file copying mechanism from server to desktop, roaming assumes the user account is logged on to only a single computer at a time. Documents in a roaming profile copied down to the local machine have no network awareness of each other, and it is not possible to use file locking to alert the user that the file is already open.

Logging onto multiple computers with one account, and opening the same document multiple times on each computer can result in inconsistencies and loss of saved changes if the file is modified on two different computers at the same time:

• When the first computer with the modified document logs off, the changes are written to the network copy of the profile.
• When the second computer logs off, the different document version overwrites the previously saved changes during profile logout.

Different versions of Windows may employ different incompatible user profile layouts. As such, a user that roams between computers with different operating systems needs separate roaming profiles for each operating system. Windows Vista and Windows 7 add ".v2" suffix to the user profile folder to isolate it from the user profiles of Windows XP and earlier. Even so, Microsoft TechNet advises users not roam between computers running Windows Vista/Windows Server 2008 and Windows 7/Windows Server 2008 R2. User profiles in Windows 8/Windows Server 2012 and Windows 8.1/Windows Server 2012 R2 are also not entirely backward-compatible, although they initially used ".v2" suffix as well. Microsoft later released hotfixes and instructions to enable these operating systems to append ".v3" and ".v4" suffixes respectively, segregating them from cross-OS access.[2][3][4][5]

Some programs do not work properly with redirected profile folders that refer to a UNC file path on a server share: \\server\share\username\Application Data

• Unless the registry entry [HKEY_CURRENT_USER\Software\Microsoft\Command Processor] "DisableUNCCheck"=dword:1 is set, Windows' Command Processor cannot have a UNC working directory, so batch files usually fail.
• It is not possible to install Microsoft Office VSTO add-ins on a UNC path. (AppData can be a natural place for users to install addins without administration privileges.)
• Adobe Reader has been incompatible with Application Data located on a UNC file path since at least version 9.0, which would crash with a runtime error.[7] Adobe Reader X (10.0) is partially compatible but will not run in document protection mode on a UNC path.
• OpenOffice.org 3.3 is similarly incompatible with Application Data on a UNC path, and the software crashes on startup.[8] A fix has been developed and will be available in an upcoming release.
• Roaming Profiles and redirection are not supported by AutoCAD[9] 2013.

These problems with UNC paths can usually be fixed by having the folders redirected to a drive mapping for the UNC share:

• Drive N: (say) is mapped to \\server\share\userhomedir
• AppDir folder redirection to user home directory:N:\Application Data

However, use of drive mappings is generally deprecated by Microsoft, and UNC-only redirection paths are the preferred implementation.

• Application software versions on various machines used with the same profile may need to be kept in sync, with the same options installed, otherwise software configuration files may refer to dynamic libraries or extensions or other resources that are not available on another machine, causing system crash or limited features or corruption of the configuration.
• Installing software under one account may cause software to be only partially functional for other accounts due to the resources being unavailable to other users depending on their access rights to the installer's personal folders.

Folder redirection may be used with mandatory profiles, and is useful in situations where it is desirable to "lock down" the general desktop appearance but still allow users to save documents to the network. For example, this can be used as a generic account for anyone to use without a password for temporary use.

Redirecting My Documents and the Desktop in a mandatory profile will allow documents to be saved, but at logoff, any changes to the desktop appearance such as the desktop picture, Internet Explorer cookies, Favorites, and the Recent documents opened list are reverted to the original state.[10]

Folder redirection with mandatory profiles is accomplished by denying write access to the central copy of the profile. When users log off, they may expect to regularly receive an error that the profile could not successfully be copied back to the server. A user should also be aware that storing data in certain locations may cause their data to be lost. For example, if the desktop is reset every time a user logs on with the mandatory profile's desktop, then although it seems fine to save files on the desktop, when the user logs off, the profile does not get copied to the server, and when the user logs back on, any work saved on the desktop is permanently lost without any advance notice other than the error on logout that the profile could not be copied.

When user U logs into a Windows computer C joined to a domain, then C will consult the following locations to determine if the user has a roaming profile path configured:

1. the “Set path for Remote Desktop Services Roaming User Profile” group policy for C, if the login is to a terminal server
2. the msTSProfilePath attribute of U's LDAP object, if the login is to a terminal server
3. the “Set roaming profile path for all users logging onto this computer” group policy for C
4. the profilePath attribute of U's LDAP object

The first of these configuration settings that has a value overrides any later ones. LDAP attributes can be set by a domain administrator, or anyone else who has write access to the respective LDAP user object according to its access-control list. The value configured as the profile path is typically given as a UNC path to folder on an SMB file server, and the path typically contains the variable “%USERNAME%” to make it specific to the user. The roaming profile for Remote Desktop Server users is specified under the "Remote Desktop Services Profile" tab.

In Windows 2000 and later versions, a GUI interface for setting the profilePath attribute is available in the Active Directory Users and Computers snap-in. Windows NT 4.0 and earlier used the User Manager for Domains program. From many other operating systems, such LDAP attributes can be accessed e.g. with OpenLDAP command-line tools ldapsearch and ldapmodify (after SASL/GSSAPI authentication).

When a user logs into a computer joined to a domain, the Windows shell will check the above-mentioned LDAP attributes and group policy files to determine the roaming user profile path. It then calls the LoadUserProfile function. Microsoft has not documented the precise file synchronization algorithm that this function implements, but it involves comparing for each file found in both the local and the roaming profile the timestamps, to then replace any older file found on the computer. When the user logs off, the Windows shell calls UnloadUserProfile, which applies a similar file synchronization algorithm in the opposite direction, to allow changes made to the roaming profile to migrate back to the location where the user's roaming profile is stored. In addition, since Windows 7, it has possible to specify a group policy “Background upload of a roaming user profile's registry file while user is logged on” to apply this synchronization process to the NTuser.dat file at regular intervals (default is 12 hours). Logging into Windows via OpenSSH for Windows does not load a roaming profile.

Workstations running Windows 95, 98 or Me can also have roaming profiles, however the users roaming profile files in Windows 9x are stored in the users Home directory even if a separate location for roaming is specified. In order to use roaming profiles in Windows 9x each workstation needs to be set up to have separate profile settings for each user that logs into the local workstation enabled. Enabling separate desktop settings in Windows 9x is enabled under Passwords in the Windows Control Panel.

Roaming profiles on Windows 95, 98 and Me are all compatible with each other so if a network has mixture of Windows 95 and Windows 98 workstations the same user profile may be used for each workstation. This is also the case with Roaming profiles between Windows NT 4.0, Windows 2000, Windows XP but there may be some compatibility issues due to differences in each version of Windows. Roaming profiles in Windows Vista and Windows 7 are compatible with each other but these versions are not compatible with earlier versions of Windows. A separate profile folder with the extension .V2 will be created when using Roaming profiles with Windows Vista or 7. The easiest solution is to have all workstations running the same version of Windows. (see Compatibility section)

For roaming to work with Novell servers, the Novell product "ZENworks Desktop Management" needs to be installed on the server, and its associated workstation management package installed on each of the client computers. Within the directory, a User Package object is created, which enables roaming, specifies where the roaming profile is stored, and also stores any associated group policies for each version of Windows where users will login. The User Package also enables Dynamic Local User, which functions similar to Active Directory, allowing an account created in eDirectory to log in on any desktop computer even if no local account exists in advance, and assigns local account privileges such as User, Power User, or Administrator to the newly created local user account. For Windows NT the user profile files are stored in the users home directory under a subfolder for each version of Windows, for example in Windows NT 4.0 the folder will be called "Windows NT 4.0 Workstation Profile" and in Windows XP the folder will be called "Windows NT 5.1 Workstation Profile"

The User Package can be associated with a specific user account in the directory, or is associated with an organizational unit that then applies to all user accounts within that OU. The User Package also enables additional ZENworks Desktop Management functions, such as remote view and remote control of the desktop computer, network printers that follow the user from one desktop to the next, and the scheduling of events that are to be run wherever the user is logged in.

While Windows 3.x does not contain user profiles it was possible for users to have their own personalised desktop in a business environment. Windows 3.x had an administrative setup option which network administrators could use by typing setup.exe /a Windows could then be installed to a network share. Windows setup was then run from each local machine to install a few local files making Windows 3.1 capable of being run over a network. The local files could be saved to a user's home directory on a Novell or Windows NT Domain network allowing the user to have his or her settings roam between machines, the local machine in this scenario did not require a hard drive and could have been booted from a floppy or network card.

Redirected network folders are able to override the separation between 2000/XP and Vista/Win7. For example, both types of profiles can be redirected to use a single Documents folder, and a single Desktop folder, so that the user's account documents are consistent between the two profiles, even if all other account settings will be different.

Redirected sharing of folders such as Application Data may lead to data corruption, since Microsoft did not intend this for their application data to be shared between the different OS versions.