Best Practices for Managing User Data and Settings, Part 2

Last month, in “Best Practices for Managing User Data and Settings, Part 1” (InstantDoc ID 97841), I began a discussion about the pieces you need to put in place to effectively manage user data and settings (UDS). The goal was to create a UDS-management framework—a combination of technology, people, and processes—to meet specific security, mobility, availability, and resiliency business requirements. In that article, I covered the server-side components of the framework. This month, I address the client-side components.

The goal this time is to unify UDS management for both Windows Vista and Windows XP users— something that isn’t possible without some of the tips you’ll find herein, such as registry-based folder redirection. Specifically, we need to address four types, or classes, of UDS that I call “normal data,” “normal settings,” “locally accessed data,” and “unwanted data.” Unfortunately, as you’ll see, Windows provides direct support for managing only the first two types of data, which is why so many organizations struggle to put all the moving parts in place—some parts are missing!

Redirect User Data Stores
The first class of data I’ll address is “normal data” that can reside in standard Windows data stores such as the Documents and Desktop folders. You can use redirected folders to manage normal data and meet your business requirements.

Redirected folders are a well understood, tried-and-true technology in Windows environments. You can redirect selected shell folders (e.g., Documents, Desktop) to shared folders on the network, and the result will be completely transparent to users. You implement most folder redirection through Group Policy, under User Configuration, Windows Settings, Folder Redirection. You should use the Group Policy Management Editor (GPME) on a Vista client to edit Folder Redirection Group Policy settings so that you can configure settings that will apply to both Vista and XP.

Although XP supports redirecting only four folders, Vista lets you redirect thirteen folders, as you can see in Figure 1. I highly recommend redirecting Documents and Desktop, as well as any of the new folders that Vista can redirect. As I discuss later, you can redirect the AppData folder, but using roaming profiles is generally a better management choice for AppData. Except in schools and other environments in which multiple users should have identical Start menus, I’ve never found it useful to redirect the Start menu.

Microsoft documents the steps for configuring folder redirection in its Help files. Rather than repeat those steps here, let’s focus on bottom-line recommendations and tips. On the folder-redirection policy’sTarget tab, you can set the following recommended policy settings.

On the Settings tab, you should changealmost all the defaults.

Redirect XP Favorites and Media Folders
Although Vista lets you use folder-redirection policies to redirect all user data folders, XP won’t let you use these policies to redirect folders such as Favorites, My Music, and My Videos. You can, however, use registry-based redirection to redirect these XP folders. In the XP registry, the HKEY_CURRENT_USER SoftwareMicrosoftWindowsCurrentVer sionExplorerUser Shell Folders key contains values for each of these folders. You can change the data of these values to redirect the folders to network locations. The resulting redirection is identical to folder redirection implemented through Group Policy.

In fact, I’ll make it easy for you. How about a Group Policy administrative template that manages registry-based redirection of these folders? You can download the Registry- Redirection.adm file from www.windowsit pro.com, InstantDoc ID 98004. Load the file into a GPO that’s scoped to apply to XP users. I recommend using registry-based redirection for Favorites, My Music, My Pictures, and My Videos on XP, even though you can use folder-redirection policies to redirect XP’s My Pictures. For Vista clients, use standard folder-redirection policies.

When you redirect XP media folders, applications such as Apple iTunes and Windows Media Player (WMP) will automatically use the redirected folder. But what about users who are accustomed to opening My Documents and double-clicking a folder to access media? To accommodate those users, I recommend that after you migrate the contents of those folders to the network, you delete the actual subfolders in My Documents. Then, create shortcuts called My Music, My Pictures, and My Videos that point to the new locations. Those shortcuts will provide XP users with the visual links they use to browse to media. Of course, you might also choose not to redirect one or more of these folders based on your need to manage users’ media files.

Continue on Page 2

With folder-redirection policies managing all user data stores for Vista users, and a combination of folder-redirection policies and registry-based redirection for XP users, you can unify the experience of users who roam between computers running different OSs. Regardless of where the user logs on, he or she will have access to all data stores.

Roaming Profiles Manage Ntuser.dat and AppData
Now that you’ve redirected all user data stores and Favorites, you’re left with the two remaining stores of user settings: the user’s registry hive and the AppData folder—%userprofile% Application Data (in XP) and %userprofile%AppDataRoaming (in Vista). These stores, which I refer to as “normal settings,” are best managed with roaming profiles.

