Docu33617 White Paper VNX Home Directory A Detailed Review

White Paper
EMC VNX Home Directory

A Detailed Review
Abstract
This paper provides an overview of the VNX Home Directory
feature. VNX gives system administrators the ability to configure
powerful rules that automate 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.
March 2015
Copyright 2015 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.5
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
The VNX Home Directory approach ..................................................................................... 9
Stored mappings .......................................................................................................... 11
Process for matching user credentials against database entries ....................................... 12
Home Directory database search: In detail ................................................................... 12
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 ........................................................... 19
Security considerations .................................................................................................... 20
Setting the Home Directory path in AD User Profile ........................................................... 22
Spreading users across two or more file systems .............................................................. 23
When <domain,user> values are identical between database entries ............................ 24
When only <domain> is identical between database entries .......................................... 27
Spreading users across two or more Data Movers ............................................................. 27
Replicating Home Directory configurations ....................................................................... 29
Migrating Home Directory configurations from VNX to VNX ............................................... 30
Migrating Home Directory configurations from another vendors array to VNX ................... 30
File Extension Filtering and Quotas ................................................................................... 32
Conclusion ............................................................................................................ 33
Executive summary
Data is vital to the operation of todays businesses: Even small data files generated
every day by individual users can 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 effectively mandate that users store data on faultsensitive 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
administrators, so EMC VNX provides an integrated Home Directory feature that
significantly reduces 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, the system or
domain administrator must:
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
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, you initially set up rules that govern home
directory behavior. To add a user home directory, you then follow this 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.
The Home Directory feature also has important benefits for disaster recovery (DR) and
migration. VNXs CIFS configurations can be replicated to remote sites for DR
purposes, and the home directory database is a replicated configuration component.
Should disaster strike, end users need only to reconnect to the home directory,
eliminating the need to change the Universal Naming Convention (UNC) path.
In migration scenarios, the home directory database and user file systems can be
migrated to the new VNX Data Mover with minimal 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. This simplicity contrasts with the need to manually migrate a CIFS home
directory configuration that includes hundreds or thousands of individual CIFS shares
(one per user). As a companys home directory storage needs grow, migrating to
newer or larger VNX cabinets requires less work than it would otherwise.
VNX for File Operating Environment (OE) 8.1.3.72 introduces a parameter that allows
users to connect to their Home Directory using a \\server\username[$] path while still
being able to use the traditional \\server\HOME path. This new syntax is helpful to
users who are migrating their home directories from another vendors arrays to a VNX.
By supporting the \\server\username[$] path, manual changes from a
\\server\username[$] path to a \\server\HOME path is eliminated. See Migrating
Home Directory configurations from another vendors array to VNX for more
information.
In summary, the VNX Home Directorys benefits are:
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 papers goal is to communicate the business case for VNX Home Directory, as
well as high-level implementation and design considerations of the feature. Specific
implementation details are documented in the VNX Home Directory Management Help
Files and are not be covered here.
To achieve that goal, this paper answers these 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, those considering the purchase of EMC VNX storage, and EMC field
personnel are the intended recipients of this paper.
This audience expected to have a basic understanding of VNX concepts and the
administration of users within a Microsoft Windows Active Directory domain. A basic
understanding of VNX CIFS technology is assumed, although this paper should also
be accessible to those who understand Microsoft CIFS concepts but lack deep
understanding of VNXs CIFS implementation.
Terminology
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. 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 forth.
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 grouped 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. EMC VNX File
CIFS 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.
VNX File CIFS ManagementAn EMC MMC snap-in that provides management
functions for Home Directory, as well as for some other VNX features. (Previously
called Celerra CIFS Management.)
What is VNX Home Directory?

Traditional approaches to CIFS home directory implementation
To understand exactly what VNX Home Directory is and what it does, first consider two
traditional approaches for providing CIFS home directories: shared drive and unique
shares.
Note that this papers examples use a simple subset of a hypothetical user base, and
they show the perspective of three users:
Table 1. Example users and logon names
Full name
Windows logon name
Joanna Smith
MARKETING\jsmith
Mark Fodor
MARKETING\mfodor
Rue Prada
FINANCE\rprada
This example uses a CIFS server called ATLANTA3, assumed to be 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, shown in Figure 1. This implementation is simple 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 advantage of this approach is that it can be extremely easy to
implement if security is not a concern. Some challenges with this approach are:
The creation of each users home directory can be labor-intensive.
Setting permissions on each new home directory can be labor-intensive and

error-prone.
Unless proper security measures are implemented with file
permissions/Access Control Lists (ACLs), one user may be able to see and
perhaps modify another users files. Correctly applying ACLs to home
directories can be a laborious 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.
Figure 1. All users map the same CIFS share in the shared drive approach
Unique shares
The unique shares approach is another common implementation for CIFS home
directories (shown in Figure 2). In this approach, a unique CIFS share is created for
each users home directory. Only the user who 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. Its
drawbacks include:
Creation of all the shares can be labor-intensive.
Creation of the directory that roots each share can be labor-intensive.
Setting permissions on each new share can be labor-intensive and errorprone.
Figure 2. A CIFS share is created for each user in the unique shares approach
The VNX Home Directory approach

VNX Home Directory achieves the benefits of both the shared drive and unique shares
approaches (ease of implementation and high security) while alleviating
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.
VNX Home Directory uses CIFS login information and a database to provide a unique,
secure home directory view to each user. The home directory view users see is
defined by 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 key 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,

allowing the administrator to specify mapping behavior for hundreds or even
thousands of users with a single rule.
For a given CIFS server, each user of the CIFS server connects to
\\[cifs-server]\HOME to access his/her home directory. In other words, all users
connect to the same CIFS share, as depicted in Figure 3.
Figure 3. User mechanism of connecting to VNX with Home Directory feature
All users connect to \\atlanta3\HOME, the location of their home directory. Note that
any shared-drive CIFS solution can provide this functionality, but only 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 were used:
$ dir \\atlanta3\HOME
aapple
jsmith
mfodor
rprada
For example, Joanna Smith could access the contents of Mark Fodors home directory
if the ACLs allow. Yet this behavior is not typically desirable. The alternative unique
shares approach giving each user a dedicated share to map (\\atlanta3\jsmith,
\\atlanta3\mfodor, \\atlanta3\rprada) is also undesirable because it greatly
increases the administrative burden of providing the user home directories.
Changing the requirements extends the example case. A column could be added to
the user table to specify not only the users logon information, but also the file path
that should be exported to the user when connected to the home directory CIFS share.
In other words, the table that specifies that each user should have a unique view
when connected to \\atlanta3\HOME\ is augmented.
Table 2. Users, logon names, and home directory paths
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 the example significantly. All users are connecting to
the same share \\atlanta3\HOME yet each user sees a different set of files and
folders when connected. VNX Home Directory enables exactly this capability, shown
in Figure 4.
10
Figure 4. Logical view built when a user connects to Data Mover with VNX Home
Directory
VNX Home Directorys secure single share model in which all users connect to the
same share yet see unique, private file system views provides noteworthy value
when configuring user profiles in the Active Directory. The Setting the Home Directory
path in AD User Profile section on page 22 offers more information.
Stored mappings
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 this general form:
Table 3. Database table 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.
Table 4. Match criterion table form
Match criterion
domain name
Path
Options
username
When a user like Joanna Smith logs into the CIFS server called atlanta3, the Data
Mover extracts Joannas domain (MARKETING) and username (jsmith) from her login
credentials. The Data Mover uses this information to search the home directory
database; it compares Joannas domain and usernames with the various match
criteria stored in database table. If the Data Mover finds a match, then the specified
11
path will be associated with Joannas CIFS session. If no match is found, then
Joannas CIFS session fails and she is denied login.
In the following sections look more closely at how this process works.
Process for matching user credentials against database entries

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:
Table 5. Database matching criteria
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 it fails to that path, then the Data Mover will
look for the next matching database entry. Since the search algorithm is slightly more
complex than this description allows, it is worth taking a deeper look at the database
search.
Home Directory database search: In detail
Finding a match in the database is not as simple as the first match algorithm.
Rather, the Data Mover searches the entire database top to bottom when looking for a
match, and no single match is used 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 is the one 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.
12
This section uses Joanna as an example to look at the match process. For this
example, Joanna maps \\atlanta3\HOME, and the Home Directory database looks like
the following:
Figure 5. Database matching

After reading the database table from top to bottom, the Data Mover processes the
rows that match in most recently found order. This means that the matches will be
processed in this order:
Table 6. Database matching order
Order
processed
Matching entry
MARKETING
*smith
/home/special/msmith options
/guests
options
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. Assuming 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 the path /guests does exist. Joanna will be allowed to map
\\atlanta3\HOME and her working directory for that session will be /guests.
Recall that this result is not desired; Joannas working directory was to be
/marketing/jsmith. That goal can be achieved by simply changing the order of the
Home Directory database table entries so that the desired entry to apply is found last
and processed first:
13
Table 7. Database matching order flexibility

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 the goal is to spread users across multiple file systems. This white paper
discusses how to spread users across multiple file systems in a subsequent section.
If multiple matches are necessary to implement the home directory rules required for
the organization, then the best practice is to put the more general criteria toward the
top of the database table and more specific criteria toward the bottom of it. This
arrangement allows more specific database entries to be found last and processed
first.
Path syntax
This white paper has established 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> but <domain,user,path>.
Including the path in the key provides 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 is discussed below; 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:
o : Substituted with the username of the user who is connecting to the
HOME share
o <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.
The substitution strings provide enormous flexibility when defining database entries.
Consider the following example:
14
Table 8. Example database entries with substitution strings

Domain
User
Path
Options
a*
/home/<d>/a-c/
options
b*
/home/<d>/a-c/
options
c*
/home/<d>/a-c/
options
d*
/home/<d>/d-f/
options
e*
/home/<d>/d-f/
options
z*
/home/<d>/y-z/
options
FINANCE
/finance/
options
MARKETING
/marketing/
options
20 more
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 match to one of these entries, and
their home directories are arranged into alphabetical buckets (a-c, d-f, etc.) according
to their domain and usernames. For example, if ENGINEERING\ecartman logs in, the
Data Mover will process the database and determine that the home directory is
/home/engineering/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 /finance,
respectively.
Substitution strings provide the ability to avoid having to specify one Home Directory
database entry per user. Instead, you can specify a generic path that contains
substitution strings; the path will then become customized for each user based on
login credentials.
Regular expressions
When defining Home Directory database entries using only alphanumeric characters
and the two supported wild cards (* and .), it can be difficult to encode the
necessary patterns. This challenge might result in an excessive number of database
entries to achieve a goal that should have been relatively simple. VNX Home Directory
solves this problem by leveraging the enormous flexibility of regular expressions to
specify the domain name and username of a database entry.
Consider a scenario where the goal is to divide 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, this goal can be accomplished only by
creating 26 separate database table entries, one for each letter of the alphabet.
15
Table 9. Example entries without Regular Expression use

Domain
User
Path
Options
a*
/homeA-D/<d>/
options
b*
/homeA-D/<d>/
options
c*
/homeA-D/<d>/
options
d*
/homeA-D/<d>/
options
e*
/homeE-H/<d>/
options
18 more
x*
/homeU-X/<d>/
options
y*
/homeY-Z/<d>/
options
z*
/homeY-Z/<d>/
options
Using regular expressions, this set of 26 entries can be consolidated into a set of only
seven and shows how powerful it is to use regular expressions:
Table 10. Example entries using regular expressions
Domain
User
Path
Options
.*
[a-d].*
/homeA-D/<d>/
regexp=Yes
.*
[e-h].*
/homeE-H/<d>/
regexp=Yes
.*
[i-l].*
/homeI-L/<d>/
regexp=Yes
.*
[m-p].*
/homeM-P/<d>/
regexp=Yes
.*
[q-t].*
/homeQ-T/<d>/
regexp=Yes
.*
[u-x].*
/homeU-X/<d>/
regexp=Yes
.*
[y-z].*
/homeY-Z/<d>/
regexp=Yes
Table 11 shows other examples of how regular expressions can be used in the Home
Directory database to simplify Home Directory management:
16
Table 11. 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
While regular expressions can simplify Home Directory management, they should be
used with care. Be sure that the regular expression you use does not unintentionally
match users other than those it is designed to match.
Auto-create
While the combination of regular expressions with Home Directorys single share
model is powerful, its usefulness is diminished if each users home directory must be
manually created. VNX Home Directorys auto-create feature can ensure that home
directories are created automatically as needed by the VNX1.
Auto-create is an option set on the Home Directory database table entry. It tells the
Data Mover to create the users home directory if such a directory does not already
exist. There are several choices for the security applied to these auto-created
directories; see the Security considerations section on page 19 for details. Only the
lowest level token in the home directory path will be created. If the parent container
of the lowest-level token not exist, then the home directory entry will be treated as if it
does not match the login credentials.
File system permissions on the automatically created directory are:

drwxr--r-2 root
bin
17
/homeI-L/
marketing/
In path /homeI-L/<d>/ with autocreate enabled, the lowest level

directory (represented by 
jsmith in this case) will be created
automatically if needed.
jsmith/
Figure 6. Auto-create and the Home Directory path

For example, assume that MARKETING\jsmiths home directory is /homeIL/marketing/jsmith. Also assume that the only matching database table entry for
MARKETING\jsmith specifies a home directory path of /homeI-L/<d>/ 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 /homeIL/marketing. 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 (/homeIL/marketing/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 EMC VNX File CIFS Management MMC
Snap-in, a tool that runs on Microsoft Windows operating systems and plugs into the
Microsoft Management Console (Figure 7). Refer to the MMC Snap-in help files for
more information.
The Scope of the Home Directory section 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 EMC VNX File CIFS Management
MMC Snap-in2. 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.
The EMC VNX File CIFS Management MMC Snap-in is available on EMC Online Support.
18
Figure 7. EMC VNX File CIFS Management MMC Snap-in

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 can 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 EMC VNX File CIFS
Management MMC Snap-in (Figure 7). The special HOME CIFS share is 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?
You configure the Home Directory at the Data Mover or Virtual Data Mover level. Thus,
the home directory service can be enabled or disabled independently on each Data
Mover and Virtual Data Mover.
Each VNX Data Mover or Virtual Data Mover has its own Home Directory database. All
users logging in to the HOME share on the primary Data Mover will share a database.
However, users logging into a Virtual Data Mover share a different home directory
database. Users connecting to two different CIFS servers on the same Data Mover or
Virtual Data Mover share the same Home Directory database.
Exporting/importing the Home Directory database

There is 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
19
another Data Movers Home Directory database you can copy the file3 /.etc/homedir
from one Data Mover to another.
Security considerations
In the most common and secure configuration, the VNX Home Directory allows each
user to access only his/her own home directory, as defined by the rules configured in
each home directory database on each Data Mover. You should take special care to
ensure that the rules defined by 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.
The VNX Home Directory gives you greater control over who can access automaticallycreated home directories. This higher degree of control is accomplished using 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 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
ensure that you achieve the desired result.
A third setting is also available. This setting places the UNIX root user as the owner of
each Home Directory folder and the EVERYONE group is given full control. This third
setting 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\Flags
The server_file Control Station command can be used to retrieve and upload this file.
20
Figure 8. 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 different groups of CIFS users
require different auto-create security policies, those groups can be segregated onto
different VDMs. 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 created automatically or manually are unaffected by this registry
setting.
The following is a detailed description of the three options for Home Directory
security:
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).
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 users home
directory, an administrator or user with take ownership privileges must 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 that user 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.
21
0x2 Any new home directory folder is created with root as the owner and
allows full privileges to the EVERYONE access control entry (ACE).
NOTE: When using the setting 0x1, you should exercise special care. Understand fully
the implications of permissions and ACL inheritance. In particular, the inheritance of
the CREATOR OWNER ACL limits permissions to newly created files and folders
inside a users home directory folder to the user who 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. It will not be accessible to the user who owns the home directory. This
is because there is no ACL in the home directories ACL that specifically grants
permission to that user (instead, it is the CREATOR OWNER ACL).
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 directory4 (Figure 9). In a traditional unique shares home directory scenario,
each user has a unique home directory network path. For example, the path shown in
Figure 9 might be \\atlanta3\rprada if using the unique shares approach. With each
user who added to the Active Directory, you must specify the unique path of users
home directory in that users profile.
VNX Home Directory removes this burden because all users of a CIFS server connect
to the same path. This is precisely why in Figure 9 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 with 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.
If the home directory field is set in the AD User Profile, then Windows will take the following actions when the user logs in to a
domain member computer:
Map the home directory and assign it to the specified network drive
Set the HOMEDRIVE, HOMEPATH, and HOMESHARE user environment variables
4
22
Figure 9. Setting the home directory in an Active Directory

Figure 9 shows how to set the user home directory using the Active Directory Users
and Computers MMC snap-in. The home directory can also be set using 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
Spreading users across two or more file systems

In certain scenarios, you might want 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, splitting the home
directory users between two or more file systems may yield 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.
23
Billing/chargeback Spreading users across two or more file systems can help
track the capacity used by each set of users. Tracking use can be helpful when
parts of an 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 on page 12 and Path syntax on page 14 that say regarding the
database key. The database key for the Home Directory database is <domain, user,
path> and in the case of multiple entries that match on <domain, user> the
matches are searched backward until an entry with a viable/matching path is found.
This behavior enables users to be spread among multiple file systems.
Two options are available for spreading users among multiple file systems:
1. Create two or more entries where <domain, user> are 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.
To understand spreading users further, consider examples using the two MARKETING
domain users from this papers examples. In this case, Joanna Smith and Mark Fodor
will be on different file systems.
Table 12. Spreading users on different file systems
Full name
Windows logon name
Home Directory path
Joanna Smith
MARKETING\jsmith
/marketing1/jsmith
Mark Fodor
MARKETING\mfodor
/marketing2/mfodor
When <domain,user> values are identical between database entries

If the username and user domain must be identical across home directory entries,
then (in most cases) it is necessary to create the home directories manually in the file
systems. The auto-create feature will not produce the desired result.
The home directory database may look like the following:
24
Table 13. Example home directory entries

Domain
User
Path
Options
MARKETING
/marketing2/
auto-create=no
MARKETING
/marketing1/
auto-create=no
A user would manually create the following directories in the marketing1 and
marketing2 VNX file systems:
/marketing1/jsmith
/marketing2/mfodor
When Joanna Smith maps \\atlanta3\HOME, both entries will match her user domain
and username. Recall that the Data Mover database search takes the last match and
attempts to find the specified path. In this case, the last match has the
path=/marketing1/. Since /marketing1/jsmith exists, no further search is needed.
Joannas home directory will be /marketing1/jsmith.
When Mark Fodor maps \\atlanta3\HOME, both 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/. Since
/marketing1/mfodor does not exist, the Data Mover will look at the next-to-last
match: path=/marketing2/. Since /marketing2/mfodor exists, no further search is
needed. Marks home directory will be /marketing2/mfodor.
Given this description, it is not difficult to predict what would happen if auto-create
were enabled on these database entries. The last match (the one with
path=/marketing1/) is the first examined and with auto-create enabled the Data
Mover would simply create a /marketing1/mfodor directory for Mark rather than
processing the second-to-last match. This behavior would effectively put all users on
the same file system (/marketing1), which is undesirable.
With that caution in mind, the creation of a third directory can be beneficial.
Table 14. Example directory structure to account for users without Home Directories
Domain
User
Path
Options
MARKETING
/marketing3/
auto-create=yes
MARKETING
/marketing2/
auto-create=no
MARKETING
/marketing1/
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. Home directories will
automatically be created for them on /marketing3 if they do not already exist.
25
This approach is often the least convenient from an administrative perspective, but it
is necessary when 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, the experience of a real-world VNX customer is helpful:
Situation
A school has two sets of users: teachers and students. Both teachers and students
log into the same Windows domain. Teachers receive much larger quota allocations
than students, so their home directories are stored in a different path from the path
for 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?
Analysis
Perhaps the most important piece of information in 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. In other words, the <domain,username> portion
of the Home Directory entry will be identical if multiple entries are required.
It is also clear that the user base must be distributed as groups across multiple file
systems or across multiple paths within the same file system. As a result, multiple
Home Directory entries are required, one for each distinct path.
Like most schools, the student-teacher ratio is fairly large at this school, 20 students
for every one teacher (20:1). The following Home Directory configuration would
perhaps be the most efficient configuration possible.
Table 15. Home Directory configuration for school example
Domain
User
Path
Options
SCHOOL
/homedirs/students/ auto-create=yes
SCHOOL
/homedirs/teachers/
auto-create=no
Note that this configuration 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/) 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 autocreate is enabled on the second matching entry. Thus, the administrator does not
have to manually create home directories for students.
26
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. The administrator
can later rectify the situation by simply moving that home directory to
/homedirs/teachers.
When only <domain> is identical between database entries
Looking at an alternative approach reveals that, using the auto-create feature, it is
possible to 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 rest of
the usernames begin with l through z. This fact would allow an administrator to
put half of the 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:
Table 16. Example auto-create for home directory database
Domain
User
Path
Options
MARKETING
[l-z].*
/marketing2/
MARKETING
[a-k].*
/marketing1/
auto-create=yes,
regexp=yes
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, and it works best when the login names
that comprise the user base have specific string attributes that allow them to be
grouped into distinct sets. In this 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, you may want to spread the home directory users of a single
domain across more than one Data Mover or CIFS server as shown in Figure 10. Some
of these scenarios include:
27
Performance In domains with a large number of users or with heavy I/O loads,
putting all home directory users on the same Data Mover may not be feasible from
a performance standpoint. In this case, the I/O load can be spread across Data
Movers by spreading the user base across those Data Movers.
Capacity In environments where the individual user home directories are very
large, it may be necessary to spread users across multiple backend storage
systems that are connected to different VNX cabinets.
Location In geographically distributed domains, it may be necessary to spread

users across two or more Data Movers. Spreading users across Data Movers (and
VNX cabinets) may allow for storing 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 across two or more Data Movers may help
to manage billing/chargeback. For example, if each department in the
organization is charged internally for one Data Mover, it can be helpful to put the
users of each department on the Data Mover it pays for.
Figure 10. Users can be spread across Data Movers by connecting them to different
CIFS servers
Because each Data Mover and Virtual Data Mover has its own Home Directory
database, the task of spreading users across two or more Data Movers is easy. Simply
direct users to the correct Data Mover (via a CIFS server) when they attempt to map
their home directory. This direction requires preparation to decide which Data Mover
28
each user should use and to ensure the users profile reflects the UNC path to that
Data Mover.
Replicating Home Directory configurations

CIFS Replication (using Virtual Data Movers) can be used to replicate Home Directory
environments between VNX cabinets. This replication can specify the amount of data
change required between delta-set transfers. When the primary/source site is lost in a
disaster or taken down for maintenance, the secondary site can be brought up with all
Home Directory services functioning as before. In such an event, CIFS users will lose
their CIFS sessions, but they will be able to reconnect to the same UNC path (for
example, \\atlanta3\HOME) without realizing they are connecting to a different
location. Figure 11 illustrates this replication technique.5
When using CIFS Replication with Home Directory, keep these best practices in mind:
Replicate between cabinets located in different geographic locations if the 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 the destination Virtual Data Mover are
identical to those used on the source Virtual Data Mover.
Ensure that the network interface names used on the destination Virtual Data
Mover are identical to those used on the source Virtual Data Mover. IP addresses
can be different on the destination Data Mover.
EMC advises the testing of Home Directory replication plan prior to implementing it on production data.
29
Figure 11. CIFS Replication of Home Directory configuration

For more information on VDM Replication, please see the white paper titled Virtual
Data Movers on EMC VNX located on EMC Online Support.
Migrating Home Directory configurations from VNX to VNX

VNX Home Directory configurations can be migrated easily to other VNX cabinets.
Simply migrate the user file systems that contain the home directories and manually
copy the homedir database to the new cabinet. This capability is particularly useful
when upgrading a VNX cabinet or redistributing workload among VNX cabinets.
Further, the use of VNX File System Migration (also known as CDMS) or other
supported migration technologies when migrating Home Directory file systems will
minimize end-user downtime.6
Migrating Home Directory configurations from another vendors array to VNX

Home Directory configurations on another vendors array can be migrated easily to a
VNX array. With VNX for File OE version 8.1.3.72 or later, users can connect to a
\\server\username[$] path which will direct them to their home directory. This
capability allows home directories on other vendors arrays, which use this path
mapping, to be migrated to VNX without extra configuration.
6
EMC advises you to test your Home Directory migration plan prior to implementing it on production data.
30
This capability is especially helpful in the case where the users have local
applications, such as built in synchronization and embedded links. Those
applications will not have to be manually updated on each individual users account
after the migration. This capability is the same for shared network devices, such as
scanners, printers, and fax devices.
Without this path mapping, manual remediation would be needed to modify each
users configuration to a \\server\HOME path. Users will still be able to map to the
traditional \\server\HOME path, though. As seen in Figure 12, users can connect to
either \\server\HOME or \\server\username[$] to get to their home directory since
both paths point to the same place.
Figure 12. User mechanism of connecting to VNX

The new \\server\username[$] home directory connections are enabled by default on VNX. The
username support can be disabled using a registry called UsernameSupported on each VDM
(Figure 13). Note that this registry can be set differently on each VDM. The registry is found
through the following path:
HKEY_LOCAL_MACHINE/Software/EMC/Homedir/UsernameSupported
31
Figure 13. Setting registry setting for username support on home directories
The following is a description of the two options that are available for the
UsernameSupported registry:
0x0 Disables the ability of Home Directories to be connected using the

//server/username[$] path. Home Directories can still be connected using
//server/HOME.
0x1(default) Enables Home Directories to be connected by both

//server/HOME and //server/username[$] paths.
File Extension Filtering and Quotas

File Extension Filtering blocks the creation of files on CIFS shares when the files have
a prohibited extension. The Quotas feature allows 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 can work seamlessly with Home Directory.
Consider a situation where the goal is to prevent creation of files with the .mp3
extension on \\atlanta3\HOME. To achieve this goal, the following file could be
created:
\\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, the following file could be created:
\\atlanta3\HOME\c$\.filefilter\mp3@home
32
Conclusion
VNX Home Directory feature can significantly ease the administrative pain of
providing home directories for CIFS users. It eliminates the need to manually create
and manage CIFS home directory shares, and it can also eliminate the need to
manually create each user home directory.
Home Directory provides sufficient flexibility for you to 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 simple 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 VNX File System Migration 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.
33

Docu33617 White Paper VNX Home Directory A Detailed Review

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Docu33617 White Paper VNX Home Directory A Detailed Review

Hochgeladen von

Copyright:

Verfügbare Formate

White Paper

EMC VNX Home Directory

Copyright 2015 EMC Corporation. All Rights Reserved.

Part Number H2283.5

EMC VNX Home Directory

What is VNX Home Directory? ................................................................................... 7

How do I manage Home Directory? ......................................................................... 18

EMC VNX Home Directory

EMC VNX Home Directory

Significantly reduced administrative costs around home directory

Simpler, more reliable disaster recovery

What is Home Directory?

How does Home Directory work?

How do I manage Home Directory?

EMC VNX Home Directory

EMC VNX Home Directory

What is VNX Home Directory?

Windows logon name

The creation of each users home directory can be labor-intensive.

Setting permissions on each new home directory can be labor-intensive and

EMC VNX Home Directory

Creation of all the shares can be labor-intensive.

Creation of the directory that roots each share can be labor-intensive.

Setting permissions on each new share can be labor-intensive and errorprone.

EMC VNX Home Directory

The VNX Home Directory approach

It provides a unique, secure home directory view to each user without

It automates most of the traditional home directory management duties by

It has a flexible language for specifying home directory mapping rules,

Figure 3. User mechanism of connecting to VNX with Home Directory feature

EMC VNX Home Directory

Windows logon name Home directory path

Joanna Smith MARKETING\jsmith

EMC VNX Home Directory

EMC VNX Home Directory

Process for matching user credentials against database entries

EMC VNX Home Directory

Figure 5. Database matching

EMC VNX Home Directory

Table 7. Database matching order flexibility

It must begin with a forward / or backward slash \ character.

EMC VNX Home Directory

Table 8. Example database entries with substitution strings

EMC VNX Home Directory

Table 9. Example entries without Regular Expression use

EMC VNX Home Directory

Does not match

All users in the domains

Users in any other

All users in all domains whose

All users in all domains that

File system permissions on the automatically created directory are:

EMC VNX Home Directory

In path /homeI-L/<d>/<u> with autocreate enabled, the lowest level

Figure 6. Auto-create and the Home Directory path

How do I manage Home Directory?

Managing home directory entries

EMC VNX Home Directory

Figure 7. EMC VNX File CIFS Management MMC Snap-in

Enabling the Home Directory service

Scope of the Home Directory feature

Exporting/importing the Home Directory database

EMC VNX Home Directory