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 \\namespace\%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 \ servername\users$\%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 \ server\users$\%username%\data\documents.
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.
Register