Roaming profiles got a bad rap in the days of Windows NT 4.0. Even in the 21st century, many organizations have had less-than-ideal experiences with roaming profiles, citing the size and synchronization of profiles as particularly problematic. However, properly implemented roaming profiles work very well.

Profile synchronization is quite efficient. At logon and logoff, Windows compares the server copy of the profile with the locally cached copy and synchronizes only files that have changed. However, if your Documents folder has thousands of files, scanning those files to identify what has changed can take a long time, creating a perception of slow logon and logoff processes. Additionally, the Desktop or Documents folders might have one or more large files. For example, PST files can be huge. Each time Microsoft Outlook touches a PST file, it changes that file’s timestamp so that, at logoff, Windows considers it a changed file even when the contents of the PST file haven’t changed. At each logoff, then, your PST files get copied to the profile on the server. Therefore, in most environments, it isn’t appropriate to allow users’ desktops and Documents folders to roam.

These two examples illustrate the problem of enabling roaming profiles without careful thought and design. It’s important to exclude certain folders from roaming. Redirected folders are automatically excluded from roaming, so once you redirect the Documents, Desktop, and other folders, the number of files in your roaming profile—and particularly the number of large files—will be significantly reduced.

You can use Group Policy to exclude additional folders from roaming. The Group Policy setting you require is Exclude directories in roaming profiles, located under User Configuration, Administrative Templates, System, User Profiles. Because this setting is user-based, you could have different folders roaming based on a user’s role. You can specify folder names relative to the user profile, such as AppDataRoamingMicrosoft WindowsCookies. Figure 2 shows an example that excludes the Cookies folder on both Vista and XP.

A well-designed UDS framework will use roaming profiles as the mechanism for managing a user’s registry file—the ntuser .dat file in the root of the profiles. This file contains a number of critical settings and customizations that affect a user’s Windows experience, and it’s absolutely worth managing to achieve your mobility, availability, and resiliency requirements. The only practical way to meet the requirements for the registry file is a roaming profile—even if the only item in the roaming profile is ntuser.dat.

I also recommend that you allow the AppData folder—specifically, the AppData Roaming folder in Vista and the Application Data folder in XP—to roam. It’s possible to redirect AppData, but in my experience, many poorly coded applications won’t function correctly if AppData is redirected. Some applications also have trouble if, on a laptop, AppData is cached using offline files and network connectivity causes the computer to transition between online and offline modes. I think your goal should be to redirect App- Data eventually but not until you have time to thoroughly test all applications. So, the practical recommendation is to use roaming profiles to manage AppData until you can confidently redirect it.

Vista appends a .V2 extension to the folder that hosts the user’s roaming profile. If you configure a user’s profile path as \ namespace%username%profile, the user’s XP profile will be in the Profile folder, and the user’s Vista profile will be in the Profile. V2 folder—automatically. Due to significant differences in registry and AppData structure, there’s no way to unify those two settings stores for Vista and XP users. They will be separate. That’s another good reason for ensuring that roaming profiles manage only those two stores—any other stores in the roaming profile will be duplicated and separate for a user’s XP and Vista profile.

When a user’s roaming profile contains only the registry file and the AppData folder, the profile should be very small. On my heavily overloaded laptop, my roaming profile is only 40MB. Profile synchronization has less data to scan and copies only changed files, so the process is fast, efficient, and reliable.

Manage the Location of Unwanted Data
Most IT organizations aren’t expected to manage users’ personal music collections. I’m using music as an example of what I call “unwanted data”—a class of data that isn’t subject to your business’s security, mobility, availability, and resiliency requirements. You might identify other types of data as unwanted: users’ personal files, pictures, or email archives from non-business email accounts. This is one class of data for which Microsoft doesn’t a provide straightforward management solution. Vista makes it easier to manage unwanted data classes if they parallel specific media types: The Vista Pictures, Music, and Videos folders are already at the root of the user profile. For other classes of unwanted data (e.g., personal files), you’ll still need this workaround.

To ensure that unwanted data isn’t stored on network servers, you must first move the data so that it’s not within the scope of a redirected folder. For example, XP’s My Music folder is a subfolder of My Documents. Because My Documents will be redirected, you must relocate the My Music folder. Create a first-level folder underneath the root of the user profile—%userprofile%Music, for example—and move the data to that folder.

Next, determine how to redirect applications and the user to the new location. In the case of a media folder such as Music, you can use registry-based redirection to redirect applications to the new location. You can even use the RegistryRedirection. adm Group Policy administrative template to implement the registry-based redirection. Just point the My Music folder to your custom folder (%userprofile%Music). You must also ensure that users can find the custom folder for the unwanted data. Shortcuts placed at the data folder’s old location do the trick.

Continue on Page 3

Repeat this process for each class of unwanted data: Create a folder within the user profile, redirect applications as necessary, and provide users a way to navigate to the folder. Of course, you can combine various types of unwanted data within one user-profile folder. I recommend creating a Personal Files folder (%userprofile%Personal Files) to host unwanted data that isn’t directly associated with pictures, music, or videos.

After you move all unwanted data out of redirected folders, the final step to managing unwanted data is to exclude the unwanted data folders from roaming profiles. Use the aforementioned Group Policy setting to exclude each unwanted data folder.

Manage Data That Must Be Accessed Locally
Sometimes, it’s possible to store data on the network, but you find that performance over the network while accessing that data is unacceptable. Consider a company that creates videos for Web streaming. Editing video files over the network generally isn’t feasible. Most video-editing software performs adequately only when video files are accessed from the local disk subsystem. Our sample company needs to manage these video files according to the same requirements I mentioned earlier, including resiliency, availability, and perhaps even mobility.

These files need to reside on the network, but users need to access them from a local disk. I refer to such data as “locally accessed data”—another class of data for which Microsoft provides no perfect management solution. There are three approaches you can use to address locally accessed data. Each has its pros and cons.

First, you can move such data out of redirected folders and into folders in the user profile. Users access files in the user profile locally. They’ll be synchronized to the network at logoff as part of the roaming-profile synchronization. However, if locally accessed data files are large, synchronization can be extremely time-consuming.

Second, you can keep the data in redirected folders, use offline files to take the data offline, and leverage a new Group Policy setting available to Vista clients: Network Directories To Sync At Logon/Logoff Time Only. The policy is located in User Configuration, Administrative Templates, System, User Profiles— a non-intuitive location for an offline files setting. You use the network paths to the locally accessed data to configure the policy— for example, \namespace%username% DocumentsStreamingVideoProjects. Vista clients will access files in that location from the local cache, providing all the performance benefits of local access. Unfortunately, as with roaming profiles, the data will synchronize at logoff and synchronization time might be unacceptable.

The third approach is to move the data out of redirected folders and into the user profile—but to exclude the folders from roaming. Then, implement another mechanism that synchronizes or backs up the data in the folders to appropriate network locations on a configurable schedule. Our video-streaming company, for example, could create a folder for each user (%userprofile%Streaming- VideoProjects) and exclude it from users’ roaming profiles, then use a scheduled task to back the folder up to the network every few days. The Windows Administration Resource Kit has a script that does just that—and the script works on all current versions of Windows. You can deploy the script as a logon or startup script or as a scheduled task, and it uses Robocopy to synchronize the local store with a network folder at a given frequency— once a week, for example. In Part 1, I recommended a Backups folder in the physical and DFS namespace; that folder is specifically designed to store a network backup of files in this “locally accessed” class of data.

UDS to Go
After you’ve moved UDS to network servers, keep in mind that laptop users will need access to data and settings when they’re disconnected from the network. Roaming profiles will ensure that a user’s registry file and AppData folder are available locally. For all the data in the redirected folders, you can use offline files to cache the network data stores for offline access. In fact, Vista and XP clients will automatically cache redirected folders. There are many caveats and nuances that affect the design and implementation of offline files. I’ll go over the most important.

  csccmd /DISCONNECT:\contoso.com  users%username%documents    csccmd /DISCONNECT:”\contoso.com  users%username%desktop”

Tip of the Iceberg
A UDS management framework can be quite complicated, not only because of the complexity and idiosyncrasies of the involved technologies but also because you have to creatively address two data scenarios—unwanted data and locally accessed data—that Windows technologies don’t adequately support.

Microsoft’s documentation thoroughly details the steps necessary to implement the individual technologies with which to manage UDS. Unfortunately, very little documentation exists to help you support the varied classes of data in your enterprise. This article should help you overcome and avoid common implementation pitfalls, and if you still need help, I strongly encourage you to dive into Chapter 3 of the Windows Administration Resource Kit for comprehensive guidance toward a UDS management framework.