2. Putting data protection in place
To put the data protection strategy in place, you need to perform several tasks:
Prepare the central server share(s) and the groups that will support folder redirection.
Enable the Distributed File System to make the share available in all locations (optional).
Enable roaming profiles and exclude specific folders from the profile.
Enable the folder redirection Group Policy Object (GPO).
Test the strategy before applying it to users.
Each operation requires care and structure in its application. The following sections outline how each step is performed.
Preparing for data protection
Because
both folder redirection and roaming user profiles rely on networked
storage, you need to make sure your storage locations will be ready
before you begin the redirection process. Although roaming profiles are
a function of the user account in Active Directory, folder redirection
is a function of Group Policy. In addition, Group Policy can control
how the roaming profile will be managed as well as how profiles are
managed in general.
If you only have a
single, central site, then it will be easy to configure both folder
redirection and roaming profiles. Just direct each to the same network
share to store the contents under folders created for each user in the
organization. If, however, there are multiple sites or locations in
your organization, then you'll have to consider creating redirection
folders in each location. After all, you don't want users to
synchronize folders or profiles over the wide area network (WAN), do
you?
Both systems allow for either central
or regional redirection. Roaming user profiles are the easiest to set
up because they are set as a property of the user account. But with
folder redirection, you need to prepare two elements before you can
support regional users:
You must
prepare special AD groups that will regroup users in each location. In
many cases, you may already have these groups in place. Using groups
allows you to create a single GPO for folder redirection. If you want
to create multiple GPOs, you can create one GPO for each region and
assign them to Organizational Units (OU) that represent the regions and
contain the accounts for the users located in that region.
You need to prepare shared folders in each location.
You
might also want to use this strategy if you want to direct user folders
from different departments to different file servers even if all your
users are in a single location.
Use the
following steps to create the groups in AD and then create the file
shares. You will need Account Operator rights in AD to perform this
task.
Use Active Directory Users and Computers to create the appropriate groups.
Because these groups will contain users, they should be Global Security
groups. For regional folder redirection support, create regional groups
that contain the accounts of all of the users in a given regional site.
For departmental redirection, create departmental groups to contain the
users. In most organizations, groups with this purpose will already
have been created. If not, create them. Use a clear naming convention
to make them easy to identify.
NOTE
When
you work with groups in Active Directory, you should rely on the AGLP
rule. AGLP stands for Accounts which go into Global Groups, which are
then inserted into Local Groups. Finally, Permissions are assigned to
the Local Groups.
Create file shares.
Because users will not be accessing these file shares because they will
access data through folders on their desktops, such as Documents, you
do not need to make these shares visible to users. Therefore, you can
create the shares using the $ character in the name of the share,
effectively hiding it from normal network browsing. Two share
structures are required; one for folder redirection and one for roaming
profiles. Begin with the first.
Create the first share structure.
On a file server will sufficient space for each user, create a
top-level share named FolderRedir$. Set Everyone Full Control in the
share permissions and assign Authenticated Users modify or change
permissions at the NTFS level.
Create the second share structure.
On the same file server, create a top-level share named RoamingProf$.
Set Everyone Full Control in the share permissions and assign
Authenticated Users modify or change permissions at the NTFS level.
Repeat the process if either regional or departmental share structures are required.
Both the required groups and the shares are ready. Proceed to the next step.
Enabling the Distributed File System
This
step is optional and really only applies to organizations that use
remote sites and expect to have to support users roaming from one
office location to another. When users rely on folder redirection and
roaming profiles and move from one office to another during the
performance of their work, they can find themselves in situations where
they need to load their profile from a remote location instead of from
the local network. There is however an easy way to avoid this situation.
Windows
Server 2003 R2 and Windows Server 2008 both include a very powerful
technology called the Distributed File System (DFS). Although DFS is
not new to these versions of Windows Server, its implementation in
these versions has changed so much that it is basically a completely
different product. DFS includes two different components:
DFS Namespaces:
This component is designed to replace the traditional letter-based
network share mapping. Instead of using a traditional universal naming
convention (UNC) shares in the \\servername\sharename format, DFS Namespaces uses domain-based shares in the \\domainname\sharename
format. The file share name is therefore based on the name of the
Active Directory domain instead of on a single server's name.
Domain-based DFS Namespaces are then assigned targets or specific
servers that host a copy of the share. Organizations that have remote
sites assign a target for the share in each site. Each target contains
the same files. Users that move from site to site continue to address
the share through the domain-based UNC but do so through Active
Directory's site identification. They are automatically directed to a
local target for the share, avoiding WAN communications to access data.
DFS Replication:
This component is used to maintain consistency between the contents of
one target with all others. DFS Replication uses delta-based compressed
replication, replicating only changed data blocks from one location to
the other instead of replicating entire files, to keep the target
content up to date.
Together,
these two technologies ensure that users can access the same content
from any location without having to cross the WAN. For travelling users
relying on roaming folders and folder redirection, DFS is a boon
because it can be used to make their data available automatically in
any of the offices in which they can find themselves.
If you decide to rely on DFS to provide data availability to your traveling users, then you need to perform several tasks:
Identify which users roam from office to office. Ideally, you can put these users into a special "roaming" Global Security group in AD.
Create the DFS Namespace. Use the same share names as with non-roaming users, but make them domain-based DFS shares.
Assign targets to the DFS Namespace. Assign one target per remote site along with one target in the central office.
Configure DFS Replication for the Namespace. Doing this ensures that each target has the same content.
Use
the new DFS Namespace to assign the Group Policies that will enable
folder redirection and redirect users' roaming profiles to the DFS
Namespace share.
Proceed as follows to perform these activities. You need Server Operator permissions to perform this task.
Begin by logging onto the File Server Management console.
Either this can be done on a server where the File Server role has been
deployed including the DFS components or, preferably, on a desktop that
has the Remote Server Administration Tools (RSAT) deployed.
NOTE
To use the RSAT for Windows Server 2008 on Vista, you must have Vista Service Pack 1 deployed.
Connect to a File Server and then move to the File Server Management =>
DFS Management =>
Namespaces node in the Tree pane of the console.
Right-click on Namespaces or use the Action pane to select New Namespace. Doing this launches the New Namespace wizard.
Assign
a server to host the Namespace by typing in the name of the server or
using the Browse button to select the server. Click Next. If the
server's DFS service is not running, the wizard will offer to start it.
Click Yes. (Note that any server that will host a target will do to host the namespace.)
Create the namespace.
You only need to type in the latter part of the share name since the
domain name will automatically be assigned. Two Namespaces are
required: RoamingProf and FolderRedir. Assign the first name, and then
repeat the procedure to assign the second name.
NOTE
DFS Namespaces cannot be hidden, therefore you do not need to add the $ sign at the end of the Namespace names.
Click
Edit Settings to modify the share permissions. In the Edit Settings
dialog box, click Browse to place the share on the appropriate disk and
folder. Click OK and then click Next. Shares should be on a data
disk, usually D: and should be placed within a special DFSRoots folder
to properly identify them. Also, assign permissions so that
administrators have full control and users have read and write
privileges (see Figure 3).
Make sure that you select Domain-based namespace.
This ensures that the Namespace is stored within the directory and is
made available to any location in your network. This dialog box lists
the share name for your Namespace; make note of it. Click Next.
Review the changes to perform and click Create. Click Previous if you need to modify the settings.
Review the tasks the wizard performed and click Close.
Repeat the procedure for the second namespace.
Now you're ready to assign targets to the Namespace. Once again, this is done in the File Server Management console.
Select the Namespace to which you want to add targets.
Click Add Namespace Server in the Action pane.
In the Add Namespace Server dialog box, click Browse to locate the servers you want to add as targets.
Again,
click Edit Settings to assign the folder to the appropriate location
and set proper permissions. Use the same settings as in the previous
procedure. Click OK to assign the new target. If the server's DFS service is not running, the wizard will offer to start it. Click Yes.
Repeat
the previous step to assign additional servers to this Namespace.
Repeat the entire procedure to assign targets to the other Namespace.
Now
you're ready to set replication rules for the targets for each
Namespace. Once again, this is done in the File Server Management
console.
Move to the File Server Management =>
DFS Management =>
Replication node in the tree pane of the console.
Right-click on Replication or use the action pane to select New Replication Group. This launches the New Replication Group wizard.
In the first page of the wizard, select Multipurpose replication group. Selecting this enables you to set replication to keep content synchronized between locations.
Click Next, name the Group, and click Next again. For example, you can use Roaming Data Protection for the group name and assign a description.
Use
the Add button to select replication group member servers. Add all of
the target servers in the Namespaces you created earlier. Click Next.
Select the Full mesh replication topology and click Next.
This step ensures that all members can initiate replication to all
other members and will maintain identical content in each location.
Select how much bandwidth replication will be allowed to use and identify the schedule.
If
your users spend entire days in remote offices when they travel, then
you can use a daily replication schedule because they won't need to
access their data in another location for 24 hours.
If
your users are in several different offices in a single day, then you
should use a more frequent replication schedule. In addition, you
should throttle replication.
Use a value that is in keeping with the WAN links and available bandwidth on each link. Normally, 64 Mbps is sufficient.
Select Replicate during the specified days and times, and then click Edit Schedule.
In
the Schedule window, you can use the schedule which best fits your
needs. Select the bandwidth to use, and then select the available times
for this bandwidth. Click on Details to view the results of the
schedule you set (see
Figure 4). Click OK and then Next when done.
Select the primary replication member and click Next. This server will be the initial master during the first replication pass.
Select
the folders to replicate. Click Add to select the first folder, use the
Browse button to locate the folder, use the same name as the target and
make sure Permissions are set to Existing permissions. Click OK and
repeat to add the second folder. Click Next when done.
Select
the local paths on target servers for each folder you replicate and
then select the target server, click Edit, Enable replication, and
click Browse to identify the local path. This should be the same path as the Namespace path on each target server.
Click OK and repeat for each target server. Click Next when Done.
Repeat the selection of local paths for the second folder to replicate.
Review your choices and click Create when ready. Click Previous to make modifications to your settings if needed.
Click Close when ready.
Windows displays a replication delay message indicating that
replication will not begin until the target servers pick up the
configuration from Active Directory. For example, in large
organizations with extensive replication latency, this configuration
would not be picked up by members until the latency period has passed.
This is okay because you are still not ready to replicate data because
your configuration is not yet complete.
Click OK. Your DFS strategy is complete.
