Best Practices for Managing User Data and Settings, Part 2

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% Documents\StreamingVideoProjects. 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.

• Vista and XP support the encryption of the offline files cache, adding a layer of security to user data on the road. See “Using EFS with Offline Files” (InstantDoc ID 47624) for more information.
• Consider disabling the automatic caching of redirected folders on desktop systems. You probably don’t want the conference room computer to cache the redirected folders of every user who logs on to it.
• By default, XP systems will scan all files in offline folders to determine what has changed and what needs to be synchronized at logoff. If you have thousands of files cached, this scanning can take forever. XP can use a different algorithm to track files as they’re changed, making logoff synchronization significantly more efficient. Use Group Policy to disable the Synchronize All Offline Files Before Logging Off policy setting, which you’ll find in Administrative Templates, Network, Offline Files of both User Configuration and Computer Configuration. This option is equivalent to the Synchronize All Files Before Logging Off option on the Offline Files tab of the Control Panel Folder Options applet. This approach works well when you’re primarily or exclusively using offline files to make user data (as opposed to shared data) available offline.
• Consider removing the list of blocked file types when you’re using Offline Files to cache user data. Check out the Microsoft article “Error message: ‘Files of this type cannot be made available offline’” for details.
• Folders for which you’ve used registrybased redirection to redirect won’t be made automatically available offline. You can “push” these files offline into users’ caches by using the Administratively Assigned Offline Files policy setting, which you’ll find under User Configuration, Administrative Templates, Network, Offline Files.
• Provide XP users a way to force themselves offline when connected over a mediocre connection. If an XP user connects to the corporate network over a VPN, Offline Files might decide that the connection is “good enough” and attempt to work from the network copies of cached files. It might even try to synchronize over the VPN. Microsoft Product Support Services (PSS) can provide you with Csccmd (csccmd.exe), a command-line tool for managing Offline Files. The tool supports a /DISCONNECT switch, which can force a namespace offline so that users work from the locally cached copy. Create a batch file on the user’s desktop that he or she can double-click to stay offline while connected over the VPN. Here’s an example of the batch file:

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

• The functionality and performance of Vista’s Offline Files is so vastly improved over that of XP that you should have very few problems supporting the offline use of UDS for Vista users.

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.

End of Article

   Previous  1  2  [3]  Next