Best Practices for Managing User Data and Settings, Part 1

In recent months, I’ve worked with several clients on projects designed to improve the management of user data and settings (UDS). Insufficiently or incorrectly managed UDS can have a significant negative effect on your IT department’s service delivery. By putting the right pieces in place, you can reduce costs, increase security, enable mobility, improve productivity, and ensure business continuity.

Windows provides most of the pieces: redirected folders, roaming profiles, quotas, file screens, DFS namespaces, encryption, and offline files. All you need to do is add the right people, processes, and supporting scripts and tools. By putting all these pieces together in just the right way, you can create a framework for effectively managing UDS. But it’s not easy—there are many moving parts. And although there’s a slew of documentation about profiles and redirected folders, very little of it deals with the crazy interactions between all these technologies and the various types of data that you need to manage in your enterprise.

In this two-part series, I’ll offer some design guidance to help you create a UDS management framework. I’ll also help you unify UDS management for both Windows Vista and Windows XP users. For some good foundational reading before diving into these best practices, I recommend that you read chapter 3 of the Windows Administration Resource Kit. The chapter goes into far more detail than I have space for here. The resource kit also contains great tools and scripts to help you implement a UDS management framework. (Although the book is part of the Windows Server 2008 Resource Kit, the content also applies to Windows Server 2003 and to Vista and XP clients.)

In this first part of the series, let’s dive into some best practices for the server side of the equation. I’ll look at the physical namespace (i.e., folders and permissions), the SMB namespace (i.e., shares), and the DFS namespace that will give you the most effective back end for UDS management. In Part 2, I’ll look at the client-side components.

Identify Your Business Requirements
First, let’s get some definitions out of the way. User data refers to files created by and necessary for an individual user—items in a user’s Documents folder (My Documents in XP) or on their desktop. Settings refers to everything from a user’s Microsoft Outlook configuration, custom dictionary, quick launch shortcuts, templates, and desktop wallpaper to his or her Microsoft Internet Explorer (IE) Favorites. Windows has a number of data and settings stores for UDS, including My Documents, Desktop, Favorites, AppData, and the ntuser.dat registry file. These data stores can reside physically on the local system, on a network server, or both. For laptop users, in fact, data stores are in both local and network locations, with technologies including offline files and roaming profiles keeping the two locations in sync.

Before you begin designing a UDS management framework, spend some time identifying the business requirements that drive such a project. I suggest that they’ll fall into the following categories:

Preview the Best Practice Design for a UDS Framework
After identifying your strategic requirements, you can begin to design a framework that tackles UDS according to those requirements. Here’s a quick overview of what your UDS framework will comprise.

Redirected folders. Redirected folders ensure that critical stores of user data are located on file servers. Users on Windows clients will continue to access their data in their Documents folder, on their desktop, in their Favorites folder, and in media folders such as Music, Pictures, and Videos. The functionality of redirected folders makes it transparent to users that the physical data stores for those folders are on the network.

Offline files. Laptop users will leverage offline files so that their data is available when they’re disconnected from the network. The offline files cache will be secured with encryption to reduce the risk of data leakage when a laptop is lost or stolen.

Roaming profiles. You’ll use roaming profiles to meet the mobility, availability, and resiliency requirements for users’ registry hives—the ntuser.dat file in the root of their profiles. You’ll also include the App- Data folder in the roaming profile. For reasons I’ll detail in Part 2, although it’s technically possible to redirect AppData, in most scenarios it’s likely that redirection will be a future-state, and until then AppData will be managed as part of the roaming profile. Chances are the registry file and AppData folder are the only two items you’ll use roaming profiles to manage. Users’ profiles will be very small indeed, and for that reason, roaming profiles will effectively support those two settings stores.

DFS namespaces. DFS namespaces will abstract the physical location of user data stores so that users’ data can be managed easily and moved with minimal impact.

Unmanaged data. Classes of data that shouldn’t be stored on network servers (e.g., users’ personal music collections) will be excluded from both redirected folders and roaming profiles so that they remain on the users’ local hard disk.

Quotas and file screens. You can optionally implement quotas and file screens on server data stores to manage the quantity and types of data stored there.

Create the Physical Namespace of Folders for UDS Stores
To support your security, mobility, availability, and resiliency business requirements, the redirected folders and roaming profiles have to go somewhere. The data will end up on a network server. That server must have a folder structure that supports UDS manageability. I recommend the folder structure that Figure 1 shows for each user on the server. Some of the structure’s features might surprise you.

Notice that the structure doesn’t use a flat namespace. Instead, all the typical user data stores—including Desktop and Documents— are contained within a parent folder called Data. You’ll use this Data folder when you decide to implement quotas for user data storage. A user’s quota should be universal: It should apply to data whether it’s stored in the Documents, Desktop, or media folders. To apply a quota to user data stores effectively, those stores must reside under one parent folder. However, you can’t use the user’s top-level folder (e.g., jfine) for that quota, because there are other stores—the Backups and Profiles folders—that shouldn’t be subject to the same quota.

