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:

• Security—You must ensure that the data your users create is secure.
• Mobility—Users should have access to their data and settings not only from their desktop PC or personal laptop but also from conference rooms and other computers.
• Availability—When a user gets a new or replacement system, his or her data and settings should be fully available at first logon.
• Resiliency—If a user’s hard disk fails or is stolen, his or her business data and settings shouldn’t be permanently lost.

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.

   Previous  [1]  2  3  Next