Roaming Profiles

Now that you're familiar with the files and folders that make up Local Profiles, you're ready to implement Roaming Profiles. Roaming Profiles are a logical extension to the Local Profiles concept. When users hop from machine to machine, the customized settings they created on one machine are automatically placed on and displayed at any machine they log on to.

For instance, you might have an organization in which 30 computers are at each site for general use by the sales team. If any member of the sales team comes into any office, they know they can log on to any machine and be confident that the settings from their last session are patiently waiting on the server.

Setting up Roaming Profiles for users in Active Directory is a straightforward process: share a folder to house the profiles, and then point each user's profile toward the single shared folder. By default, Roaming Profiles save a copy of the profile to the local hard drive. That way, if the network or server becomes unavailable, the user can use the last-used profile as a cached version. Additionally, if the user's Roaming Profile on the server is unavailable (and there is no locally cached copy of the Roaming Profile), the system downloads and uses the Default User Profile as an emergency measure to get the user logged on with some profile.

As you'll see in the next chapter, another advantage associated with Roaming Profiles is that if a machine crashes, the most recent "set" of the user environment is on the server for quick restoration.

For those of you who threw up your hands and gave up using Roaming Profiles in Windows NT, I encourage you to try again with Windows 2000 and Windows XP. The Roaming Profile algorithm is much improved since the NT 4 days. Specifically , there are two reasons why the improved Windows 2000/Windows XP algorithm is better than the old NT 4 counterpart :

• Roaming profiles now account for "multiple logins" Most people had problems when a single user logged on to multiple machines at the same time. In NT 4, the profile was preserved only from the last computer the user logged off from potentially losing important files in the profile. Windows 2000 and Windows XP don't work that way. They do a file-by-file comparison of files before they get sent back to the serversending only the latest time-stamped file to help quell this problem. So, give it another go if you despaired in the past.

  However, one warning should be noted. All the user's settings are represented as one single file: NTUSER.DAT . Because the last writer wins, the NTUSER.DAT with the latest time stamp overwrites all others. If you make two independent changes to a setting on two different machines, you can lose one because only the NTUSER.DAT with the latest time stamp "wins."

• Roaming profiles now only pull down and push up changed files NT 4 roaming profiles were on the slow side especially over slow links. The good news with Windows 2000/Windows XP roaming profiles is that only new and changed files are specifically moved around the network. So, if someone logs on to the same machine over and over again, the user is not waiting for the whole gamut of profile files to be downloaded. Logging in is now faster than ever.

Setting Up Roaming Profiles

The first thing we need to do on our server, WinDC01, is to create and share a folder in which to store our profiles. In this example, we'll choose a novel name Profiles. To create and share a folder in which to store Roaming Profiles, follow these steps:

1. Log on to WinDC01 as Administrator.

2. From the Desktop, click My Computer to open the My Computer folder.

3. Find a place to create a users folder. In this example, we'll use D:\PROFILES. After entering the D: drive, right-click and select New ˜ Folder. Name your new folder Profiles .

   Tip 

   You can substitute any name for Profiles. Additionally, you can hide the share name by placing a $ after the name, such as Profiles$.

4. Right-click the newly created Profiles folder, and choose "Sharing and Security" from the shortcut menu to open Profiles Properties dialog box at the Sharing tab.

5. Click "Share this folder." Windows 2000 and Windows XP client computers require that the permissions on the share are at least set to "Change." The defaults on Windows 2003 servers are for Everyone to have Read rights, which isn't sufficient. Use the Permissions button to change the rights so that Authenticated Users have at least Change rights as shown in Figure 8.8.

Figure 8.8: Change the permissions on the Profiles share so that Authenticated Users have Change control.

Warning 

Do not attempt to use the Offline Settings button (shown in Figure 8.8) in conjunction with Roaming Profiles. In Windows 2000 servers, the Offline Settings button is seen as "Caching." Roaming Profiles are automatically cached with their own independent algorithm. Therefore, leave the default settings as they are. Although the Offline Settings button is, in fact, useful, it's largely incompatible with Roaming Profiles. For more information on this phenomenon , see the Knowledge Base article "Off line File Caching Option Must Be Disabled on Roaming Profile" (Q287566). (For more on the Caching button, see Chapter 9.) Additionally, do not use the Encrypting File System (EFS) on shares containing Roaming Profiles. If you do so, roaming will not work.

Now you need to specify which network user accounts can use Roaming Profiles. In this example, you'll specify Brett Wier. Brett will now be able to hop from workstation to workstation. When he logs off one workstation, the changes in the profile will be preserved on the server. He can then log on to any other workstation in the domain and maintain the same user experience.

To modify accounts to use Roaming Profiles, you'll leverage Active Directory Users and Computers as follows :

1. Choose Start ˜ Programs ˜ Administrative Tools ˜ Active Directory Users and Computers.

2. Expand Corp.com in the tree pane, and double-click Brett Wier's account to open the Brett Wier Properties dialog box; click his Profile tab.

3. In the Profile Path field, specify the server, the share name, and folder you want to use, such as \\WinDC01\profiles\ %username% , as shown in Figure 8.9. For our purposes, you can leave all other fields blank.

   Note 

   The syntax of %username% is the secret sauce that allows the system to automatically create a Roaming Profiles folder underneath the share. The %username% variable is evaluated at first use, and Windows springs into action and creates the profile. Windows is smart tooit sets up the permissions on the folder with only the required NTFS permissions, such that only the user has access to read and modify the contents of the profile. If you want administrators to have access along with the user, see the information in the "Add the Administrators Security Group to Roaming User Profiles" section later in this chapter.

4. Click OK.

Figure 8.9: Point the user's profile path settings at the server and share name.

Modifying Multiple User's Profile Paths

After you set up Roaming Profiles and get comfortable with their use, you'll likely want the rest of your users to start using Roaming Profiles as well. The Windows 2003 Active Directory Users and Computers tool allows you to modify the profile paths of multiple users simultaneously . To do so, follow these steps:

1. Select the users (hold down Ctrl to select discontiguous users).

2. Right-click the selection, and choose Properties from the shortcut menu to open the "Properties on Multiple Objects" dialog box:

   
   Figure 8.10: Administrators cannot poke around user profiles (by default).

   Even if you're an administrator, you cannot dive in to Brett's folder. This is a safety mechanism that gives Brett exclusive permissions over his own sensitive stuff. If you want administrators to have access along with the user, see the information in the "Add the Administrators Security Group to Roaming User Profiles" later in this chapter.

   The Impact of Users Latching On, to My Documents

   Because My Documents is part of the profile, there is the extra burden of lugging all the files in My Documents back and forth across the network each time a user logs on. This can have serious ramifications . Once users start using the My Documents folder, they generally don't want to stop. They place 50MB worth of PowerPoint files, 50MB of Word documents, and 50MB of Visio files in My Documents, and then roam to another workstation, and they've just moved 150MB of data across the network at logon time! Ouch!

   In any case, this pain can fortunately be mitigated in two ways. Windows 2000, Windows XP, and Windows 2003 handle roaming profiles differently than their Windows NT cousin does.

   Let's imagine that we have two users: one on Windows NT and another on Windows 2000, Windows XP, or Windows 2003. Each user puts 300MB of files into the Roaming Profile. When a user on Windows NT does this, all files in the profile are copied up to the serverlock, stock, and barrelup to the server and then back over to the target workstation every time a user logs on or off. Can you say "Painful?"

   Windows 2000, Windows XP, and Windows 2003 transfer only changed files up and back between the client and server. Thus, if a user transfers 60MB of data and then changes one file, only that file is sent back to be saved in the Roaming Profile. This feature is great news if a user uses the same machine day in and day out; only the changes are pushed up and back. But the usefulness of this feature breaks down any time a user roams to a computer they have never used before. In this case, the entire contents of the Roaming Profile (including My Documents) is brought down from the server.

   That's why the real power comes with an IntelliMirror feature, Redirected Folders, which we'll explore in the next chapter.

    

Migrating Local Profiles to Roaming Profiles

In some situations, you might already have lots of machines with Local Profiles. That is, you didn't start off your network using Roaming Profiles, and now you have either many machines with Local Profiles or just pockets of machines with a combination of Roaming Profiles and Local Profiles. You can, if you want, maintain the user's Local Profile settings and transfer them to the spot on the server you set up earlier. You can convert a Local Profile to a Roaming Profile in two ways. Whichever option you choose, you first need to set up a share on a server.

Automatic Upload of Existing Local Profiles

In general, this step couldn't be easier. As we did earlier, on each user's Profile tab, point the profile path to \\ servername \share\%username% as seen in Figure 8.9. The next time the user logs on to a machine with a Local Profile (and then logs off), the Local Profile is automatically uploaded to the server to become their future Roaming Profile. For most users, this is the way to go.

Manual Upload of Existing Local Profiles

If the user has logged on to multiple workstations and therefore has multiple Local Profiles, you might want to guarantee that one specific Local Profile becomes the Roaming Profile for that user. The procedure is nearly identical to the one you used to create the Default Domain User Profile. To preserve a specific Local Profile and convert it to a Roaming Profile, follow these steps:

1. Log on as the Administrator to the workstation where the desired Local Profile resides.

2. Choose Start, right-click My Computer, and choose Properties from the shortcut menu to open the System Properties dialog box. Click the Advanced tab, and then in the User Profiles section, click Settings to open the "User Profiles" dialog box.

3. Select the Local Profile you want to convert to a Roaming Profile, and then click the Copy To button to open the Copy To dialog box, as shown in Figure 8.11.

4. Enter the server name, shared folder name, and folder name of the profile storage path, as shown in Figure 8.11.

5. Also, be sure to change the profile so that at least the user has access. It's generally okay to modify the profile permissions to Everyone. Click OK.

Figure 8.11: To move a specific profile to the server, use the Copy To dialog box.

When you do, the user's folder is automatically created in the shared folder.

Changing the Profile Type from Roaming to Local

Mere mortal users (those without administrative privileges) can go to the User Profiles dialog (as seen on Figure 8.6), choose their own profile, then change the profile type with the "Change Type" button. This will change their profile from Roaming to Local or back again and thus specify which copy of the profile (local or Roaming) is to be used when they log on.

If a user selects Local Profile, a Roaming Profile revert to a Local Profile. The Roaming Profile on the server stays there, but the user doesn't use it when working at this local machine. The next time the user works at this specific workstation, the changes are only saved to the local profile.

If the user selects Roaming Profile, and the Roaming Profile is on the server, the system determines which copy is newer. If the local copy is newer , the user is asked whether to keep or ditch the profile on the server.

 

Also, don't forget that for each specific user Local Profile that you manually convert to a Roaming Profile, you'll need to modify the profile path (similar that seen in Figure 8.9 earlier). Once you've done this, this user, Jimmy Kissel can now log on to any Windows 2000 or Windows XP machine as jkissel, and this specific profile (that you just pushed up) will follow him as a Roaming Profile.

Roaming and Nonroaming Folders

Now that you have a grip on which folders constitute the profile and how to set up a Roaming Profile, it might be helpful to know a bit about what's going on behind the scenes. Remember that several folders make up our profile.

Local settings, including local machine-specific application folders and information, do not roam when Roaming Profiles are enabled. This is true for the following elements:

• Local computer Application Data. Some applications write information specific to the local computer here. This folder is located in \Documents and Settings\{Username}\LocalSettings\Application Data . Any subfolder below this folder also do not roam, including:

  • History

  • Temp

  • Temporary Internet Files

  All others do roam with the user:

• Application Data. This folder is located in Documents and Settings\{Username}\Application Data . This is typically a per-user store for application data, such as Office 2000/Windows XP/2003 Custom Dictionary.

• Cookies

• Desktop

• Favorites

• My Documents

• My Pictures

• NetHood

• PrintHood

• Recent

• Send To

• Start Menu

• Templates

Indeed, My Documents, My Pictures, Desktop, Start Menu, and Application Data have an additional property; they can each be redirected to a specific point on the server, as you'll see in the next chapter.

Windows XP and Windows 2003 Profile Changes

Everything stated until this point is valid for Windows 2000, Windows XP, and Windows 2003. However, both Windows XP and Windows 2003 contain additional stuff that their Windows 2000 cousins do not. Let's examine that stuff below.

Additional System Profiles

Windows XP and Windows 2003 contain two new profiles that are meant to be used by newly installed services: Local Service and Network Service.

Local Service Meant to be used by services that are local to the computer but do not need intricate local privileges or network access. This is in contrast to the "System" account, which pretty much has total authority over the system. If a service runs as Local Service, it appears to be a member in the local users group. When a service runs as Local Service across the network, the service appears as an anonymous user.

Network Service Similar to Local Service, but has elevated network access rightssimilar to the System account. When a process runs under Network Service rights, it does so as the SID (Security ID) assigned to the computer.

Windows XP and Windows 2003 automatically create these profiles, which are basically normal but still a little special. For instance, you will not see the Local Service or Network Service in the listing of Profiles in the System Properties dialog box. You can see them in the Documents and Settings folder; however, they're "super-hidden" so that mere mortals cannot see them by default. You can see them in the top window in Figure 8.12.

Figure 8.13: Users roaming within Cross-Forest scenarios receive this message.

You can use a policy setting to prevent this from affecting your client computers. To do this, locate the Allow Cross-Forest User Policy and Roaming User Profiles policy setting by drilling down in Computer ˜ Administrative Templates ˜ System ˜ Group Policy.

Affecting Roaming Profiles with Computer Group Policy Settings

Roaming Profiles are simple to set up and maintain, but sometimes you'll want to use certain policy settings to affect their behavior. The policies you'll be setting appear in the Computer Configuration section of Group Policy. Drill down into Administrative Templates ˜ System ˜ User Profiles, as shown in Figure 8.14. In Windows 2000, these User Profiles policies were not located under their own branch but in Administrative Templates ˜ System ˜ Logon.

Figure 8.14: There are many policy settings that affect profiles.

Recall from Chapter 1 that computers must be in the OU that the GPO affects (or in a child OU that inherits the setting).

Tip 

You might also need to reboot the machine once you move the computer into an affected OU for your wishes to take immediate effect.

Before implementing any policy setting that affects Roaming Profiles, read through this section and determine if it adds value to your environment. Then, create a test OU and ensure that the behavior is as expected.

Do Not Check for User Ownership of Roaming Profile Folders

Windows XP without a service pack and Windows 2000 with SP3 and earlier may have a potential security hole. If someone, such as a person in the Server Operators group, can pre-create the user's target profile subfolder on the server, that creator is also the owner of the subfolder. When the user then pushes up their profile to the subfolder, the user isn't the only one with access to the profile; the creator/owner also has access. This could mean that the creator/owner can peer inside and get stuff they really shouldn't have.

If a client logs on to a Windows 2003, Windows XP (SP1 and later), or Windows 2000/SP4 computer, the machine is smart enough to first check to see if the user is the only one with permissions on the folder (as seen earlier in Figure 8.10) before moving sensitive profile data up. If you enable this policy setting, you're telling newer machines to act like older machines and allow sensitive profile information to move up to the server, even if the user doesn't have exclusive access and ownership to the subfolder. Personally, I would leave this unconfigured. (You can read more about this in the Knowledge Base article KB 327259.)

Tip 

This policy setting applies only to Windows 2003 computers, Windows XP (SP1 and later) computers, and Windows 2000/SP4 computers.

Delete Cached Copies of Roaming Profiles

This is a space-saving and security mechanism that automatically deletes the user's locally cached profile when the user logs off. The default behavior is to allow files to be downloaded and pile up on each and every hard drive to which the user roams. You can enable this policy setting to (as the forest rangers say) "Leave only footprints and only take away memories at your campsite." Heck, you won't even be leaving any footprints.

This policy setting has two downsides, however; let's walk though three scenarios to examine these potential problems. And, we'll look at one really good use for this setting.

Scenario 1: Server down at login time This policy setting is set to delete cached copies of Roaming Profiles. The user logs on, makes some changes, and logs off. The profile is automatically sent back to the server, and the footprints are washed away on the local machine.

Now, let's say that the server that houses the Roaming Profiles goes down. By default, if the user tries to log on and the server is unavailable to deliver the Roaming Profile, the locally cached copy of the profile is summoned to take its place. Once you enable this policy setting, you're severing a potential lifeline to the user if the server that houses the Roaming Profile becomes unavailable. Enabling this policy setting sweeps up after the user on the local machine at logoff . If the server goes down, the user will not get their locally cached version of the Roaming Profile because there is no locally cached version of the profile. Rather, the only profile the user will get is a temporary Local Profile that is not saved anywhere when the user logs off.

Scenario 2: Server down at logoff time Conversely, if for some reason the server becomes unavailable to receive the Roaming Profile at logoff time, the default behavior (without the policy setting Enabled) is to maintain a locally cached copy for the user at logoff time. When the server recovers, and the user next logs on to that machine, they will pick up their locally cached version of the profile. At next logoff time, the changes are sent back to the server, and the locally cached version is deleted. If you enable this policy setting, there is no way for the system to maintain the locally cached copy for the user when the server recovers.

Scenario 3: Up and back and up and back Again, by setting this policy setting, you're deleting all cached files. So, when the user logs back on to the same machine, all the roaming profile files need to get re-downloaded from the roaming profile on the server, which means you're killing the caching inherent in the roaming profile system. In essence, you're making your machine act like NT 4, where the whole profile gets re-downloaded at login. Note, however, that at logoff time, things should still be faster than NT 4 because you're pushing up only changes (where NT 4 would have pushed up all the files.)

Using this setting in a high security environment This policy setting is useful in high-security environments where you need to make sure that no trace of potentially sensitive data in the profile is left behind. Be careful when using it with laptops, however, because users frequently need to use their copy of the locally cached version of the profile to get their work done. Additionally, enabling this policy setting does prevent third-party tools from "resurrecting" deleted files inside the profile. It deletes the files, but doesn't obliterate them to prevent industrious hackers from any possible recovery.

