White Paper

Abstract
This paper provides an overview of the VNX Home Directory
feature. VNX gives its system administrators the ability to
configure powerful rules that automates the process of creating
and assigning home directories to users. Whether an
organization has hundreds of users or tens of thousands, this
feature helps relieve the management burden of providing CIFS
home directories for the organizations users.

October 2011

EMC VNX HOME DIRECTORY
A Detailed Review

2 White Paper Title


















Copyright 2011 EMC Corporation. All Rights Reserved.

EMC believes the information in this publication is accurate as
of its publication date. The information is subject to change
without notice.

The information in this publication is provided as is. EMC
Corporation makes no representations or warranties of any kind
with respect to the information in this publication, and
specifically disclaims implied warranties of merchantability or
fitness for a particular purpose.

Use, copying, and distribution of any EMC software described in
this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC
Corporation Trademarks on EMC.com.


Part Number H2283.2

3 White Paper Title
Table of Contents
Executive summary ....................................................................................... 4
Introduction ................................................................................................. 5
Audience ............................................................................................................................ 5
Terminology ....................................................................................................................... 6
What is VNX Home Directory? .......................................................................... 7
Traditional approaches to CIFS home directory implementation ......................................... 7
Shared drive................................................................................................................... 7
Unique shares ................................................................................................................ 8
VNX Home Directorys approach ......................................................................................... 9
Process for matching user credentials against database entries ....................................... 12
Home Directory database search: In detail ................................................................... 13
Path syntax ...................................................................................................................... 14
Regular expressions ......................................................................................................... 15
Auto-create ...................................................................................................................... 17
How do I manage Home Directory? ................................................................. 18
Managing home directory entries ..................................................................................... 18
Enabling the Home Directory service ................................................................................ 19
Scope of the Home Directory feature ................................................................................ 19
Exporting/importing the Home Directory database ........................................................... 20
Security considerations .................................................................................................... 20
Setting the Home Directory path in AD User Profile ........................................................... 22
Spreading users across two or more file systems.............................................................. 24
When <domain,user> are identical between database entries ....................................... 25
When only <domain> is identical between database entries .......................................... 28
Spreading users across two or more Data Movers............................................................. 28
Replicating Home Directory configurations ....................................................................... 29
Migrating Home Directory configurations.......................................................................... 31
File Extension Filtering and Quotas ................................................................................... 32
Conclusion ................................................................................................ 32
References................................................................................................. 32



4 White Paper Title
Executive summary
Data is vital to the operation of todays businesses even the small data files that are
generated every day by individual users can sometimes have costly repercussions if
they are lost or damaged. Yet, by failing to provide a protected storage location on the
network for this data many companies are effectively mandating that users store data
on fault-sensitive disks in laptop or desktop computers.
CIFS home directories can be combined with fault-tolerant storage (such as VNX) to
provide safe, secure, network-accessible storage for this user-level data.
Management of these home directories can be burdensome to the storage
administrator, so EMC VNX provides an integrated Home Directory feature that
significantly reduces the administrative burden by shifting the directory and share
management to VNX.

In the typical business environment user home directories are not shared each
home directory is intended for only one specific user. Consequently, it is up to the
system or domain administrator to:

1. Determine where the users home directory will exist.
2. Create a directory on the file server to act as the users home directory.
3. Create a CIFS share to give the user access to the home directory.
4. Secure the CIFS share.
5. Set the home directory field of the users profile on the domain controller to
reflect the appropriate home directory location.
VNXs Home Directory feature eliminates the need for three of these steps. Further, it
significantly eases the burden of the last step because the contents of the home
directory field in the user profile can be the same for all users.
When using VNXs Home Directory feature the administrator initially sets up some
rules that govern home directory behavior. To add a user home directory, the
administrator then follows this significantly less burdensome sequence of steps:
1. Determine where the users home directory will exist.
2. Set the home directory field of the users profile on the domain controller to
reflect the appropriate home directory location.
Other very important benefits of the Home Directory feature are seen when looking at
disaster recovery (DR) architectures and migration scenarios. VNXs CIFS
configurations can be replicated to remote sites for DR purposes, and the home
directory database is one component of the configuration that is replicated. Should
disaster strike, end users need only to reconnect to the home directory there is no
change in the UNC path.

5 White Paper Title
In migration scenarios, the home directory database and user file systems can be
migrated to the new VNX Data Mover with little downtime. Once the home directory
database has been migrated, users can simply be referred to the new VNX Data Mover
where each user will see his home directory as it was on the old VNX Data Mover.
Contrast this with the need to manually migrate a CIFS home directory configuration
that includes hundreds or thousands of individual CIFS shares (one per user). As the
home directory storage needs of your company grow, you can migrate to newer or
larger VNX cabinets with less work than would otherwise be required.
Let us recap VNX Home Directorys benefits:
Significantly reduced administrative costs around home directory
management
Simpler, more reliable disaster recovery
Simpler, more reliable home directory migrations to VNX or between VNX Data
Movers (intra- and extra-cabinet)
Introduction
This white papers goal is to communicate the business case for VNX Home Directory,
as well as some high-level implementation and design considerations of the feature.
Specific implementation details are documented in the VNX Home Directory
Management Help Files and will not be covered here.
To achieve that goal, this white paper will attempt to answer the following questions:
What is Home Directory?
How does Home Directory work?
How do I manage Home Directory?
How can I take Home Directory beyond its basic functionality and use it in
advanced ways?
Audience
EMC customers, people who are considering the purchase of EMC VNX storage, and
EMC field personnel are the intended recipients of this paper.
Readers of this paper are expected to have a basic understanding of VNX concepts
and the administration of users within a Microsoft Windows NT4 or Windows
2000/2003/2008 Active Directory domain. A basic understanding of VNX CIFS
technology is assumed, although this white paper should also be digestible by those
who understand Microsoft CIFS concepts but lack an understanding of VNXs CIFS
implementation.

6 White Paper Title
Terminology
VNX File/Celerra Management: Also called Celerra CIFS Management, it is an EMC
MMC snap-in that provides management functions for Home Directory, as well as for
some other VNX features.
Common Internet File System (CIFS): A file sharing technology for IP networks that is
the primary file sharing technology for Microsoft Windows operating systems and that
has gained traction with other operating systems in recent years. CIFS is based on the
Server Message Block (SMB) protocol.
Disaster recovery (DR): The recovery of business IT operations after the primary data
site is lost to a disaster. Such disasters may include power outages, natural disasters
such as wind damage or flooding, terrorist attacks, and so on.
Home Directory: A dedicated, network-attached (CIFS) file storage resource; typically
one per user and mapped as a network drive at login.
Microsoft Management Console (MMC): An extensible Microsoft application
(mmc.exe) that provides the ability to create a custom system management
dashboard (or view). Many Microsoft Windows features are managed via the MMC;
for example, Computer Management (compmgmt.msc) is an MMC application.
MMC Snap-in: A plug-in to the Microsoft Management Console. These plug-ins can be
arbitrarily gathered together into a single, customized MMC view by using the
mmc.exe /console command. Microsoft provides many such plug-ins, but third-party
vendors such as EMC may also provide plug-ins to manage their own products. VNX
File/Celerra Management is an example of an MMC Snap-in that is provided by EMC.
Virtual Data Mover (VDM): A virtual container of VNX file systems and CIFS servers. A
VDM is treated as a unit, and it can be moved between Data Movers within a VNX
cabinet and replicated to other Data Movers for disaster recovery.


7 White Paper Title
What is VNX Home Directory?
Traditional approaches to CIFS home directory implementation
To understand exactly what VNX Home Directory is and what it does, we first take a
look at two traditional approaches for providing CIFS home directories: shared drive
and unique shares.
Note that the examples will use a simple subset of a hypothetical user base, and they
will show the perspective of the following three users:
Table 1 Users and logon name
Full name Windows logon name
Joanna Smith MARKETING\jsmith
Mark Fodor MARKETING\mfodor
Rue Prada FINANCE\rprada
We will use a CIFS server called ATLANTA3. Assume that it is joined to the MARKETING
domain. Also assume that the MARKETING domain has a bidirectional trust
relationship with the FINANCE domain so that members of both domains can
authenticate with ATLANTA3.
Shared drive
One common implementation for CIFS home directories is the shared drive
implementation, as shown in Figure 1. This is a very simple implementation both
conceptually and in practice: One large shared drive (CIFS share) is created and
shared by many users. Each user has a folder/directory on the shared drive that is
used as the users home directory. The big win with this approach is that it can be
extremely easy to implement if security is not a concern. Some problems that can
be found with this approach are:
Creation of each users home directory can be labor-intensive
Setting permissions on each new home directory can be very-labor intensive
and is prone to error.

Unless proper security measures are implemented with file permissions/ACLs,
one user may be able to see and perhaps modify another users files.
Correctly applying ACLs to home directories can be a labor-intensive and error-
prone process.
The user must navigate into a subdirectory of the share to find his own home
directory
This problem can be prevented by specifying the full path to a users home
directory in his Windows profile. For example, in Figure 1 mfodors profile
would contain the path \\atlanta3\shared\mfodor in his home directory
settings.

8 White Paper Title

Figure 1. The shared drive approach to home directory management - all users map
the same CIFS share.
Unique shares
A second common implementation for CIFS home directories is the unique shares
approach, as shown in Figure 2. In this approach, a unique CIFS share is created for
each users home directory. Only the user that owns the home directory is permitted
to map the share. This approach is more secure than the shared drive
implementation, but it suffers from being much more difficult to implement. Some of
its big drawbacks include:
Creation of all the shares can be very labor-intensive.
Creation of the directory that roots each share can be very labor-intensive.
Setting permissions on each new share can be very labor-intensive and is
prone to error.

9 White Paper Title

Figure 2. In the unique shares approach to home directory management, a CIFS share
is created for each user. This share is rooted at the user's home directory.
VNX Home Directorys approach
VNX Home Directory offers a way to achieve the benefits of both the shared drive and
the unique shares approaches (ease of implementation and high security) while
eliminating most of the administrative burden. It accomplishes this in two ways:
It provides a unique, secure home directory view to each user without
requiring a unique share for each user.
It automates most of the traditional home directory management duties by
moving responsibility for those duties from the administrator to the VNX
server.
Home Directory uses CIFS login information and a database to provide a unique,
secure home directory view to each user. The home directory view that is seen by any
given user is defined by the rules stored in the Home Directory database. A VNX
administrator configures the database to meet the specific needs of the organization.
VNX Home Directory eases home directory administration in two big ways:
It enables users to see their unique home directory views while logging into
the same CIFS share.
It has a flexible language for specifying home directory mapping rules that
allows the administrator to specify mapping behavior for hundreds or even
thousands of users with a single rule.

10 White Paper Title
For a given CIFS server, each user of the CIFS server will connect to
\\[cifs-server]\HOME to access their home directory. In other words, the
users all connect to the same CIFS share, as depicted in Figure 3.


