With folder-redirection policies managing
all user data stores for Vista users, and
a combination of folder-redirection policies
and registry-based redirection for XP users,
you can unify the experience of users who
roam between computers running different
OSs. Regardless of where the user logs on, he
or she will have access to all data stores.
Roaming Profiles Manage Ntuser.dat and AppData
Now that you’ve redirected all user data stores
and Favorites, you’re left with the two remaining
stores of user settings: the user’s registry
hive and the AppData folder—%userprofile% Application Data (in XP) and %userprofile%\AppData\Roaming (in Vista). These stores,
which I refer to as “normal settings,” are best
managed with roaming profiles.
Roaming profiles got a bad rap in the days
of Windows NT 4.0. Even in the 21st century,
many organizations have had less-than-ideal
experiences with roaming profiles, citing the
size and synchronization of profiles as particularly
problematic. However, properly implemented
roaming profiles work very well.
Profile synchronization is quite efficient.
At logon and logoff, Windows compares the
server copy of the profile with the locally
cached copy and synchronizes only files that
have changed. However, if your Documents
folder has thousands of files, scanning those
files to identify what has changed can take
a long time, creating a perception of slow
logon and logoff processes. Additionally, the
Desktop or Documents folders might have
one or more large files. For example, PST files
can be huge. Each time Microsoft Outlook
touches a PST file, it changes that file’s timestamp
so that, at logoff, Windows considers it
a changed file even when the contents of the
PST file haven’t changed. At each logoff, then,
your PST files get copied to the profile on the
server. Therefore, in most environments, it
isn’t appropriate to allow users’ desktops and
Documents folders to roam.
These two examples illustrate the problem
of enabling roaming profiles without
careful thought and design. It’s important to
exclude certain folders from roaming. Redirected
folders are automatically excluded
from roaming, so once you redirect the Documents, Desktop, and other folders, the
number of files in your roaming profile—and
particularly the number of large files—will be
significantly reduced.
You can use Group Policy to exclude
additional folders from roaming. The Group
Policy setting you require is Exclude directories
in roaming profiles, located under User
Configuration, Administrative Templates,
System, User Profiles. Because this setting
is user-based, you could have different folders
roaming based on a user’s role. You can
specify folder names relative to the user
profile, such as AppData\Roaming\Microsoft
\Windows\Cookies. Figure 2 shows an
example that excludes the Cookies folder on
both Vista and XP.
A well-designed UDS framework will
use roaming profiles as the mechanism for
managing a user’s registry file—the ntuser
.dat file in the root of the profiles. This file
contains a number of critical settings and
customizations that affect a user’s Windows
experience, and it’s absolutely worth managing
to achieve your mobility, availability, and
resiliency requirements. The only practical
way to meet the requirements for the registry
file is a roaming profile—even if the only item
in the roaming profile is ntuser.dat.
I also recommend that you allow the
AppData folder—specifically, the \AppData Roaming folder in Vista and the \Application
Data folder in XP—to roam. It’s possible
to redirect AppData, but in my experience,
many poorly coded applications won’t function
correctly if AppData is redirected. Some
applications also have trouble if, on a laptop,
AppData is cached using offline files and
network connectivity causes the computer to
transition between online and offline modes.
I think your goal should be to redirect App-
Data eventually but not until you have time
to thoroughly test all applications. So, the
practical recommendation is to use roaming
profiles to manage AppData until you can
confidently redirect it.
Vista appends a .V2 extension to the
folder that hosts the user’s roaming profile.
If you configure a user’s profile path as \\ namespace\%username%\profile, the user’s
XP profile will be in the Profile folder, and
the user’s Vista profile will be in the Profile.
V2 folder—automatically. Due to significant
differences in registry and AppData structure,
there’s no way to unify those two settings
stores for Vista and XP users. They will be separate. That’s another good reason for
ensuring that roaming profiles manage only
those two stores—any other stores in the
roaming profile will be duplicated and separate
for a user’s XP and Vista profile.
When a user’s roaming profile contains
only the registry file and the AppData folder,
the profile should be very small. On my heavily
overloaded laptop, my roaming profile is
only 40MB. Profile synchronization has less
data to scan and copies only changed files,
so the process is fast, efficient, and reliable.
Manage the Location of
Unwanted Data
Most IT organizations aren’t expected to
manage users’ personal music collections.
I’m using music as an example of what I call
“unwanted data”—a class of data that isn’t
subject to your business’s security, mobility,
availability, and resiliency requirements.
You might identify other types of data as
unwanted: users’ personal files, pictures,
or email archives from non-business email
accounts. This is one class of data for which
Microsoft doesn’t a provide straightforward
management solution. Vista makes it easier
to manage unwanted data classes if they parallel
specific media types: The Vista Pictures,
Music, and Videos folders are already at the
root of the user profile. For other classes of
unwanted data (e.g., personal files), you’ll still
need this workaround.
To ensure that unwanted data isn’t stored
on network servers, you must first move
the data so that it’s not within the scope of
a redirected folder. For example, XP’s My
Music folder is a subfolder of My Documents.
Because My Documents will be redirected,
you must relocate the My Music folder. Create
a first-level folder underneath the root of the user profile—%userprofile%\Music, for
example—and move the data to that folder.
Next, determine how to redirect applications
and the user to the new location. In
the case of a media folder such as Music,
you can use registry-based redirection to
redirect applications to the new location.
You can even use the RegistryRedirection.
adm Group Policy administrative template
to implement the registry-based redirection.
Just point the My Music folder to your custom
folder (%userprofile%\Music). You must also
ensure that users can find the custom folder
for the unwanted data. Shortcuts placed at
the data folder’s old location do the trick.
Continue on Page 3
)
Register
stalar March 28, 2008 (Article Rating: