What are roaming profiles?

Let’s remind ourselves briefly what roaming profiles are, lets say we have forgotten—God forbid. At some point in the not-too-distant past, Microsoft decided to implement systems to help LAN administrators cope with ever-changing user environments and settings, increasingly complex networks, and security. One of these systems was roaming profiles, which gave portability to user profiles in an NT4 domain. In essence, users could now work at a variety of PCs, often at different locations, safe in the knowledge that they wouldn’t have to re-create things such as their desktop settings because everything profile-related was now stored at a central location on a server and was called every time a user logged on to a PC. While this new functionality was very useful, it also gave rise to new issues, in particular network bandwidth usage, which can increase dramatically when roaming profiles are in use. This is a particular problem on, say, 10-Mbps networks if you consider that an average user’s profile might, over time, grow to over 100 MB in size. Multiply this by several tens, or worse, hundreds or even thousands, of corporate users and soon the network slows almost to a halt. Until the advent of 100-Mbps, and more recently, gigabit networks, roaming profiles were often discounted for this very reason. During the development of the Windows 2000 platform, Microsoft changed quite a lot of the mechanisms in roaming profiles, to address issues such as (but not limited to) network bandwidth usage.

 

Ch-ch-ch-changes
Let’s take a look at some of the major differences between the older NT4 roaming profile model and the Windows 2000/2003 model. Chief amongst these is something known as the merge algorithm, which determines how roaming profiles are saved, updated and/or altered. Under NT4, roaming profiles are subject to mirroring, where every file and folder in the profile is copied to and fro using XCopy.

When a user logs on, the whole profile is copied to the local client at C:\Winnt\profiles and any changes during that session are written to the profile which is copied— in its entirety—from the local client back to the central location when the user logs off. In so doing, any other folders or files which are present, whether they are on the client or profile server, will be wiped, because of the mirroring function within the algorithm, which states that there can only ever be one master profile at any given time.

On the face of it, this may seem unimportant, but consider the following examples:

  • A user logs on to client X.
  • The same user then logs on to client Y.
  • The user moves back to client X and creates and saves a document in the local profile.
  • The user logs off client X and the whole profile gets XCopied back to the profile server.
  • The user then logs off client Y.
  • Because of the NT4 merge algorithm (which demands only one master profile), the profile stored on client Y will then be copied back to the profile server, but in so doing will wipe the profile that was stored there very recently from when the user logged off client X, taking with it the file that the user created while logged in at client X.

Similarly, if the user modifies a document, the same problem will arise:

  • A user logs on to client X.
  • The same user then logs on to client Y.
  • The user moves back to client X and opens and modifies a document, which gets saved in the local profile.
  • The user logs off client X and the whole profile gets XCopied back to the profile server.
  • The user then logs off client Y.
  • Because of the NT4 merge algorithm (which demands only one master profile), the profile stored on client Y will then be copied back to the profile server, but in so doing will wipe the profile that was stored there very recently from when the user logged off client X, taking with it the file that the user modified while logged in at client X.

Clearly, the single master profile approach in NT4 has its limitations and potentially serious repercussions when data is lost in this way. Windows 2000/2003 deals with this issue by making use of a different merge algorithm, this time based on time stamping and the principle of “last write wins”. Time stamps permit the true merging of data at the file and folder level, which means that data will not be lost or overwritten.

In this case, the time at which a user logs on or off is written to the profile and when it comes time to write any changes, the time stamp on a file or folder is used to determine the age of said file which will then either be deleted (if older) or written, if newer. Making sure that profile changes during a session are recorded correctly is also part and parcel of the newer system.

Windows 2000/2003 looks at the copy of a cached profile on a client and, based on the contents of the server profile and the last logoff time from that machine, any file changes will either be preserved or deleted. An example:

  • A user logs on to client X.
  • The same user modifies and saves document 10.xls on client X.
  • The user logs on to client Y.
  • The user logs off client Y, which now also has a copy of the profile with an earlier version of document 10.xls.
  • The user moves back to client X, deletes document 10.xls, and logs off.
  • To ensure that document 10.xls remains deleted, the local cache of the profile is synchronized with the server. This means that all documents present in the local cache but not on the profile server, and which haven’t been modified since the last logoff, will be deleted.

The result of all this is that Windows 2000/2003 can truly merge the varying contents of roaming user profiles across numerous client PCs, a significant improvement over Windows NT4.

Non-roaming components
At NT4 Service Pack 4, and in Windows 2000/2003, Microsoft introduced non-roaming components into the roaming profile, which are applied on a per-user basis. An example would be the Temp and Temporary Internet Files directories which remain excluded from the roaming profile, while Favorites are included and follow the roaming user.

In a Windows 2000/2003 environment, there is also a Group Policy setting, Exclude Directories In Roaming Profile, which can be used to tailor exactly which folders do or do not become part of the roaming profile. However, this setting cannot be applied to Temp and/or Temporary Internet Files because these are excluded by default.

Back to bandwidth
The folders which cause the greatest amount of traffic are My Documents and My Pictures (and more recently My Music). Because of the way NT4 handles the whole issue of roaming profiles, Windows 2000/2003 added the function known as Folder Redirection which can be applied to selected users, or groups of users, through Group Policy.

In practice, this means that any personal folders (e.g., Application Data, Desktop, My Documents, My Pictures, and Start Menu) under the purview of the said Group Policy— most usually My Documents and My Pictures— will not be downloaded to the local client when users with roaming profiles log on to the network. Although these files are part of the whole profile, they will remain at the location at which the profile is stored on the profile server; but with the help of registry settings on the client operating system, the folders will nevertheless remain available wherever and whenever roaming users should require them.

Group Policy allows administrators great flexibility in regard to the storage location of roaming profile folders. As mentioned above, this can be done on the basis of security group membership, and this means that different groups using different file servers could access their profiles from a variety of sources, leading not only to a more efficient use of network bandwidth, but also better server load-balancing.

Another tool available to those experiencing bandwidth limitations is the Proquota.exe program, which helps administrators to enforce strict limits on personal profile sizes, much as Exchange does with limiting mailbox sizes. If the user is logged on and their profile grows beyond the limit imposed by Proquota.exe during his or her session, the user will be unable to logoff until the size of the profile is reduced below the threshold limit.

You most likely would not use this tool if you have also implemented a Folder Redirection policy, because the largest folder in a profile is usually My Documents, which remains in one place under Folder Redirection, hence no need to limit a profile size if it will obviously remain fairly small.

… (complete article: http://articles.techrepublic.com.com/5100-10878_11-5096940.html

*** jp 05/18/09

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: