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
Register
