Best Practices for Managing User Data and Settings, Part 1

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 \\server01\users$\dholme\Documents Finance\excelfile.xls that must be changed to \\server02\users$\dholme\Documents Finance\excelfile.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.com\Users). 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: \\namespace users\username\foldername (e.g., \\contoso .com\users\dholme\desktop and \\contoso .com\users\dholme\profile). 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 \\servername\Users$ username\Data\foldername path as the target, through the Users$ share that allows caching. The profile folders use the \\servername\Profiles$ username\Profile 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 \\domain\users data\%username%\data\foldername (e.g., \\contoso.com\users\data\jfine data\documents). 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 .com\users\data) 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.