Having the Data folder gives you a management scope—a container that represents all day-to-day user data stores. You can use this folder to apply a quota for the user’s data. You can also use it to scope file screens that prevent certain types of data from being stored on the network. The concepts of quotas and file screens are familiar, and Windows makes them easy to implement and manage in Server 2008 and Windows 2003 R2. Check out the File Server Resource Manager (FSRM) Help documentation for details.

Figure 1 also shows two profile folders: Profile and Profile.V2. Vista appends a .V2 extension to the folder hosting the user’s roaming profile. So, if you configure a user’s profile path as amespace%username%profile, the roaming profile for a user will be in the Profile folder if the user logs on to an XP system, and in the Profile.V2 folder if the user logs on to a Vista system—automatically. Because of significant differences in registry and AppData structure, there’s no way to unify those two settings stores for Vista and XP users. They’ll be separate. That’s another good reason for ensuring that roaming profiles manage only those two stores.

The profile folders are first-level folders, not subject to the quota that is implemented on the Data folder. Profiles shouldn’t be subject to quotas because if the system encounters a quota limit during synchronization, the profile can become corrupted. In Part 2, you’ll see that in the UDS framework, profiles will contain only AppData and the ntuser.dat registry file, so you’ll eliminate profile bloat, manage profile size, and improve synchronization. Profiles simply won’t grow too large, so you’ll be better served by having profiles “quota free.”

The Backups folder solves a business-datamanagement scenario that Windows doesn’t address with redirected folders and roaming profiles. (You’ll see how useful it is in Part 2.) You can also use this folder to archive user-specific data (e.g., old .pst files) that isn’t needed regularly and therefore doesn’t need to be available offline for laptop users. You’ll manage which data goes in Backups and how it gets there with mechanisms other than roaming profiles and redirected folders. Backups isn’t a subfolder of the Data folder, so it can be configured with a quota that’s separate from the quota applied to normal day-to-day data stores.

Above these folders is a single parent folder for the user, and above the user folders is a single parent for all users on the server. In Figure 1, the top-level folder is called Users. Of course, all these folders must be secured according to your organization’s information security policy. On the Users folder, assign the permission System::Allow::Full Control, along with permissions that enable appropriate administrative and support access to user data stores. For example, you can grant a security auditing team Read permission for the user data stores, and you can give the Help desk permission only to the top-level user folders, but not to subfolders. The resource kit offers further information, as well as tools to help you secure the user data folder structure on the server.

One exciting byproduct of setting everything up correctly is that you won’t need to provide any permissions to normal users at the root Users folder. As long as each user has Full Control of his or her individual %username% folder, no permissions at the Users folder level are necessary. The default user right to traverse folders will let the user “jump through” (without accessing) the Users folder, straight to his or her folder. Therefore, users have no permission to look in, browse through, or even see other users’ folders. Now that’s least-privilege security!

There’s a catch: You must provision the folder tree for each user before applying redirected folders and roaming profiles. That is, you must pre-create the folder structure that Figure 1 shows. Again, the resource kit can help you automate the provisioning of user data stores; it even provides a series of folder-provisioning script samples. You can also obtain the scripts from www.intelliem .com/resourcekit.

Create the SMB Namespace of Shared Folders for UDS Stores
SMB namespace is a fancy term for discussing the standard, server-based Universal Naming Convention (UNC) paths to the UDS stores. You’re certainly familiar with paths such as servernameusers$%username%. Such UNCs are navigating to a folder through an SMB namespace.

The correct SMB namespace for a UDS framework requires that the top-level folder, Users, be shared twice. The first share will be used in paths to user data stores. Most organizations share the top-level folder with a hidden share name such as Users$. SMB paths to users’ documents folders, for example, would be serverusers$%username%datadocuments.

On the Users$ share, be sure to assign the Full Control share permission to the group of users who have data stores on the server. The NTFS permissions on the root Users folder and on each user’s root folder will control effective access. Remember that users actually don’t have NTFS permissions on the Users folder, so the Everyone::Allow::Full Control share permission is fine for the Users$ share.

You must also share the Users folder a second time for paths that point to the user’s roaming profile. I recommend a name such as Profiles$. Again, assign the Full Control share permission to the group of users on the server or to the Everyone group. The reason that the Users folder must be shared a second time is that you must disable caching on SMB paths to user profiles. It’s a long story that has to do with a potential conflict between Windows Offline Files and roaming profiles. Caching is enabled by default and should be left on for the Users$ share to support laptop users in the UDS framework. But you must disable caching on the Profiles$ share, as you see in Figure 2. Users—including laptop users—will still get a synchronized copy of their user profile on their local systems by using profile synchronization, which is a separate mechanism from the caching of Windows’ Offline Files feature.