Figure 3. User mechanism of connecting to VNX with Home Directory feature. All three
users are logging in to the same CIFS share.
Each of the users has connected to \\atlanta3\HOME the location of their home
directory. Note that any shared drive CIFS solution could provide this functionality if
all three users are allowed to see the same files and directories when connected to
\\atlanta3\HOME. For example, in Figure 3 all three users would see the same
directory listing of \\atlanta3\HOME if a shared drive implementation is used:

$ dir \\atlanta3\HOME
aapple

jsmith
mfodor
rprada


Joanna Smith could access the contents of Mark Fodors home directory if the ACLs
allow. This is not typically desirable behavior. The alternative unique shares approach

11 White Paper Title
giving each user a dedicated share to map (\\atlanta3\jsmith,
\\atlanta3\mfodor, \\atlanta3\rprada) is also not desirable because
it greatly increases the administrative burden of providing the user home directories.

Now, let us change the requirements just a bit. We will add a column to the user table
that specifies not only the users logon information, but also the file path that should
be exported to the user when they connect to the home directory CIFS share. In other
words, we will specify that each user should have a unique view when connected to
\\atlanta3\HOME.\

Table 2 Users and logon name and home directory path
Full name Windows logon name Home directory path
Joanna Smith MARKETING\jsmith /marketing/jsmith
Mark Fodor MARKETING\mfodor /marketing/mfodor
Rue Prada FINANCE\rprada /finance/rprada

This latest requirement changes things significantly. All users are connecting to the
same share \\atlanta3\HOME yet each user sees a different set of files and
folders when connected. This is exactly what VNX Home Directory enables us to do,
and Figure 4 illustrates it.


12 White Paper Title
Figure 4. Logical view that is built when a user connects to Data Mover with VNX
Home Directory. All three users log in to the same share, yet each sees a different
directory.
VNX Home Directorys secure single share model in which all users can connect to
the same share yet see unique, private file system views provides a significant
amount of administrative value when configuring user profiles in the Active Directory.
The Setting the Home Directory path in AD User Profile section has more information.
VNX Home Directory uses a database to store mappings between users and file
system paths. Each Data Mover, or Virtual Data Mover, has a database table where a
row in the table takes the following general form:
Match criterion Path Options
A match criterion consists of two patterns: One pattern specifies a domain name and
the other pattern specifies a username.
Match criterion Path Options
domain name username
When a user for example, Joanna Smith logs in to the CIFS server called atlanta3
the Data Mover will extract Joannas domain and username from her login credentials.
In Joannas case, the domain name is MARKETING and the username is jsmith. This
information is used by the Data Mover to search the home directory database
Joannas domain and usernames are compared with the various match criterion
stored in each row of the database table. If a match is found, then the specified path
will be associated with Joannas CIFS session. If no match is found, then Joannas
CIFS session fails to be established and she is denied login.
In the following sections we will look more closely at how this process works.
Process for matching user credentials against database entries
Recall from the discussion above that login information (domain name, username) is
compared against the match criterion of database entries to find the users home
directory path. Visually, this database simply looks like:
domain name username path options
domain name username path options

domain name username path options
At the most basic level, the Data Mover consults the database and looks for a match
based on domain name and username. If it finds such a match, then it looks for the
path specified by the matching entry. If that path is not found then the Data Mover
will look for the next matching database entry. In reality, however, the search
algorithm is slightly more complex than this description, so we will now take a deeper
look at how the database is searched.

13 White Paper Title
Home Directory database search: In detail
Finding a match in the database is not quite as simple as the first match algorithm
described above. Rather, the actual behavior is that the entire database is searched
top to bottom when looking for a match and that no single match is tried until all
matches have been identified.
When the Data Mover finds multiple matches in the database it will attempt to use
(try) the most recently found match first. (Note that the most recently found
matching entry will be the one that was found farthest down the database table.)
Should the Data Mover be unable to locate the path specified by that matching entry
it will take the next most recently found match and try it, and so on.
We will use Joanna as an example to look at this match process pictorially. Assume
that she maps \\atlanta3\HOME and the Home Directory database looks like the
following:

After reading the database table from top to bottom, the Data Mover is going to
process the rows that match in most recently found order. This means that the
matches will be processed in this order:
ORDER
PROCESSED
MATCHING ENTRY
1 MARKETING *smith /home/special/msmith options
2 * * /guests options
3 MARKETING jsmith /marketing/jsmith options
The Data Mover will look at Matching Entry #1 first, so it will search for the path
/home/special/msmith. Let us assume that the path /home/special does not exist on
the Data Mover. Matching Entry #1 will be discarded because the home directory
/home/special/msmith does not exist. Matching Entry #2 (/guests) will be processed
next and let us assume that the path /guests does exist. Joanna will be allowed to
map \\atlanta3\HOME and her working directory for that session will be /guests.

FINANCE * /finance options
MARKETING jsmith /marketi ng/jsmith options
MARKETING h* /marketi ng-h options
* * /guests options

MARKETING *smith /home/special/msmith options

Database
Read
Top-to-
Bottom
These rows match

14 White Paper Title
Recall that this is not the behavior we wanted we wanted Joannas working directory
to be /marketing/jsmith. We can achieve that by simply changing the order of the
Home Directory database table entries so that the entry that we want to apply to
Joanna is found last (and processed first):
Domain User Path Options
FINANCE * /finance options
MARKETING h* /marketing-h options
* * /guests options

MARKETING *smith /home/special/msmith options
MARKETING jsmith /marketing/jsmith options
In practice, it is best to ensure that only one database table entry/row will match each
user unless you want to spread your users across multiple file systems. We will
discuss how you spread users across multiple file systems later in this white paper.
If multiple matches are necessary to implement the home directory rules required for
your organization, then the best practice is to put the more general criteria toward the
top of the database table and the more specific criteria toward the bottom of the
database table. This allows the more specific database entries to be found last and
processed first.
Path syntax
Recall from previous sections that Home Directory database entries are matched to a
users login credentials based on the value of the domain name and username.
However, the actual database key is not <domain,user> it is <domain,user,path>.
Including the path in the key gives you the flexibility to specify multiple matching
entries in the database so that users can be spread across multiple file systems.
Spreading users across multiple file systems will be discussed later; it is only
mentioned here to emphasize the reason the path field is part of the key in the Home
Directory database.
A path has the following general syntax:
It must begin with a forward / or backward slash \ character.
It may contain two special strings that are substituted by the Data Mover upon
processing the database entry:
<u>: Substituted with the username of the user who is connecting to the HOME
share
<d>: Substituted with the domain name of the user who is connecting to the
HOME share
It must be specified relative to the root of the Data Mover or Virtual Data
Mover.

15 White Paper Title
The substitution strings give you an enormous amount of flexibility when defining
your database entries. Consider the following example:
Domain User Path Options
* a* /home/<d>/a-c/<u> options
* b* /home/<d>/a-c/<u> options
* c* /home/<d>/a-c/<u> options
* d* /home/<d>/d-f/<u> options
* e* /home/<d>/d-f/<u> options
20 more
* z* /home/<d>/y-z/<u> options
FINANCE * /finance/<u> options
MARKETING * /marketing/<u> options
The first 26 entries in this table (only six are shown here) are catch all entries
users of all domains other than FINANCE and MARKETING will be matched to one of
these entries, and their home directories are arranged into alphabetical buckets (a-c,
d-f, and so on) according to their domain and usernames. For example, if
ENGINEERING\ecartman logs in, the Data Mover will process the database and
determine that his home directory is /home/engineeri ng/d-f/ecartman.
The last two entries in the table catch all users in the MARKETING and FINANCE
domains, associating those users with directories under /marketing and /fi nance,
respectively.
Substitution strings give you the ability to avoid having to specify one Home Directory
database entry per user. Rather, you can specify a generic path that contains
substitution strings and the path will then become customized for each user based
on their login credentials.
Regular expressions
When defining Home Directory database entries using only alphanumeric characters
and the two supported wild cards (* and .) it can sometimes be very difficult to
encode the patterns you need. This often results in the use of an excessive number of
home directory database entries to achieve something that should have been
relatively simple. VNX Home Directory solves this problem by giving you the enormous
flexibility of using regular expressions when specifying the domain name and
username of a database entry.
Consider a scenario where we want to divide our users alphabetically among different
file systems such that groups of four adjacent letters are on the same file system (a-d,
e-h, and so on) Without regular expressions we can accomplish this only by creating
26 separate database table entries one for each letter of the alphabet.


16 White Paper Title

Domain User Path Options
* a* /homeA-D/<d>/<u> options
* b* /homeA-D/<d>/<u> options
* c* /homeA-D/<d>/<u> options
* d* /homeA-D/<d>/<u> options
* e* /homeE-H/<d>/<u> options
18 more
* x* /homeU-X/<d>/<u> options
* y* /homeY-Z/<d>/<u> options
* z* /homeY-Z/<d>/<u> options

This set of 26 database entries can be consolidated into a set of only seven database
entries by using regular expressions:
Domain User Path Options
.* [a-d].* /homeA-D/<d>/<u> regexp=Yes
.* [e-h].* /homeE-H/<d>/<u> regexp=Yes
.* [i-l].* /homeI-L/<d>/<u> regexp=Yes
.* [m-p].* /homeM-P/<d>/<u> regexp=Yes
.* [q-t].* /homeQ-T/<d>/<u> regexp=Yes
.* [u-x].* /homeU-X/<d>/<u> regexp=Yes
.* [y-z].* /homeY-Z/<d>/<u> regexp=Yes

Clearly the ability to specify regular expressions is powerful.

17 White Paper Title
Table 3 shows other examples of how regular expressions can be used in the Home
Directory database to simplify Home Directory management:


18 White Paper Title
Table 3. Examples of regular expression use in the Home Directory database
Domain name Username Matches Does not match
[ENGINEERING|FINANCE] .* All users in the domains
ENGINEERING and FINANCE
Users in any other
domain
.* [wdc|moc].* All users in all domains whose
names are prefixed with the
contractor designations wdc
(Widget Development Corp) or
moc (Manufacturing
Operations Consultants)
Users whose
names are not
prefixed with one
of the two
designations
.* .* [2] [0-9]
{3}.*
All users in all domains that
have four sequential numeric
characters in the username
where the first digit is 2; for
example, joe2006
Users whose
names do not
have the required
sequence of
digits


Regular expressions should be used to simplify your Home Directory management.
However, care must be taken to consider whether a given regular expression may
unintentionally match users other than those you designed it for.
Auto-create
While the combination of regular expressions with Home Directorys single share
model is very powerful, its usefulness is diminished if you must manually create each
users home directory. VNX Home Directorys auto-create feature can ensure that
home directories are created automatically as needed by the VNX
1
.
Auto-create is an option you set on the Home Directory database table entry. It tells
the Data Mover to create the users home directory if it does not already exist. There
are several choices for the security applied to these auto-created directories (See the
Security Considerations section for more information). Only the lowest level token
in the home directory path will be created. Should the parent container of that lowest
level token not exist, then the home directory entry will be treated as if it does not
match the login credentials.


1
File system permissions on the automatically created directory are:
drwxr--r-- 2 root bin

19 White Paper Title

Figure 5. Auto-create and the Home Directory path
For example, assume that MARKETING\jsmiths home directory is /homeI-
L/marketi ng/jsmith. Also assume that the only matching database table entry for
MARKETING\jsmith specifies a home directory path of /homeI-L/<d>/<u> and that the
auto-create option is set on that entry. When jsmith attempts to map the HOME share
the Data Mover will create the jsmith directory if it does not already exist in /homeI-
L/marketi ng. If /homeI-L/marketing does not already exist then jsmith will be unable
to map the HOME share because the Data Mover will not create both the parent
directory (/homeI-L/marketing) and the home directory itself (/homeI-
L/marketi ng/jsmith). Only the lowest level token in the path (the home directory itself)
will be created.

How do I manage Home Directory?
VNX Home Directory is managed through the VNX File/Celerra Management Data
Mover Management MMC Snap- in
2
which is a tool that runs on Microsoft Windows
operating systems and plugs in to the Microsoft Management Console (Figure 6).
Refer to the Data Mover Management help files for more information. These help files
are available from within the Data Mover Management MMC Snap-in or from the VNX
Documentation CD.

Scope of the Home Directory provides important information about the granularity at
which the home directory service can be controlled.
Managing home directory entries
Home directory entries are managed through the VNX File/Celerra Management Data
Mover Management MMC Snap- in.
2
You can add, delete, and modify entries. You can
also reorder the database by dragging entries and dropping them at the bottom of the
database.


2
The Celerra Data Mover Management MMC Snap- in is available by installing the VNX File/Celerra CIFS Management tool f rom
the VNX Applications and Tools CD.
/homeI-L/
marketing/
jsmith/
In path /homeI-L/<d>/<u> with auto-
create enabled, the lowest level
directory (represented by <u>
jsmith in this case) will be created
automatically if needed.

20 White Paper Title

Figure 6. VNX File/Celerra Management's Data Mover Management MMC Snap-In. This
snap-in is used to manage the Data Mover's home directory database. After
connecting to a CIFS server on the Data Mover you can manage Home Directory.
Note that the Data Mover Management Snap-in operates by connecting to a VNX CIFS
server. You must therefore create a CIFS server and connect the Data Mover
Management Snap-in to that CIFS server before you are able to modify Home Directory
service status or manage the Home Directory database.
Enabling the Home Directory service
The Home Directory service can be started and stopped through the VNX File/Celerra
Management Data Mover Management MMC Snap- in (Figure 6). The special HOME
CIFS share will be exported automatically when the Home Directory service is running.
Scope of the Home Directory feature
It is important to know the scope of the Home Directory feature. Does it apply to the
whole Data Mover? Does it apply to all Data Movers in a VNX cabinet? Or does it have
some other scope?
Home Directory is configured at the Data Mover or Virtual Data Mover level. Thus, the
home directory service can be enabled/disabled independently on each Data Mover
and Virtual Data Mover.
Further, each VNX Data Mover or Virtual Data Mover has its own Home Directory
database. Thus, all users logging in to the HOME share on the primary Data Mover
will share a database, but users logging in to a Virtual Data Mover will share a
different home directory database. Users connecting to two different CIFS servers on
the same Data Mover or Virtual Data Mover will share the same Home Directory
database.

21 White Paper Title
Exporting/importing the Home Directory database
There is currently no graphical user interface for exporting and importing the Home
Directory database. However, to give one Data Mover or Virtual Data Mover an
identical copy of another Data Movers Home Directory database you can copy the
file
3
/.etc/homedir from one Data Mover to the other.
Security considerations
In the most common and secure configuration, the VNX Home Directory feature allows
each user the ability to access only their own home directory, as defined by the rules
configured in each home directory database on each Data Mover. Special care should
be taken to ensure that the rules defined by the system administrators do not allow
unintended access violations. The default behavior is the most secure and does not
need to be changed if the owner-only access model is desired.
For information on defaults and behavior when upgrading from a code version
without this functionality (prior to 5.6.50) to a code version with this functionality
The VNX home directory feature gives you more control over who has access to
automatically-created home directories. It does this through the Access Control Lists
(ACLs) that are applied to these directories. Specifically, a registry flag offers two
security options for automatically-created home directories:
1. Restrict ACL to the owner. (This is the default value.)
2. Set ACL based upon inherited values.

With both of these settings, if the parent ACL is set up correctly, the inheritance
model ensures that the owner of the new home directory is the Windows user rather
than UNIX root. When using inheritance, you must be careful when building the
inherited ACL to make sure that you achieve the desired result.
A third setting for this flag is also offered to provide compatibility with the behavior
prior to release 5.6.50. This setting has the UNIX root user as the owner of each Home
Directory folder and the EVERYONE group is given full control.
This flag applies only to new auto-created home directories. It does not apply to
manually created or existing home directories.
This security feature is controlled through a registry entry belonging to the CIFS
Server:
HKEY_LOCAL_MACHINE\Software\EMC\Homedir\Flag

3
The server_file Control Station command can be used to retrieve and upload this file.

22 White Paper Title

Figure 7. Setting the registry entry for auto-created home directories

The registry entry is global to each Data Mover and Virtual Data Mover, meaning that
every CIFS Server on the Data Mover shares the same setting, and every CIFS server on
a Virtual Data Mover (VDM) shares the same setting. (A VDM has its own registry,
which is distinct from the Data Movers registry.) .) If you have different groups of CIFS
users that for some reason require different auto-create security policies, you can
segregate those groups of users onto different VDMs to achieve this. This registry
entry can be set from any Windows host in the CIFS Servers domain by using the
regedit / regedt32 commands to connect to the CIFS Servers registry.
This setting only applies to new, automatically-created, home directory paths. Paths
that were previously automatically-created or manually created paths are unaffected
by this registry setting.
The following is a detailed description of the three options for Home Directory security
(DART 5.6.50 and later):
0x0 (default) This setting disallows ACL inheritance from the parent folder and
creates the new home directory with the user as the owner (as opposed to root).
Furthermore, only the user/owner has full privileges. No other privileges are set,
which effectively locks out every other user from the directory. To access the

23 White Paper Title
users home directory, an administrator or user with take ownership privilege
will need to take ownership of the home directory and modify the ACL as required.
0x1 This setting creates the new home directory with the current user as the
owner (as opposed to root) and gives them full privileges. Inheritance from the
parent folder is allowed and dictates any further permissions applied on the home
directory folder. This setting may revert to the 0x0 behavior if the ACL inheritance
from the parent folder has not been configured. Using inheritance requires care in
building the inherited ACL so that the desired result is achieved.
0x2 This setting provides functionality identical to what is provided with the
5.6.47.11 code release. Any new home directory folder is created with root as the
owner and allows full privileges to the EVERYONE ACE.
NOTE: When using the setting 0x1, particular care must be taken to understand the
implications of permissions and ACL inheritance. In particular, the inheritance of the
CREATOR OWNER ACE will limit permissions to newly created files and folders
inside a users home directory folder to the user that created the file or folder. For
example, a file created by the Domain Administrator (assuming the permission to do
so exists in the ACL) in another users home directory will be owned by the Domain
Administrator and will not be accessible to the user that owns the home directory.
This is because there is no ACE in the home directories ACL that specifically grants
permission to that user (instead, it is the CREATOR OWNER ACE.)
Setting the Home Directory path in AD User Profile
Active Directory Users and Computers allows you to assign a network path as a users
home directory
4
(Figure 8). In a traditional unique shares home directory scenario
each user has a unique home directory network path. For example, the path shown in
Figure 8 might be \\atlanta3\rprada if using the unique shares approach. With each
user that is added to the active directory, the administrator must specify in that users
profile the unique path of his home directory.
VNX Home Directory removes this burden because all users of a CIFS server connect
to the same path. This is precisely why in Figure 8 Rue Prada is connecting to
\\atlanta3\HOME rather than \\atlanta3\rprada. Other users such as Mark Fodor
would also connect to \\atlanta3\HOME. Thus, it is possible for the Active Directory
administrator to create a template user account that has the home directory
predefined in the profile, and then copy that user account to add a new user. The
home directory path will be copied from the template account and the administrator
will not need to set it manually.

4
If the home directory field is set in the AD User Profile then Windows will do the following when the user logs in to a domai n
member computer:
Map the home directory and assign it to the specified network drive
Set the HOMEDRIVE, HOMEPATH, and HOMESHARE user environment variables

24 White Paper Title


Figure 8. Setting the home directory in an Active Directory user's profile
is done through the AD User Properties dialog box. Access this dialog
box from Active Directory Users and Computers right-click the user
and choose Properties from the context menu.

Figure 8 shows how to set the user home directory using the Active Directory Users
and Computers MMC snap-in. However, the home directory can also be set via the net
user command on the cmd.exe command line. The net user command can be
particularly useful in scripting changes to the home directory configuration of existing
user accounts. The following example shows how the home directory would be set to
\\atlanta3\HOME for the user rprada:
net user rprada /homedir:"\\atlanta3\HOME

25 White Paper Title

Spreading users across two or more file systems
In certain scenarios it may be desirable to spread the home directory users of a single
domain across more than one file system. Some of these scenarios include:
Performance: In large domains or under heavy I/O conditions, you may find that
splitting your home directory users between two or more file systems yields better
performance.
Capacity: In large domains or in environments where user home directories are
very large, it may be necessary to spread users among two or more file systems to
avoid encountering file system capacity limitations.
Billing/chargeback: Spreading users among two or more file systems may help
you to keep track of the capacity used by each set of users. This can be helpful in
situations where parts of the organization are billed internally for their users file
system usage, or for ISVs that are providing storage hosting services for external
customers.
VNX Home Directory makes it relatively easy to spread users across two or more file
systems. Recall the discussions in Process for matching user credentials against
database entries and Path syntax that said the database key for the Home Directory
database is <domain, user, path> and that in the case of multiple entries that match
on <domain, user > the matches are searched backward until an entry that has a
viable/matching path is found. This is the behavior that enables you to spread users
among multiple file systems.
Two options are available for spreading users among multiple file systems:
1. Create two or more entries where <domain, user> is identical between database
entries, but <path> is different. This option requires caution when using the
auto-create functionality.
2. Create two or more entries where only <domain> is identical between database
entries, but <user> and <path> both differ between database entries. This option
enables unrestricted use of the auto-create functionality.
Let us look at some concrete examples using our two MARKETING domain users from
the earlier examples, only this time Joanna Smith and Mark Fodor will be on different
file systems.
Full name Windows logon name Home Directory path
Joanna Smith MARKETING\jsmith /marketing1/jsmith
Mark Fodor MARKETING\mfodor /marketing2/mfodor

26 White Paper Title

When <domain,user> are identical between database entries

If we want to keep the username and user domain identical across our home directory
entries, then in most cases we will need to manually create the home directories in
the file systems because the auto-create feature will not produce the desired
behavior.
Our home directory database may look like the following:
Domain User Path Options

MARKETING * /marketing2/<u> auto-create=no
MARKETING * /marketing1/<u> auto-create=no
We manually create the following directories in the marketing1 and marketing2 VNX
file systems:
/marketing1/jsmith
/marketing2/mfodor
When Joanna Smith maps \\atlanta3\HOME both of these entries will match her user
domain and username. Recall from Home Directory database search: In detail that the
Data Mover will take the last match and try to find the specified path. In this case, the
last match is the one with path=/marketing1/<u>, and since /marketi ng1/jsmith
exists no further search is needed /marketing1/jsmith will be used as Joannas
home directory.
When Mark Fodor maps \\atlanta3\HOME both of these entries will match his user
domain and username. The Data Mover will take the last match and try to find the
specified path. In this case, the last match is the one with path=/marketing1/<u>,
and since /marketing1/mfodor does not exist, the Data Mover will look at the next-to-
last match path=/marketi ng2/<u>. Since /marketi ng2/mfodor exists no further
search is needed /marketing2/mfodor will be used as Marks home directory.
Now you can see what would happen if we were to enable auto-create on these
database entries the last match (the one with path=/marketing1/<u>) is the first
examined and with auto-create enabled the Data Mover would simply create a
/marketi ng1/mfodor directory for Mark rather than processing the second-to-last
match. This would effectively put all users on the same file system /marketing1
which is not what we wanted.



27 White Paper Title
With that caution in mind, we could do something like this:
Domain User Path Options

MARKETING * /marketing3/<u> auto-create=yes
MARKETING * /marketing2/<u> auto-create=no
MARKETING * /marketing1/<u> auto-create=no

In this case, all users who do not have home directories pre-created on /marketing1
or /marketing2 will fall through to the third-to-last match and home directories will
automatically be created for them on /marketing3 if they do not already exist.

This approach is often the least convenient approach from an administrative
perspective, but it is necessary when your usernames lack specific string attributes
that would allow them to be grouped into well-defined sets. Because this approach is
perhaps the most difficult to understand, let us look at a concrete, real-world example
from a VNX customer:
The situation
A school has two sets of users teachers and students. Both teachers and students
log in to the same Windows domain. Teachers get much larger quota allocations than
students, so their home directories are stored in a different path than the student
home directories. There is no mechanism by which a teacher can be distinguished
from a student when examining the username. What would the recommended home
directory configuration look like?
The analysis
Perhaps the most important piece of information we learned from reading the
description of this customers situation is that there is no mechanism by which the
username or domain can distinguish a student from a teacher. This tells us that the
<domain,username> portion of the Home Directory entry will be identical if
multiple entries are required.
We also learned that the user base must be distributed as groups across multiple file
systems or across multiple paths within the same file system. This tells us that
multiple Home Directory entries are required one for each distinct path.


28 White Paper Title
Now, we will assume this is like most schools in that the student-teacher ratio is fairly
large let us say 20 students per one teacher (20:1). The following Home Directory
configuration would perhaps be the most efficient configuration possible:
Domain User Path Options

SCHOOL * /homedirs/students/<u> auto-create=yes
SCHOOL * /homedirs/teachers/<u> auto-create=no
Note that what this does is it requires the administrator to manually create teacher
home directories in the path /homedirs/teachers/. When a teacher logs in, her
directory will be found by the first matching entry under the path
/homedirs/teachers/.
When a student logs in, his directory will be not be found by the first matching entry
(/homedirs/teachers/<u>) because it does not exist there. Home Directory then will
look at the second matching entry and will find the students home directory in the
path /homedirs/students. If the student does not already have a home directory
under /homedirs/students, then one will be created automatically because auto-
create is enabled on the second matching entry. Thus, the administrator does not
have to manually create home directories for students.
Since the student-teacher ratio is 20:1 the administrator needs only to manually
create home directories for approximately 1/21 of the user base (the teachers).
Should he forget to create a teachers home directory then the teacher will
automatically be given a home directory in /homedirs/students, and the administrator
can later rectify the situation by simply moving that home directory to
/homedirs/teachers.



29 White Paper Title
When only <domain> is identical between database entries
Let us look at an alternative approach that allows us to use the auto-create feature so
that we can avoid manually creating home directories.
Assume that half of the users in the MARKETING domain have usernames beginning
with one of the letters from the alphabetical set of letters a through k. The other
half of users have usernames beginning with l through z. We can utilize this fact to
put half of our users on /marketing1 and the other half on /marketing2 while also
taking advantage of the auto-create functionality.
Such a home directory database might look like:
Domain User Path Options

MARKETING [l-z].* /marketing2/<u> auto-create=yes,
regexp=yes
MARKETING [a-k].* /marketing1/<u> auto-create=yes,
regexp=yes
When Joanna Smith maps \\atlanta3\HOME only the last of these entries will match
her user domain and username. If this is her first time mapping the share, then the
Data Mover will see that /marketing1/jsmith does not exist and will create it to use as
Joannas home directory.
When Mark Fodor maps \\atlanta3\HOME only the second to last of these entries will
match his user domain and username. If this is his first time mapping the share, then
the Data Mover will see that /marketing2/mfodor does not exist and will create it to
use as Marks home directory.
This approach is often the most convenient approach, and it works best when the
login names that comprise your user base have specific string attributes that allow
them to be grouped into distinct sets. In our example that attribute is the value of the
first character of the username. Regular expressions can then be used to specify
match criteria based upon these attributes.
Spreading users across two or more Data Movers
In certain scenarios it may be desirable to spread the home directory users of a single
domain across more than one Data Mover or CIFS server as shown in Figure 9. Some
of these scenarios include:
Performance: In domains with a large number of users or with heavy I/O loads,
you may find that putting all of your home directory users on the same Data Mover
is not feasible from a performance standpoint. In this case, you can spread the I/O
load across Data Movers by spreading your user base across those Data Movers.
Capacity: In environments where the individual user home directories are very
large it may be necessary to spread the users across multiple backend storage
systems that are connected to different VNX cabinets.