Once this policy setting is Enabled, the profile is erased only on logoff. And then it erases only profiles from machines on which users don't already have an existing cached copy! If you need to maintain a high-security environment, be sure to enable this policy setting early so that users don't have time to roam from machine to machine sprinkling copies of their profiles around (which won't get erased later by use of this policy setting).

Warning 

To use this policy setting, you'll need to disable (or not configure) the Do Not Detect Slow Network Connection policy setting, as described shortly. If a network connection is determined to be slow, it automatically tries to grab the locally cached copy of the profile, which doesn't exist if you've enabled this Delete Cached Copies of Roaming Profiles policy setting.

Slow Network Connection Timeout for User Profiles

Enabling this entry performs a quick ping test to the profiles server. If the speed is greater than the minimum value, the Roaming Profile is downloaded. If, however, the speed is not fast enough, the locally cached profile is used unless you've enabled the previous entry ( Delete Cached Copy of Local Profiles ). In that case, the user ends up with a temporary profile as described earlier.

Warning 

Setting the Do Not Detect Slow Network Connection policy setting, as described in the next section, forces anything set in this policy setting to be ignored.

This policy setting has two modes, which it uses automatically: IP and non-IP. If the computer housing the profiles is connected to a network using IP, the speed is measured in kilobits (Kb) per second. If the computer housing the profiles is not connected using IP, the speed is measured in milliseconds (ms).

This policy setting is a bit strange : even if it's not configured, it has a default. That default speed threshold for IP mode is 500KB; that is, if the ping test determines that the bandwidth to the machine that houses the profiles is greater than 500KB, the profile is downloaded. If the ping returns a bandwidth of less than 500KB, the Roaming Profile is skipped , and the locally cached profile is used.

That default speed threshold for non-IP mode is 120ms; that is, if a machine that houses the profiles responds in less than 120ms, the profile is downloaded. If the machine that houses the profiles does not respond to the test in 120ms, the profile is skipped, and the locally cached profile is used.

You might want to enable this policy setting and increase the value thresholds if you want to increase the chances of a dial-up connection receiving the Roaming Profile instead of the locally cached profile. If you enable this policy setting, you'll need to manually specify both an IP ping time test and a non-IP ping millisecond test.

Note 

Unrelated speed tests can verify the ability to apply GPOs for both the user and computer. They are in the Group Policy Editor under Computer or User Configuration ˜ Administrative Templates ˜ System ˜ Group Policy ˜ Group Policy Slow Link Detection.

Do Not Detect Slow Network Connection

Like the previous policy setting, this one is a little strange. If it's not configured, it still has a default; that is, the users affected by this policy setting check the Slow Network Connection Timeout for User Profiles setting to see what a "slow network" actually means. If you enable this policy setting, you're disabling slow network detection, and the values you place in the Slow Network Connection Timeout for User Profiles policy setting don't mean diddly, nor do the default values of 500KB or 120ms.

Wait for Remote User Profile

Again, even if this policy setting is not defined or disabled, there is still a default; if the speed is too slow, it will load the locally cached profile. If you enable this policy setting, the system waits until the Roaming Profile is downloadedno matter how long it takes. You might turn this on if your users hop around a lot and the connection to the computer housing the Roaming Profiles is slow, but not intolerable. That way, you'll still use the Roaming Profile stored on the server as opposed to the locally cached profile.

Prompt User When Slow Link Is Detected

When the ping test determines that the link speed is too slow, the user can be asked if they want to use the locally cached profile or grab the one from the server. If this policy setting is not configured or it's disabled, the user isn't even asked the question. If the Wait for Remote User Profile policy setting is enabled, the profile is downloaded from the serverhowever slowly. If this policy setting is enabled, the user can determine whether they want to accept the profile from the server or utilize the locally cached profile.

If you've enabled the Delete Cached Copies of Roaming Profiles policy setting, there won't be a local copy of the Roaming Profile, so the user will be forced to accept the Default User Profile. If the Do Not Detect Slow Network Connection Properties policy setting is enabled, this GPO is ignored.

Timeout for Dialog Boxes

If the Prompt User When Slow Link Is Detected policy setting is enabled, the user has a 30-second countdown to respond. Once this policy setting is enabled, the default value of 30 seconds can be changed. This dialog box timeout is also presented when the server that houses the Roaming Profile is unavailable, when the user logs off, or when the locally cached profile is newer than the Roaming Profile stored on the server. In all cases, the user can be prompted to determine what to do. The value you specify here is how many seconds to wait for an answer before the other policy settings make the decision for the user.

Log Users Off When Roaming Profile Fails

This is the harshest sentence you can offer the user if things go wrong. By default, if the server is down (or the profile is corrupted), the user first tries to load a locally cached profile. If there is no locally cached profile, the system creates a TEMP profile from the Default User Profile.

However, if you choose to enable the setting, the behavior changes. If no Roaming Profile or locally cached profile is available (presumably because you've enabled the Delete Cached Copies of Roaming Profile policy setting), the user is not permitted to log on.

Maximum Retries to Unload and Update User Profile

As previously discussed, this policy setting is meant to assist Windows 2000 Terminal Services when trying to log users off and release their Roaming Profiles. Increase this value to increase the number of attempts made at unloading the pertinent Registry information and update the profile when users start to complain that things aren't the same when the last logged off (especially on Terminal Services). Setting this upon Windows XP or Windows 2003 machines should not be necessary, as the underlying algorithm is changed on those systems to automatically adjust when necessary.

Add the Administrators Security Group to Roaming User Profiles

As you saw in Figure 8.10 earlier in this chapter, only the user can dive in and poke around their own user profile. However, you can specify that the administrator and the user have joint access to the folder.

Oddly, this policy setting is found under the computer side of the housenot the user. Therefore, it's somewhat difficult to implement this policy setting on a small scale, because it's sometimes a mystery that client machine users will log on to. If you want to use this policy setting, I recommend creating a GPO with this policy setting at the domain level, to guarantee that any client computers that users log on to will be affected. Setting this policy setting such that it affects the file server housing the profiles doesn't do anything for you. It's the target client computers that need to get this policy setting.

This policy setting only takes effect when new users first log on to affected client computers. Once they're on, they'll make some changes that affect the profile, and then log off. When they log off, a signal is sent back to the directory housing the profile, which then finalizes the security on the directory so that both the user and the administrator can both plunk around in there.

To be especially clear, as I implied , this policy setting works only for new usersthat, is those users who don't already have a Roaming Profile. Users who already have established Roaming Profiles are essentially left in the dark with regard to using this; but there is a ray of light. If you want the same effect, you can take ownership of a profile and manually establish administrative access for the administrator and the user, as described in the upcoming section "Mandatory Profiles from an Established Roaming Profile."

Note 

This policy setting works with Windows 2000's Service Pack 2 and later, although the policy setting's ExplainText states that it's only applicable to Windows XP and Windows 2003.

Prevent Roaming Profile Changes from Propagating to the Server

As previously discussed, when a user jumps from machine to machine and lands on one with an existing Local Profile, the system merges the Local Profile as a favor to the user. The idea is that if this Local Profile has a data file, say, RESUME.DOC , that's missing in the user's Roaming Profile, this is a perfect time to scoop it up and keep it in the Roaming Profile. You can dictate specific machines for which you don't want this to happen.

In general, you set this policy setting only on computers that you are sure you don't want the merge between Local Profiles and Roaming Profilesperhaps because the Local Profiles contained many unneeded files.

Note 

This policy setting affects only Windows XP and Windows 2003 machines; though the "merge" algorithm is the same for Windows XP, Windows 2003, and Windows 2000 machines. Even so, Windows 2000 machines cannot be affected by this policy setting (and hence, will always merge regardless if this policy setting is Enabled or not).

Only Allow Local User Profiles

This policy setting is useful when you have set up specialty machines, such as lab machines, library machines, kiosk machines, and so on. By setting this policy setting on the machines, you can ensure that a user's Roaming Profile doesn't "get in the mix" for what you designed this machine to be.

Note 

If trying to figure out all the ins and outs of Roaming Profile policies is giving you a headache , use the handy flowchart in Figure 8.15 to help figure out what each policy setting does and how it will affect your users.

Figure 8.15: Roaming Profile policy settings flowchart

Leave Windows Installer and Group Policy Software Installation Data

Earlier, we explored the Delete Cached Copies of Roaming Profiles policy setting. The idea was to "clean up" behind a user when he or she logged off. This is a great idea in theory, but had an unintended consequence.

That is, if you opt to delete roaming profiles at logoff time, the information regarding applications deployed via Group Policy Software Installation (explored in Chapter 10) is also lost (by default). There is a new policy that affects users on Windows XP/SP2 (or Windows 2003/SP1) called Leave Windows Installer and Group Policy Software Installation Data . Once enabled, the Group Policy Software Installation data remains on the hard drive, so subsequent logins for users are much faster.

This is likely a good idea to enable for most of your Windows XP clients except when very high security is needed.

Affecting Roaming Profiles with User Group Policy Settings

As you have just seen, most policy settings regarding Roaming Profiles are associated with the computer itself. Two policy settings, however, affect Roaming Profiles but are located on the user side of the fence: Limit Profile Size and Excluding Directories in Roaming Profile . These policy settings are found under User Settings ˜ Administrative Templates ˜ System ˜ User Profiles, as shown in Figure 8.16.

Figure 8.17: You can limit the Roaming Profile size, if desired.

Once this policy setting is configured, the affected users cannot log off until the files that compose their profile take up less than the limit. They are presented with a list of files in their profile, as shown in Figure 8.18, from which they must choose some to delete.

Figure 8.18: Once the Roaming Profile size is set, users can't log off until they delete some files.

In general, this is a blunt instrument. The original use of this entry was for situations in which users stuffed lots of documents into their Windows NT Roaming Profileonto the Desktop, for instance. Recall that Windows NT pushes the entire profile up and back causing major bandwidth headaches . Indeed, because users rely heavily on the My Documents folder (which is part of the profile), there's even more reason to be concerned .

Warning 

Don't try to place disk quota restrictions on Roaming Profiles. Because applications sometimes put their own data inside the profile, users have a hard time tracking down files to delete if the quota prevented them from writing. Instead, use disk quotas on redirected folders, such as the My Documents folder. This is explored in the next chapter.

But instead of being forced to use this policy setting as your only weapon to fight disk space usage, you have an ace in the hole; in the next chapter, you'll learn how to use Folder Redirection to redirect My Documents. You can then place a disk quota on the redirected My Documents folder.

Excluding Directories in Roaming Profile

As previously stated, several folders in the profile will not roam. Again, these are the Documents and Settings\Username\Local Settings\Application Data (and everything below it, including Local Settings, History, Temp, and Temporary Internet Files).

You can add additional folders to the list of those that do not roam, if desired. You might do this if you want to fix a specific file to a Desktop (if you maintain locally cached profiles). For instance, you can exclude Desktop\LargeZipDownloads if you want to make sure those types of files do not roam with the profile (see Figure 8.19).

Figure 8.19: Prevent specific folders, such as the Desktop, from roaming.

Tip 

In Windows 2000, some, but not all, of the automatically excluded folders are presented in the Group Policy Editor. As far as I can tell, they're only there for show; deleting them produces no appreciable gain. (For example, you can't make the Temp, History, or other folders roam in the profile.) You can only add your own entries in addition to or in lieu of the presented entries. These are not listed for Windows XP/Windows 2003.

Note 

Enter additional entries relative to the root of the profiles. For instance, if you want to add the Desktop, simply add Desktop (not c:\Documents and Settings\Desktop or anything similar), because the Desktop folder is found directly off the root of each profile.

Connect Home Directory to Root of the Share

I'm pretty sure that by the time you get to the end of this book, you won't want to use old-style "Home Drives" anymore. That's because the changes in Roaming Profile behavior and redirected folders (next chapter) present a better way for users to store their files. However, if you do end up using Home Drives for each user (located in the Account tab of each user's account's Properties), you can specify a location for users to store their stuff. Specific environment variables typically used when setting up home directories are defined differently in NT 4 and Windows 2000 (and later).

Those two environment variables %HOMEDRIVE% and %HOMEPATH% are automatically set when you set up, share, and assign a home directory for a user. NT 4 client computers aren't as smart as Windows 2000 computers, and they understand the "meaning" of the %HOMEDRIVE % and %HOMEPATH% shares a bit differently. To make a long story short, the fully qualified name path to the share isn't represented when those variables are evaluated on NT 4 clients; but it is for Windows 2000 and later clients. You can "dumb down" Windows 2000 and newer clients by applying this policy setting, and making new clients act like old NT 4 clients.