Use DFS Namespaces to Abstract and Present Each User’s Data Stores
The final piece of infrastructure is DFS namespaces—a very important component. If you’ve ever moved a user’s data from one server to another, you know that you have to change a lot. You have to change the user’s roaming profile path and the GPO and registry folder redirection settings. That’s easy enough, but think about all the links within and between documents. For example, think about all the Microsoft Excel worksheets with linked formulas pointing to \server01users$dholmeDocuments Financeexcelfile.xls that must be changed to \server02users$dholmeDocuments Financeexcelfile.xls. That “path migration” is a great deal of work, and most organizations aren’t equipped to thoroughly migrate user data paths, particularly for inter-document links. So they don’t, and productivity is lost.

DFS namespaces, like the other components I discuss in this article, require thoughtful design, but I can recommend the design that Figure 3 shows as a best practice. Figure 3 represents what I call a fully enumerated DFS namespace, in which each UDS store is presented in the DFS namespace. A user is given a first-level folder within a domain-based DFS namespace (e.g., \contoso.comUsers). Below that folder is a single level of subfolders— one for each data and settings store. So, the paths used for roaming profiles and redirected folders are simple: amespace usersusernamefoldername (e.g., \contoso .comusersdholmedesktop and \contoso .comusersdholmeprofile). The namespace abstracts the fact that several data stores are actually subfolders of a parent Data folder on the server. So, the Data folder on the server can manage quotas in the physical namespace on the server without adding complexity to the namespace used for administering UDS.

Each folder in the user’s DFS namespace targets the appropriate folder on the server. The data folders use the \servernameUsers$ usernameDatafoldername path as the target, through the Users$ share that allows caching. The profile folders use the \servernameProfiles$ usernameProfile and Profile.V2 paths as targets, through the Profiles$ share that disables offline files, because roaming profiles have a separate mechanism for synchronization.

Understand Why a Fully Enumerated DFS Namespace Is a Best Practice
Proposing individual DFS namespace folders for each user data store might seem extreme. Many organizations have a simpler DFS namespace, such as the one that Figure 4 shows. Such a DFS namespace can serve a small organization well. Paths to user data stores take the form \domainusers data%username%datafoldername (e.g., \contoso.comusersdatajfine datadocuments). The appearance of data twice isn’t a typo. The first data folder is in the DFS namespace, which targets the Users$ share in the server’s SMB namespace. The %username% folder and the second data folder are in the physical namespace on that server, within the Users$ share.

But even in a small organization, there’s a big problem: This namespace is inflexible. The DFS namespace (e.g., \contoso .comusersdata) targets a fixed SMB namespace (e.g., \server01 users$). If some users’ data stores are moved to another SMB namespace (e.g., \server02 users$), you’ll be stuck rebuilding the DFS namespace. Even worse, you’ll have to do the involved “path migration” for roaming profiles, redirected folders, and all inter-document links. Also, any laptop users would have to have their offline files cache manipulated to avoid a total resynchronization.

You might consider using Figure 3’s namespace down to the user level and avoiding the subfolders for individual data stores. You can get away with that configuration for now, but you’re building in a hard-wired dependency on the physical namespace— Desktop, Documents, and the media folders are all in the Data folder. If you ever need to change your management on the back end, you’ll be stuck again. I’m expecting that, someday, we’ll be able to redirect the Documents store to a SharePoint My Site. That’s “pie in the sky” thinking right now, but by abstracting the location of Documents, I’m hoping to make the migration of individual data stores to other servers or even other technologies a bit smoother down the road. It’s easy enough to provision the DFS namespace for a user with the aforementioned scripts, so why not build the most flexible and forwardlooking namespace for manageability?

These considerations, plus concerns related to the interactions of other components of the UDS framework, make a fully enumerated DFS namespace a best practice. Further details are too much to cover in the space I have here, so be sure to check out the resource kit, which discusses the pros and cons of other DFS namespace structures.

You might be aware that a DFS namespace in Windows 2003 can have only 5000 links. If each user has more than half a dozen folders in the DFS namespace, you’ll be able to support several hundred users in a single namespace. See the resource kit for best-practice designs for more users in Windows 2003 environments: You can work around the limitation with additional domain DFS namespaces that won’t require additional DFS namespace servers. Server 2008 DFS namespaces remove the limit. Ideally, you should provision the DFS namespace for users when you provision the physical folders.

Only the Beginning
This article’s best practices should help you manage the back end of an effective UDS framework. By separating the physical and SMB namespaces that manage the configuration and security of UDS data stores from the presentation of those data stores in a logically organized DFS namespace, you’ll be well prepared to implement the client side. In Part 2, I’ll address roaming profiles, redirected folders, and critical workarounds necessary to solve several business-data scenarios that Microsoft’s native technologies don’t support.

As I mentioned earlier, an effective UDS management framework can be quite complicated— not because of the complexity of the involved technologies but because you must align many individual and sometimes conflicting technologies in a way that supports both your business requirements and the unique characteristics of your users’ data.