30 White Paper Title
Location: In geographically distributed domains it may be necessary to spread
users among two or more Data Movers. Spreading users across Data Movers (and
VNX cabinets) may allow you to store each users home directory data closer to
the users physical location, thus providing the user with a higher level of network
performance.
Billing/chargeback: Spreading users among two or Data Movers may help to
manage billing/chargeback. For example, if each department in the organization
is charged internally for one Data Mover you may want to put the users of each
department on the Data Mover it is paying for.

Figure 9. Users can be spread across Data Movers by connecting them to different
CIFS servers.
Recall that each Data Mover and Virtual Data Mover has its own Home Directory
database that makes the task of spreading users across two or more Data Movers
easy: Simply direct each user to the correct Data Mover (via a CIFS server) when they
attempt to map their home directory. This requires preparatory planning to decide
which Data Mover each user should utilize, and ensuring that the UNC path to that
Data Mover is reflected in the users profile.
Replicating Home Directory configurations
CIFS Replication (using Virtual Data Movers) can be used to replicate Home Directory
environments between VNX cabinets. This is an asynchronous replication in which
you can specify the amount of data change required between delta-set transfers.

31 White Paper Title
When the primary/source site is lost in a disaster or taken down for maintenance the
secondary site can be brought up and all of the Home Directory services will function
as before. CIFS users will lose their CIFS sessions, but they will be able to reconnect
to the same UNC path (for example, \\atlanta3\HOME) without ever realizing that they
are connecting to a location different than before. Figure 10 illustrates this replication
technique.
5

When using CIFS Replication with Home Directory, keep in mind the following best
practices:
Replicate between cabinets that are located in different geographic locations if
your goal is to protect against site outages.
Ensure that the mount path of all replicated Home Directory user file systems is
the same on both the source and destination Virtual Data Movers. If the mount
path is different on the destination Virtual Data Mover then the paths in the Home
Directory database may be incorrect after failover.
Ensure that the CIFS server names used on your destination Virtual Data Mover are
identical to those used on your source Virtual Data Mover.
Ensure that the network interface names used on your destination Virtual Data
Mover are identical to those used on your source Virtual Data Mover. IP addresses
can be different on the destination Data Mover.


5
EMC advises you to test your Home Directory replication plan prior to implementing it on production data.

32 White Paper Title

Figure 10. CIFS Replication of Home Directory configuration. After failover, users see
no difference in the way they connect to the CIFS server to map home directories.
For more information about using CIFS Replication, please see the document
Replicating VNX CIFS Environments.
Migrating Home Directory configurations
VNX Home Directory configurations can be migrated easily to other VNX cabinets by
migrating the user file systems that contain the home directories and manually
copying the homedir database to the new cabinet. This capability is particularly
useful when upgrading your VNX cabinet or redistributing workload among VNX
cabinets. Further, the use of Celerra Data Migration Service (CDMS) or other
supported migration technologies when migrating Home Directory file systems will
minimize end-user downtime.
6



6
EMC advises you to test your Home Directory migration plan prior to implementing it on production data.

33 White Paper Title

File Extension Filtering and Quotas
File Extension Filtering is a feature that allows you to block the creation of files on
CIFS shares when the files have a prohibited extension. The Quotas feature enables
you to control the total amount of storage that can be consumed by users and/or
groups in a file system. Both the File Extension Filtering and the Quotas features will
work seamlessly with Home Directory.
Consider a situation where we want to prevent creation of files with the .mp3
extension on \\atlanta3\HOME. To achieve this, we can simply create the
following file:
\\atlanta3\HOME\c$\.filefilter\mp3@home@atlanta3
To prevent creation of .mp3 files on all HOME shares (for all CIFS Servers) on a Data
Mover, we would instead create the following file:
\\atlanta3\HOME\c$\.filefilter\mp3@home
Conclusion
VNX Home Directory is a feature that can significantly ease the administrative pain of
providing home directories for CIFS users. It completely eliminates the need to
manually create and manage CIFS home directory shares, and it can even eliminate
the need to manually create each user home directory.
Enough flexibility is provided by Home Directory that you can implement highly
customized rules based on regular expressions, and it may require only a few rules to
spread all of your domain users over a single file system or several file systems. This
flexibility makes it very easy to scale your Home Directory implementation from
hundreds to thousands or even tens of thousands of CIFS users.
Further, when Home Directory is combined with VDM Replication a Home Directory
environment can be seamlessly replicated to a remote site for disaster recovery.
When combined with CDMS or other migration technologies, Home Directory
environments can easily be migrated to other VNX cabinets.
With an understanding of the Home Directory concepts that were outlined in this
white paper, you can create an efficient and effective home directory solution for your
organization.
References
CDMS Version 2.0 for NFS and CIFS Users Guide: on Powerlink

VNX Home Directory Management Help Files: Found on the VNX Documentation CD or
by invoking Help from within Unisphere


34 White Paper Title
VNX Documentation CD : Search for VNX Documentation CD on Powerlink

Replicating VNX CIFS Environments: Available from Powerlink or the VNX
Documentation CD.