Microsoft®

Implementing an End-User Data

Centralization Solution
Folder Redirection and Offline Files Technology Validation and Deployment
Copyright information
This is a preliminary document and may be changed substantially prior to final commercial release of the software
described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues
discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should
not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of
any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR
STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for
any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights
covering subject matter in this document. Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights,
or other intellectual property.
Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people,
places, and events depicted in examples herein are fictitious. No association with any real company, organization,
product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

Microsoft, Active Directory, BitLocker, Forefront, SQL Server, Windows, Windows Server, and Windows Vista are
trademarks of the Microsoft group of companies.

All other trademarks are property of their respective owners.

Contents
Executive Summary .......................................................................................................................................................6

Target Organizational Needs .....................................................................................................................................7

Target Group Overview .............................................................................................................................................7

Business Needs ..........................................................................................................................................................7

Deployment Requirements and Service Level Agreements ..........................................................................................8

Data Centralization and Management SLA ...............................................................................................................8

Data Availability and Mobility SLA ............................................................................................................................9

Data Protection and Portability SLA ..........................................................................................................................9

Technology Overview ....................................................................................................................................................9

SMB .........................................................................................................................................................................10

Folder Redirection ...................................................................................................................................................11

Offline Files..............................................................................................................................................................11

File Server Resource Manager.................................................................................................................................12

Failover Clustering ...................................................................................................................................................13

Shadow Copy for Shared Folders ............................................................................................................................13

Data Protection Manager 2007 SP1 ........................................................................................................................13

Planning .......................................................................................................................................................................14

Data Centralization and Management ....................................................................................................................14

Server location and network infrastructure .......................................................................................................14

Server characteristics ..........................................................................................................................................16

Planning for Folder Redirection deployment ......................................................................................................20

Planning for quotas deployment ........................................................................................................................23

Data Availability and Mobility .................................................................................................................................24

Deploying Offline Files ........................................................................................................................................24

Deploying Failover Clustering .............................................................................................................................28

Data Protection and Portability ...............................................................................................................................30

Understanding the challenges ............................................................................................................................31

Backup methodologies .......................................................................................................................................31

Data Protection Manager ...................................................................................................................................32

User-enabled data recovery ...............................................................................................................................33

3
 Data recovery planning .......................................................................................................................................34

Protecting the Data Protection Manager infrastructure ....................................................................................34

Data Security and Privacy Considerations ...............................................................................................................35

Back-end infrastructure security.........................................................................................................................35

Client computer security .....................................................................................................................................37

Network security .................................................................................................................................................39

Implementation ...........................................................................................................................................................41

Server and Storage Hardware .................................................................................................................................41

Domain Representation ..........................................................................................................................................41

Failover cluster hardware ...................................................................................................................................42

Stand-alone server hardware .............................................................................................................................42

Operating system configuration .........................................................................................................................43

File-Server-1 (Folder Redirection and Script Content – Head Office) .................................................................45

File-Server-2 (Folder Redirection and Script Content – Far Branch Office) ........................................................46

File Server Resource Manager ............................................................................................................................46

Shadow Copy for Shared Folders ........................................................................................................................50

Group Policy settings ..........................................................................................................................................50

Data Protection Manager 2007 Configuration ........................................................................................................58

Network throttling ..............................................................................................................................................59

On-the-wire compression ...................................................................................................................................60

Consistency checks .............................................................................................................................................60

Operational Procedures...............................................................................................................................................62

Adding Users to the Service ....................................................................................................................................62

Stage one ............................................................................................................................................................62

Stage two ............................................................................................................................................................63

Removing Users from the Service ...........................................................................................................................63

Conclusion ...................................................................................................................................................................64

Index of Tables .............................................................................................................................................................65

Index of Figures ...........................................................................................................................................................66

Appendix A – Scripts ....................................................................................................................................................67

Computer Specific Folder Redirection ....................................................................................................................67

Computer Specific Folder Redirection logon script ............................................................................................67

4
 Computer Specific WMI Namespace Installation startup script .........................................................................68

Computer Specific (MOF) support file ................................................................................................................68

Windows Vista Background Synchronization ..........................................................................................................68

Windows Vista Offline Rename Delete ...................................................................................................................74

5
Solution
 Leverage Microsoft
Windows Server 2008 R2
and Windows client
technologies to ensure that
your users’ files are always Executive Summary
available. Log on to an
alternate computer or
replace a computer and Audience:
your users’ data will follow
them. This white paper is intended for technical decision makers and operation managers who
 Provide a common view are evaluating ways to achieve effective management, centralization, and protection for
from any computer to your their organization’s user file data. Working knowledge of Windows Server® and
users’ data. Windows® client operating systems is assumed.
 Reduce the cost and
complexity of your users’ Objective:
computer replacement.
The objective of this white paper is to show through a case study how to use different
 Achieve centralized
management and protection Microsoft® products and technologies to put in place a comprehensive solution
for your users’ data. satisfying the needs of a mid-sized organization around users’ file data management.
 Lower WAN utilization and
The study was conducted by the Quality Assurance group of the Storage Solutions
cost with faster file access
Division (SSD) at Microsoft, a division that focuses on enabling customers of all sizes to
across geographical
locations. store, manage, and reliably access their file data.
 Reduce IT overheard for As part of a widespread effort within Microsoft to internally deploy products and
selective file restores by
solutions before releasing them to customers, the Quality Assurance group assembled a
enabling your users to
access previous versions of deployment team that was tasked with deploying a client data centralization service for
their files. a select group of users (the target group) representing a mid-sized organization.

The primary goal of this deployment was to validate that the technologies being
Products & Technologies developed by SSD enabled our customers to put in place a client data centralization
 Windows Server 2008 R2 service that satisfied a set of typical business needs.
 Windows 7
Learning:
 Windows Vista
 Server Message Blocks The white paper is structured in a format that will take the reader through the different
(SMB) phases of a deployment project. We will first assess the organizational business needs
 Folder Redirection and requirements, defining the Service Level Agreements. We will then go through the
 Offline Files (Client Side planning considerations and recommended best practices to build a service that satisfies
Caching)
the objective. Lastly, we will provide the reader with the implementation details in a
 File Server Resource
Manager section that is mainly targeted towards IT administrators.
 Microsoft Failover Clustering
 Shadow Copy for Shared
Folders
 Data Protection Manager
2007 SP1 (DPM)
 File Server Capacity Tool
(FSCT)

6
Target Organizational Needs

Target Group Overview

When selecting the target group for the internal deployment, the main criteria was to ensure that its structure and
needs were representative of a generic mid-sized organization. Several criteria were considered to select such a
group. For instance, the number of users, their geographical location, and their mobility needed to be typical of a
modern medium-sized business. The target group chosen by the deployment team had approximately 340 people
geographically dispersed across two continents and four different sites, as depicted in Figure 1 below:

Head Office
~220 Users

Far Branch Office

~100 Users

Near Branch Offices

~10+ Users

WAN Link
~80 - 100ms
RTT

WAN Link
~250 - 300ms
RTT

Figure 1 - Geographic distribution

The employees within this group had unique characteristics that needed to be considered when defining the
solution:

• Users were geographically dispersed, some located in branch offices connected to the main office
using slow wide area network (WAN) links.
• Users had various operating systems such as Windows Vista® or Windows 7 installed on each of their
client computers.
• In addition to using their own corporate computers, some users had the need to use shared
computers.
• Some users were mobile, needing to travel inside and outside corporate facilities with their laptops.
• Some users were frequently working from non-corporate computers with Internet connectivity
(working from home).

Business Needs
For this project, the business needs of the IT organization and the target group can be categorized as follows:

1. Data Centralization and Management – User data typically stored on client computers should be
centralized for IT administrators to monitor and manage. Users should also be able to access their data
from any corporate domain-joined computer.

7
 2. Data Mobility and Availability – Users should have access to their data at any time regardless of their
network connectivity or bandwidth/latency constraints. For example, users should be able to take their
laptop home and access their data without connectivity to the corporate network.
3. Data Protection and Portability – Data stored on client computers should be protected against possible
data loss. Additionally, data needs to be portable so that users can easily replace their computer and
maintain access to their data after domain logon.

The deployment team had also to consider the data privacy and security aspects of the solution. All user data
should be stored in a secure and safe location and should be accessible only by the authorized user. Some of the
important considerations are defined in a specific security section later in this document.

Additionally, while fulfilling the business needs above, the solution needed to be implemented and operated
within a limited budget. In this deployment, reducing IT personnel (administration and support) and hardware
costs were primary goals as we wanted to ensure the cost effectiveness of the solution that we proposed to our
customers.

Deployment Requirements and Service Level Agreements

The service was implemented by using pre-released versions of Windows Server 2008 R2 and Windows 7. Service
outages and data loss due to code instability were not anticipated because of the rigorous product testing and
validation process in place at Microsoft, but planning for such incidents had to be considered based upon the use
of pre-release software. Independent of the quality of the early Windows Server 2008 R2 versions being deployed,
the team was held to a high standard to maintain system availability and prevent data loss or corruption.

Defining precise Service Level Agreements (SLAs) was instrumental in making the appropriate design decisions.
Going through this definition process is an important step as the SLAs have an effect on planning considerations
such as server placement, server configuration, backup technology selection, and methodology. We will highlight
many of the decisions that were made and how they were handled to ensure that the implemented solution met
the business objectives.

Data Centralization and Management SLA

One deployment objective was to implement a controlled platform to achieve data centralization for the
organization’s user data. In our case, this data was maintained in the user profile folders which are composed of
well-known Windows folders such as Documents, Videos, Pictures, and Music.

Prior to implementing the solution for the target organization, user profile folders were maintained on individual
client computers. The data was not synchronized between the different computers (laptop and desktop, for
example), which was not convenient for our users who wanted a consistent view of their data on every computer.

The goal was to provide the ability for users to access a consistent view of their user profile folders from a
centralized location based on the specific SLA principles below:

• Support client computers that are domain-joined and running Windows Server 2008 R2, Windows
Server 2008, Windows 7, and Windows Vista.
• Provide the following storage capabilities to users:
o 10 gigabytes (GB) of storage space to support individual user profile folders.
o Warn users when their capacity utilization reaches 90%.

8
 o Warn users when their capacity utilization reaches 100%, and block the ability to create
additional content to the centralized data store.
o Provide increased capacity as required given relevant business justification.
• Solution should have a negligible performance impact on user experience independent of location or
network connectivity during enrollment or daily usage.
• Users should be able to efficiently search the data stored in their user profile folders.
• The IT administrator should be able to monitor and control the data stored for the target group for
compliance and space management reasons.

Data Availability and Mobility SLA

Achieving high availability of user data was a key business objective because users were relying on always being
able to access their files to perform their work.

The goal was to ensure that users maintain fast access to their data independent of their network connectivity or
quality of the link leveraged to connect to the centralized storage location. The SLAs for data availability and
mobility were:

• Achieve 99.99% data availability to user profile folders from client computers.
• Allow users fast access to their user profile folders independent of:
o Users that infrequently connect to the corporate network.
o The throughput and latency of the network connecting the user’s computer to the centralized
storage location.

Data Protection and Portability SLA

Protecting the user from a partial or full data loss incident was another key requirement. We wanted to protect
user data in case of various events such as accidental file modification or deletion, laptop loss, or client or server
hardware failure.

To reduce the service support costs, it was required to provide end users with the ability to recover previous
versions of their files without assistance from any IT organization’s staff member.

The SLAs for data protection and portability were:

• Service should achieve a Recovery Point Objective (RPO) of zero data loss for centralized data.
• Service should make computer replacement easy, allowing users to maintain access to their data
without the need for data migration.
• Employ a single backup server located in the head office to protect all file servers independently of
their geographic location.
• Mitigate any performance impact on the end users during backup operations.
• Minimize WAN traffic during backup operations.
• Allow end users to perform selective file and folder content recovery without assistance from IT staff.

Technology Overview
To implement the solution, a wide variety of technologies were needed. Many of the technologies that were
required have been available in the Windows Server and Windows client operating systems for a long time.
However, a few technologies key to this project have been either greatly enhanced or are new for the Windows

9
Server 2008 R2 and Windows 7 operating systems. These technologies will be introduced with special attention
given to the features relevant to this deployment.

Note: The following is not an exhaustive discussion of each technology’s feature set.

SMB
Server Message Block (SMB) is the primary remote file protocol used by Windows clients and servers and dates
back to the 1980s. When it was first introduced, local area network (LAN) speeds were typically 10 megabits per
second (Mbps) or less, WAN use was very limited, and wireless LANs did not exist. Since then, the world of network
communication has changed considerably. The original SMB protocol, also known as CIFS (Common Internet File
System), incrementally evolved over time until Windows Vista and Windows Server 2008 were introduced. Starting
with these releases, a redesigned version of the protocol known as SMB 2.0 was introduced. Notably, this version
brought a number of performance improvements over the former SMB 1 implementation.

Two important limitations of SMB 1 were its “chattiness” and lack of concern for network latency. To accomplish
many of the most common tasks, a series of synchronous round trips were required. The protocol was not created
with WAN or high-latency networks in mind, and there was limited use of compounding (combining multiple
commands in a single network packet) or pipelining (sending additional commands before the answer to a
previous command arrives). There were also limitations regarding the number of files that could be opened
concurrently, the number of shares, and the number of concurrent users supported.

The SMB 2.0 design addressed those shortcomings, bringing a number of significant improvements, including but
not limited to:

• General improvements to allow for better utilization of the network.

• Request compounding, which allows multiple SMB 2.0 requests to be sent as a single network
request.
• Larger reads and writes to make better use of faster networks, even those with high latency.
• Caching of folder and file properties, where clients keep local copies of folders and files.
• Durable handles to allow an SMB 2.0 connection to transparently reconnect to the server in the event
of a temporary disconnection.
• Improved message signing (HMAC SHA-256 replaces MD5 as hashing algorithm) with improved
configuration and interoperability.
• Improved scalability for file sharing (number of users, shares, and open files per server greatly
increased).
• Support for symbolic links.

SMB 2.1, a minor revision, brought an important performance enhancement to the protocol in Windows
Server 2008 R2 and Windows 7 with the introduction of a new client opportunistic lock (oplock) leasing model.
Oplocks are extensively used by SMB to allow the client to cache data and file handles. This brings major
performance benefits especially on slower networks by limiting the amount of data that needs to be transferred
between the client and server. The new leasing model in SMB 2.1 allows greater file and handle caching
opportunities for an SMB 2.1 client, while preserving data integrity, and requiring no current application changes
to take advantage of this capability.

The benefits of this change are:

• Reduced network bandwidth consumption

• Greater file server scalability

10
 • Better application response time when accessing files over a network

Another important enhancement brought in Windows 7 is improved energy efficiency for workstations.
Windows Vista computers may enter a sleep power state in a number of scenarios, and Windows 7 computers
allow a greater range of scenarios where they may enter a sleep power state.

For backwards compatibility, Windows Server 2008 R2 and Windows 7 support SMB 1, SMB 2.0, and SMB 2.1 and
will automatically use the version most appropriate for communication, as shown in Table 1.

SMB Version Negotiation

Server Pre-Windows Server 2008 Windows Server 2008 Windows Server 2008 R2

Client

Pre-Windows Vista SMB 1 SMB 1 SMB 1

Windows Vista SMB 1 SMB 2.0 SMB 2.0
Windows 7 SMB 1 SMB 2.0 SMB 2.1
Table 1 - SMB version negotiation

Folder Redirection
Folder Redirection is a feature that allows users and administrators to redirect the path of a user profile folder to a
new location. The new location can be a folder on the local computer or a folder on a network share. Folder
Redirection provides users with a centralized view of select user profile folders from any domain-joined computer.
Users then have the ability to work with documents located on a server as if they were located on the local drive.
For example, with this technology, it is possible to redirect the Documents folder, which is usually stored on the
computer's local hard disk drive, to a network location.

Folder Redirection offers many benefits to users and administrators, including having their data stored on a server
which can be easily backed up as part of routine system administration tasks. It also allows a user to log on to
different physical computers while automatically maintaining access to their data.

One drawback of Folder Redirection prior to Windows 7 was a user’s first logon experience when Folder
Redirection was initially deployed. With Windows Vista, the user, in certain conditions, could experience delays
during their first logon while all their local data was copied over the network to the server. To improve this
experience in Windows 7, a user with Offline Files enabled (on by default) when Folder Redirection is deployed will
see a significantly improved first logon experience because their data is moved from their local drive into their
local cache, and not over the network. After the initial move is complete, the user may access their desktop
normally and their locally cached data will be synchronized over the network to the server as a background task.

Offline Files
Offline Files (also known as Client Side Caching or CSC) makes network files available to an end user with near local
access performance when a network connection to the server is unavailable or slow.

Offline Files maintains a local cached copy of network files and folders on the client computer, so that the cached
files are available when there is no network connection to the file servers. When the connection to the file server
is restored, changes made to the files while working offline are automatically synchronized to the file server. If a
user modified the same file from multiple computers when working offline, options exist to resolve the conflict.

11
Many improvements relevant to the solution discussed in this document have been made to Offline Files in
Windows 7. These changes include:

• Introduction of the Usually Offline concept

• Ability to transition online automatically from Slow Link mode
• Support for exclusion list in Offline Files based on file extensions
• Support for offline directory rename and delete

Usually Offline provides the ability for users to always work from the cached copy while maintaining a
synchronized view of the data between the client and the server. This concept was introduced to enable users to
experience local file access performance even when the network between the client and the server is slow. When
a client network connection to a server is slow, Offline Files will automatically transition the client into an “Offline
(slow connection)” mode. The user then works from the locally cached version of the files so all reads and writes
are satisfied by the cached copy. While this feature is also available in Windows Vista, Windows 7 adds the ability
to automatically synchronize in the background at regular intervals to reconcile any changes between the client
and the server. With this feature, users do not have to worry about manually synchronizing their data with the
server when they are working offline.
Additionally, prior to Windows 7, there was no mechanism to automatically transition to an online state from an
offline state that was caused by a slow link condition. Now, the system can detect when network conditions
improve and transition back to online mode. With Windows Vista, the user needed to explicitly transition back
online by using the user interface. It is also possible for administrators to programmatically transition online at
certain key times such as user logon.

The Offline Files Exclusion List feature allows administrators to block files of selected types from being created
from the client computers for all cached network locations. The list of file types is configured by the IT
administrator through Group Policy. In the solution described in this document, and for compliance reasons, users
are prevented from creating files of specific types by policy, independent of whether they are working in an online
or offline mode.

By default, Windows 7 enables users to rename and delete directories while in offline mode. In Windows Vista
Service Pack 1 (SP1), adding a registry key was required to enable this functionality. Prior to Windows Vista SP1, it
was not possible while offline to rename or delete directories that were created online.

File Server Resource Manager

File Server Resource Manager is a suite of tools that allows administrators to understand, control, and manage the
quantity and type of data stored on their computers that are running Windows Server. By using File Server
Resource Manager, administrators can place quotas on volumes, actively screen files and folders, and generate
comprehensive storage reports. This set of advanced instruments not only helps the administrator to efficiently
monitor existing storage resources, but it also aids in the planning and implementation of future policy changes. In
Windows Server 2008 R2, File Server Resource Manager is supported on all server installation options, including
Server Core.

File Server Resource Manager enables the following tasks:

• Create quotas to limit the space allowed for a volume or folder and generate notifications when the
quota limits are approached or exceeded.
• Automatically generate and apply quotas to all existing folders and any new subfolders in a volume or
folder.

12
 • Create file screens to control the type of files that users can save and send notifications when users
attempt to save blocked files.
• Define quota and file screening templates that can be easily applied to new volumes or folders and
reused across an organization.
• Schedule periodic or on demand storage reports that help identify trends in disk usage.
• Monitor attempts to save unauthorized files for all users or for a selected group of users.

Failover Clustering
Failover clusters in Windows Server 2008 R2 provide high availability for mission-critical applications such as
databases, messaging systems, file and print services, and virtualized workloads. Failover clusters can scale to
include sixteen servers (nodes) in a single cluster by using a shared storage backend with support for Serial
Attached SCSI (SAS), Internet SCSI (iSCSI), or Fibre Channel interconnects. The nodes maintain constant
communication with each other to ensure service availability; if one of the nodes in a cluster becomes unavailable
due to an unscheduled or scheduled failure, another node immediately begins providing service. Users who are
accessing a service that has moved from one cluster node to another due to failure or another service-impacting
outage will typically not notice any service impact and will continue to work without issue.

Shadow Copy for Shared Folders

Shadow Copy for Shared Folders is a feature in Windows Server that transparently maintains previous versions of
files on selected volumes by using shadow copies. It works by taking snapshots of an entire volume at particular
points in time. Shadow Copy for Shared Folders is enabled on a per-volume basis.

By default, two schedules are applied to take the snapshots at 7:00 A.M. and 12:00 P.M. every weekday. Shadow
Copy for Shared Folders allows individual users to do selective file or folder restore from previous versions without
IT assistance.

This feature helps reduce IT operational costs by eliminating the need for administrator intervention by enabling
users to restore deleted, modified, or corrupted files from a snapshot of the volume.

Data Protection Manager 2007 SP1

Microsoft Data Protection Manager 2007 (DPM) is a full featured data protection product designed to protect
compatible applications and the Windows Server operating system. DPM is designed to deliver continuous data
protection for compatible applications and file servers by using seamlessly integrated disk, tape, or cloud storage
as a backup target. DPM invokes the Volume Shadow Copy Services (VSS) to create a one-time full replica of the
data to be protected followed by incremental synchronizations (recovery points) that by default are scheduled to
occur every fifteen minutes. DPM is intended to provide a “zero data loss” recovery when protecting applications
such as Microsoft Exchange and Microsoft SQL Server®, and a “near Continuous Data Protection (CDP)” model for
file servers where content can be protected on a fifteen-minute schedule.

DPM provides the following key file protection features related to the needs of our solution:

• File-based protection for stand-alone and clustered file servers with support for Windows
Server 2008 R2.
• Backup to disk with the option to also back up to tape and/or the cloud.
• Flexible exclusion for files and folders.
• Ability to protect open files.

13
 • Elimination of the need to repeat Full backups. The initial replica is created once and incrementally
synchronized.
• Only changed blocks within files are moved to the DPM server during incremental synchronization.
• Minimization of data loss through the ability to restore from selected recovery points or from the last
incremental synchronization.
• Support for protection of remote servers with minimum impact on WAN links (requires 512 kilobits
per second [Kbps] minimum link).
• Advanced bandwidth throttling for WAN backup scenarios.
• Self-service ability for End-User Recovery of files directly from Windows Explorer or Microsoft Office.
• Self-healing capability: in case a number of backups have failed, DPM will check to ensure data
consistency.

Planning
This section focuses on the planning required to meet the previously defined business objectives. Planning is an
important stage of the deployment process and is critical to delivering the solution on time and on budget.

Data Centralization and Management

Centralizing data from user profile folders was a key requirement of this solution. The main technology used to
achieve centralization of user profile folders was Folder Redirection. To control and monitor the data stored at the
central location both in terms of size and content, we used the functionalities offered by File Server Resource
Manager.

Server location and network infrastructure

To define our server infrastructure, we first needed to understand the way client computers would access the
servers. The geographical location and the mobility of users would have a deep impact on any data centralization
project because both location and mobility would have an effect on the characteristics of the network link
between the clients and the server. The relevant characteristics of networking are the link latency, throughput,
and the availability of the network.

SMB 2.0, introduced in Windows Vista, dramatically increased the performance of file access over slow networks
(high latency/low bandwidth). Nevertheless, the better the performance characteristics of the underlying network,
the better the end user’s experience will be when accessing files directly from the server.

14
Table 2 represents our user base classification for user location and mobility.

Facility Classification

User category Description Average network latency (RTT)

Local user
Near branch office users
Far branch office users
Mobile users
between user location and
data facility
Users located at the same location as the main < 3 milliseconds (ms)
office/data center. This implies a LAN connection
between the client computers and the datacenter.
Users located in branch offices on the same 80 to 100 ms
continent as the main office/data center location.
This implies a relatively fast (depending on the
infrastructure) WAN connection between the
client computers and the datacenter.
Users located in branch offices on a different 250 to 300 ms
continent from the main office/data center
location. This implies a relatively slow WAN
connection between the client computers and the
datacenter.
Users using laptop computers, having sporadic Variable
access to the network, and connecting to the
corporate network by using Remote Access or
Direct Access (new in Windows 7). This implies a
transient WAN connection between the client
computers and the datacenter with latency and
speed varying depending on where the user
connects from.
Table 2 - Facility classification

Based on our testing, the initial logon performance for all the client operating systems that we planned to support
was acceptable for local users and near branch users with a file server located in our main datacenter. The use of
the Offline Files technology allowed us to meet our business requirements for performance for the near branch
user experience.

For mobile users, we also looked at Offline Files to allow us to meet our data access performance and availability
needs because the characteristics of the underlying network can vary widely.

For far branch users, we chose to deploy a separate file server that was physically located on the same site as the
users. Although Offline Files would have allowed acceptable performance as far as file access is concerned, the
initial folder redirection process could have been unacceptably long for users with a large data set and who use
Windows Vista for their client operating system. Indeed, when Folder Redirection first applies, the content of the
local folders to redirect is moved to the server, and for Windows Vista this operation occurs during initial logon.
For users with several gigabytes of data stored in their local folders and with the server located on another
continent with an average latency of 250 ms to 300 ms, this would have meant an initial logon time in the order of
hours, which was not acceptable. Users with Windows 7 would not have experienced this issue, but because our
solution stipulated that we also needed to support Windows Vista and Windows Server 2008 as client operating
systems, we decided to put a file server in the far branch office.

15
Figure 2 summarizes the pre-existing network infrastructure and the choices that were made for server placement.

Head Office

Folder Redirection
Infrastructure
Users Users
WAN Link
Failover Cluster DPM Server 2.5Gb/s
Users Users 250 to 300ms RTT

Node1 Node 2
Users Users
~220 users have LAN connectivity to File Serving
infrastructure Folder Redirection
Infrastructure

Users
WAN Link Stand-alone Server
155Mb/s
50 to 100ms RTT
Users

~100 users have LAN connectivity to

Users Users Users Users File Serving infrastructure

Near Branch Office Near Branch Office Far Branch Office

Figure 2 - Network infrastructure and server locations

Server characteristics

File server capacity planning

Correctly sizing the different elements of our file server back-end infrastructure was critical for our ability to scale
the service for years to come in a cost efficient way. The purpose of this planning phase was to determine what
hardware needed to be purchased so we would provide the service in a way that meets our needs while making
sure that we accounted for future growth. Understanding the following is important to achieve this goal without
overspending:

• Characteristics of the workload

• Current and future needs
• Existing company infrastructure and how it can be best leveraged

The type of workload applied to the servers is a major variable in properly sizing the different components of the
system. Its characteristics define the relative needs in terms of CPU, memory, storage, and network. Several broad
workload categories are commonly referred to in the industry. These workloads include Database, File, E-Mail,
Web, and High Performance Computing (HPC). Each workload stresses the system resources differently.

In our case, we knew that we would be applying a File workload to our servers where multiple clients would access
files on a server through the SMB protocol. Understanding the broad category in which our workload belongs is a
good first step. However, characterizing the resource requirements based only on this data point is very
challenging. There are multiple sub-categories within the File workload, each having very different characteristics.
For our deployment, we defined our workload as a home folder workload. Some of the interesting characteristics
for this type of workload are the following:

16
 • Very little sharing of files between clients (each user has a dedicated folder mainly accessed by one
computer at a time)
• User folders are mainly composed of Microsoft Office documents, pictures, and a few videos
• Mix of mostly random read and write operations (approximately 70% read, 30% write)
• Relatively light load from each client with sporadic access over the course of a work day
• Potentially large number of clients and network connections

From a hardware standpoint, this translated into the following generic characteristics:

• More stress on the storage subsystem with more performance needed for small/medium random
I/Os
• Storage subsystem using RAID 5 or RAID 6 needed for data availability
• More stress on the networking subsystem with the ability of efficiently handling a large number of
concurrent connections and transferring a large number of small/medium packets
• Less stress on CPU which is used mainly to move data rather than performing complex data
transformation
• Less stress on memory which is used mainly for file system caching purposes

To define our hardware needs more precisely, we needed to quantify our current and future scalability
requirements. We knew that we would be deploying two file servers: one in our head office supporting
approximately 220 users and one in the far branch location supporting approximately 100 users.

Our requirements specified the need to provide 10 GB of storage space per user for this service. This goal was
established from business needs and cost. Before deploying the service, our users had various amounts of data in
their local user profile folders. Some had a few megabytes while others had many gigabytes of data. It was
important to know before the deployment the amount of data each user had in the folders we wanted to redirect
in order to provision the right amount of storage. For this purpose, the team developed a simple script that was
run on the client computers to be deployed that calculated the amount of data stored in the users folders to be
redirected.

In our case, we determined that the average amount of space consumed by each user in their local user profile
folders was 3 GB with wide variations between all users. With this data point, we did not provision 10 GB of
storage per user since it would have resulted in a large amount of unused space.

As far as future needs are concerned, we have planned for 5% increase year over year in terms of users and 10% in
terms of data. We will also adjust our requirements and the amount of storage space we offer as the business
needs change.

17
Tables 3 and 4 represent the forecasted needs for both servers over a period of 5 years.

Head Office Server Capacity Sizing

Year Number of users Actual per user Per user storage Total storage
storage usage offered as per SLA provisioned (GB)
prediction (GB) (GB)
Year 0 220 3 10 1100
Year 1 231 3 10 1155
Year 2 243 4 10 1455
Year 3 255 4 15 1783
Year 4 267 4 15 1872
Table 3 - Head office server capacity sizing

Far Branch Server Capacity Sizing

Year Number of users Actual per user Per user storage Total storage
storage usage offered as per SLA provisioned (GB)
prediction (GB) (GB)
Year 0 100 3 10 500
Year 1 105 3 10 525
Year 2 110 4 10 662
Year 3 116 4 15 810
Year 4 122 4 15 851
Table 4 - Far branch server capacity sizing

Based on these projections, we provisioned 2 terabytes of usable storage for our head office server and 1 terabyte
for our far branch server.

Based on our testing, and given the relatively low number of users per server and the characteristics of workloads,
an entry level server (dual core system, 4 GB of RAM) with direct attached storage and one 1 gigabits per second
(Gbps) network adapter would be sufficient to support the load. Having additional RAM, however, would enhance
the availability of the solution as we will discuss in the next section related to check disk (chkdsk).

To determine how many users a given configuration can support, we recommend using the Microsoft File Server
Capacity Tool (FSCT) tool. For more information, see File Server Capacity Tool - (32 bit) in the Microsoft Download
Center (http://go.microsoft.com/fwlink/?LinkId=166651). This tool simulates a home folders file workload on a set
of client computers and computes the maximum number of users a server can support based on the response time
of simulated scenarios. The scenarios include common operations such as browsing a directory, copying files, and
modifying Microsoft Office files. For a given number of users accessing data on a file server, FSCT will compute a
throughput number corresponding to the average scenarios per second that the server is able to sustain. The tool
also provides the ability to collect performance counters such as CPU, Memory, Network, and Disk subsystem
utilization details to help identify bottlenecks.

Figure 3 shows an example of the data FSCT provides when run on a setup composed of a target server under test
and several load simulation client computers. The server system used in the test had the following specifications:

 Dual socket quad core 2.33-gigahertz (GHz) CPU

 8 GB of RAM
 3x1-Gbps network adapters

18
  12x146-GB 15-KRPM SAS drives
FSCT profiled the server in this example as having the capability to sustain 4,400 file server users before it reached
an overload condition at 4,600 users.

Figure 3 - FSCT report output

With this tool it is easy to predict the evolution of the server scenarios throughput based on the amount of
simulated users as shown in Figure 4.

19
 450 100,00%
Number of scenarios per second
400 90,00%
350 80,00%
70,00%

CPU utilization
300
60,00%
250
50,00%
200 Average scenario throughput
40,00%
150 30,00% CPU utilization
100 20,00%
50 10,00%
0 0,00%

4000
2000
2200
2400
2600
2800
3000
3200
3400
3600
3800

4200
4400
4600
4800
Number of users

Figure 4 – FSCT server scenarios throughput

In our deployment, we leveraged servers and storage, which were made available from a pool of existing
hardware. The specifications were higher than required which resulted in a heavily underutilized system for our
solution. The implementation section contains the details of the specifications.

File Server storage configuration

After we established the amount of storage needed and its type, we defined how it would be configured and
presented to the operating system.

In the past and with earlier versions of Windows Server such as Windows 2000 Server, it was usually not
recommended to create large NTFS volumes (> 2 terabytes) in a system requiring high availability of data. Although
NTFS has been fully capable of handling very large volumes (up to 256 terabytes with a 64-KB cluster size by using
a GPT disk type), the time needed to run check disk (chkdsk) was often considered as a barrier to achieve high
availability. Since then, substantial improvements have been made to reduce check disk run time. Specifically, in
Windows Server 2008 R2 a new feature called block caching was introduced to address this problem. The feature
makes better use of available RAM on the system to reduce check disk run times. For this reason and given the
current price of RAM, we recommend adding extra memory capacity to the system. The time check disk needs to
complete depends on many parameters, such as number of files, size of files, speed of the storage subsystem,
volume of data, and level of fragmentation of the volume. Because of all these parameters, it is difficult to give
absolute performance numbers, and the best way to evaluate the time to completion is to perform a test on a
representative system and data set. In our solution, we decided to implement a single data volume on each server
for ease of management.

Planning for Folder Redirection deployment

Determining which user profile folders to redirect

The first step was to determine which user profile folders we wanted to redirect. Our focus in this deployment was
mainly to centralize user files and to lower the total cost of ownership in the scenario when a user needs to
configure a new computer. Folder Redirection is an effective technology to enable this scenario as it can restore
user data on a computer upon logon. To achieve our goal, we redirected the following user profile folders:
Desktop, Documents, Pictures, Music, Videos, Favorites, Contacts, Downloads, Links, Searches, and Saved Games.

20
Determining which user computers need redirection
Because the Folder Redirection Group Policy is a per-user setting, the redirection of user profile folders is tied to a
user account independent of the computer used by the user. This means that if Folder Redirection is configured for
a given user, the user will get their folders redirected on every computer they log on to. While it is desirable in
some scenarios, it might be an unwanted feature in others. It was the case in our deployment where users log on
to a variety of different computers including shared computers and computers from other users. When deploying
Folder Redirection in conjunction with the Offline Files technology as we did in our solution, every user logging on
to a computer has a copy of their redirected data stored on to the local hard drive. When several different users
log on to the same computer, this can cause the local hard drive to quickly run out of space.

As of today, there is no built-in mechanism in Windows through which an administrator can specify on which
computers Folder Redirection should apply. However, it is easy to put in place a custom solution that achieves this
result with the help of a Windows Management Instrumentation (WMI) filter and a combination of a computer
startup script and a logon script. The implementation section in this document provides the necessary information
to put in place this computer-specific Folder Redirection technique.

In our deployment, the administrator of the solution is made aware of the computers on which Folder Redirection
should apply for given users. This information is then stored in a custom database and, by using the
aforementioned technique, only specific computers get the redirection policy applied.

Determining the type of client operating system

The type of operating system installed on end user computers affects their Folder Redirection experience. Folder
Redirection and Offline Files are technologies that were introduced in Windows 2000. Since then, many
improvements have been made and new features introduced, especially to handle the behavior on slow networks.

Our users mainly use Windows Server 2008 R2, Windows Server 2008, Windows 7, and Windows Vista as their
operating systems. Scoping our deployment to those operating systems simplified our deployment and allowed us
to take advantage of the latest features available. Including older versions of client operating systems such as
Windows XP is possible but adds complexity and does not provide the same functionalities as Windows 7 and
Windows Vista. For instance, the lack of APIs for Offline Files makes the implementation of any automatic
background synchronization mechanism challenging. The Offline Files feature was completely redesigned for
Windows Vista. For more information, see What's New in Offline Files for Windows Vista
(http://go.microsoft.com/fwlink/?LinkId=166654).

Planning around network characteristics

As shown earlier, the location of the users and the characteristics of the network link used to connect to the
corporate network have a deep impact on how we implemented the solution and the technologies we put in place.
For the Folder Redirection technology, there are two important factors to consider, both having an impact on the
initial redirection experience:

• The end-to-end throughput of the link between the client computer and the domain controller used
to authenticate the user logging on to the client computer
• The end-to-end throughput and latency of the link between the client computer and the folder
redirection server

When the user logs on to their client computer after the administrator has applied the Folder Redirection policy
setting to their account, the Group Policy engine will first evaluate the throughput of the link between the client
computer and the domain controller that was used to authenticate the user. If the speed of the link is lower than a

21
certain threshold (a configurable value that is 500 Kbps by default), the Group Policy engine will determine that a
slow link logon has occurred and policy settings should not be applied, including the Folder Redirection policy
setting. This mechanism was put in place to avoid long logon times for users attempting to log on to the corporate
network through a slow Remote Access Service (RAS) connection. In all the cases, it is important to note that for
the Folder Redirection policy setting to apply, the user needs to be connected to the corporate network at the
time of logon, either through RAS or a direct connection, because the Folder Redirection policy setting is only
applied at logon and not during a Group Policy background refresh. Similarly, the policy setting will not apply if the
user performs a logon while disconnected from the corporate network (cached logon) and subsequently uses RAS
to connect to the corporate network.

The characteristics of the network link between the client and the Folder Redirection server also has an impact on
the Folder Redirection process. On Windows Vista, when Folder Redirection applies, we know that the content of
the local folders is moved over to the server during the logon operation. In extreme cases with a very large amount
of data to move over a slow network, it could take up to an hour for the first logon to complete (by default, the
Group Policy application process will stop after one hour and let the logon process continue). For this reason,
knowing the amount of data each user has in their local folders prior to applying the policy setting (by using the
script mentioned previously), along with the characteristics of the networks between the file server and the
clients, are two important data points when planning for a deployment.

These considerations have different implications from a planning point of view depending on user categories as
defined in Table 5.

Network Characteristics Impact

User category Clients to domain controller network impact
Local users Users have a fast (>100 Mbps) LAN
connection to the domain controller
authenticating them. The throughput is
greater than the slow link Group Policy
default threshold. The Folder Redirection
policy setting applies when the user logs on
after the policy setting has been set by the
administrator.
Near branch Users also have a fast LAN connection to the
office users domain controller authenticating them.
Although there is a WAN link between the
branch offices and the main office, each
branch office has a local domain controller
performing user authentication. The behavior
here is equivalent to that of the local users
case.
Far branch Same behavior as that of the near branch
office users office users.
Mobile users The link between the client and the domain
controller can potentially be slow for this
category of users and below the default 500
Kbps threshold. If the user does a RAS logon
on such a slow network or does a cached
logon, the Folder Redirection policy setting
Clients to file server network impact
The connection between the clients and the file
server is also a fast LAN. The file copy operation
time on Windows Vista during the Folder
Redirection policy setting application will not be
a concern.
The connection between the clients and the file
server is WAN with 80 ms–110 ms latency. Our
testing has shown that the time of the copy
operation on Windows Vista was still
acceptable.
Before rolling out the deployment, it is useful to
communicate to those users the potential delay
during the first logon.
Our users in the far branch office would have a
local file server dedicated to them. The behavior
here is equivalent to that of the local users.
The link between the client and the file server
can also be slow in this case. Latency and
throughput can vary widely depending on the
underlying network used, and the copy
operation time on Windows Vista can similarly
vary widely.

22
 will not be applied. Effectively, this means by Before rolling out the deployment, we
default that the policy will apply only with communicated the experience to our mobile
RAS logon on a faster connection (through user base to set expectations on the potentially
high speed Internet for instance) or when the long RAS logon time right after the policy is put
user is directly connected to the corporate into effect. Users can then make the
network (travelling user back in the office). appropriate decision of doing a RAS logon or
waiting to be back in the office with a direct LAN
connection.
Table 5 - Network characteristics impact

It is important to emphasize that the folder redirection process exposed above happens only once after the policy
setting has been deployed by the administrator. After the folders are successfully redirected, none of the above
will happen during subsequent logons provided that the Folder Redirection policy setting has not been changed by
the administrator.

It is also important to emphasize that the connection from the clients to the file server matters in the folder
redirection process mainly when you plan to deploy Windows Vista clients or operating systems prior to Windows
Vista. If the Folder Redirection policy setting is deployed on Window 7 clients, the delay experienced during the
first logon is limited even when the network connection is slow.

Planning for quotas deployment

We wanted to control the amount of space consumed on the server by each user. We used File Server Resource
Manager directory quotas to enforce our space management policy. As a general rule, we planned to enforce a
10 GB quota for every user in the deployment. We made exceptions and provided more space upon request with
appropriate business justification.

Before deploying quotas, it is important to understand how the technology interoperates with Folder Redirection
to avoid issues. The main problem to avoid is a user running out of quotas during the initial file merge process of
the Folder Redirection operation. Typically, this can happen if a user has a large amount of data in his local folders
to be redirected, in excess of the quota limit set on the server (10 GB in our case). Here also the behavior differs
between Windows Vista and Windows 7.

In Windows Vista, the merge process will start between the client and the server regardless of the amount of data
to merge and regardless of the quota available on the server. During that process the content of the local folders
not already present on the server is copied over to the server. For each user profile folder, and if the copy
succeeds, the folders are redirected and the local content is deleted. If the copy fails (because of a quota limit hit
for instance) the merge process will stop, leaving the content on the server and local client folders, which will
result in the failure of the redirection operation. Since Folder Redirection did not apply correctly, the same process
happens again at each subsequent logon until the problem is resolved and Folder Redirection succeeds. To recover
from this situation, the quota needs to be increased or the user must remove some of the data that failed to be
redirected both on the client computer’s local user profile folders and on the server.

In Windows 7, the merge process is handled differently. When Folder Redirection applies for a specific user profile
folder, the system first checks if there is enough space or quota on the server to perform the redirection operation.
If there is enough space, the content of the user profile folder to redirect is copied into the Offline Files cache. This
operation being only a local file copy, no data is transferred over the network at this time, making the logon
process faster. After the user has successfully logged on, Offline Files will perform an initial synchronization
operation, merging the content on the local cache with the one on the server. In the scenario where not enough

23
quota is available on the server, there would still be space issues to be resolved for Folder Redirection to apply
successfully, but the process is more streamlined and efficient.

To avoid space issues during the deployment, the use of the soft quota feature of File Server Resource Manager is
recommended. This feature allows administrators to define quotas that are not strictly enforced. The user will be
allowed to store data past the quota limit but the administrator and the end user can be notified by e-mail if a
certain percentage of the quota is reached. This allows the administrator and the user to be aware of the space
issue while allowing the Folder Redirection process to proceed uninterrupted. After Folder Redirection is deployed,
the IT organization can address the cases of users breaching their quota according to its space management policy
and subsequently enforce hard quotas if required.

Data Availability and Mobility

Our SLA stipulates that users must be able to access their data 99.99% of the time independently of the
connectivity they have to the file server. This includes being able to access redirected folders from the client
computer when there is no network connectivity or when the server is unavailable. Furthermore, performance
when working with the redirected folders must be comparable to the experience when working with documents
stored on the local computer’s hard drive. Particularly, accessing a document in the redirected folders when
connected to the corporate network over a slow link must be as fast as accessing a document stored locally.

Meeting those stringent requirements would not be possible by only redirecting folders to a remote share and
always performing file accesses over the network. It is, however, possible to achieve with a technology capable of
caching the files on the local computer and accessing the cached copy in an intelligent way. The Offline Files
technology in Windows provides this functionality and has been designed to work hand in hand with Folder
Redirection to provide anytime access to data with a high level of performance.

Deploying Offline Files

When deploying the Folder Redirection Group Policy setting for specific folders, those folders are also
automatically cached by default on the client computer by using the Offline Files technology. This allows users to
transparently access files from the cache when no network or a slow network is present with the possibility of
synchronizing the changes between the client and the server in the background. When deploying Offline Files with
Folder Redirection, the following needs to be considered:

• Versions of the operating system installed on users’ computers

• Size of the users’ computers Offline Files cache
• Possible folder states and optimum settings depending on users’ category

Offline Files and operating system versions

The Offline Files feature is enabled by default on the following client operating systems:

 Windows 7 Professional, Windows 7 Enterprise, Windows 7 Ultimate

 Windows Vista Business, Windows Vista Enterprise, Windows Vista Ultimate

This feature is turned off by default on Windows Server operating systems. For us, this includes Windows Server
2008 and Windows Server 2008 R2. To enable Offline Files on server operating systems, the Desktop Experience
feature must be installed and enabled.

24
Without Offline Files enabled, access to the redirected folders will happen online without any assistance from local
caching. This means that the content of the redirected folders would not be available if the server could not be
reached and access would be slow in case the server can only be reached over a slow network.

While it is possible to administratively enable Offline Files on server operating systems, we did not consider this
option in our deployment. In our case, the majority of users use Windows client and we will allow users of server
operating systems (which are typically power users) to install the feature by themselves if they so desire.

Offline Files cache size

As we learned previously, redirecting the content of a folder when using the Offline Files technology involves
copying data into the local Offline Files cache. For this operation to succeed, it is necessary for the client computer
to have enough disk space dedicated to the cache. By default, the size of the cache is 25% of the system volume
free space when the cache is initialized. The maximum amount of disk space allocated to the Offline Files cache is
configurable through Group Policy for Windows Server 2008 R2, Windows Server 2008, Windows 7, and Windows
Vista.

Depending of the amount of data stored in the redirected folders, the size of the Offline Files cache, and the disk
space available on the client computer, it is possible for the local computer to not have enough disk space to store
all content. This is especially true for users of netbooks equipped with solid state drives which—at the time of
writing this white paper—offer limited storage capacity, or when users have a separate small system partition. In
the case where not enough space is available to cache the whole content of the redirected folders, the cache will
be filled to capacity, and an error stating that the quota has been exceeded will be raised to the user during
synchronization operations. In this state, files that have not been cached will only be available when there is
network connectivity between the client and the server.

In our deployment, we maintained the default maximum size for the Offline Files cache. According to our hardware
inventory, the client computers deployed had enough disk space to hold the maximum amount of data allowed
(10 GB) with the default cache size.

25
Possible folder states and optimum settings

Folder states

After the redirected folders are cached, they can be available to the user in different states, depending on the
connection with the server, the settings deployed by the administrator, and the user intent. Table 6 represents the
different states and the impact that they have on where file operations happen and how the changes are kept
synchronized with the server.

Working States

Folder state Condition File operation Client server relationship

Online The client has a fast (above Read operations are Highly coupled
slow link threshold serviced from the cache. Any change goes directly to both
conditions) connection with All other operations go to the server copy and the cached
the server. the server or go to the copy.
server and to the cache as
is the case for write
operations.
Offline The client has no connectivity The user operates on the Decoupled
(not connected) to the server or the server is files from the cache only. Any change is made only to the
unavailable. cache and will be subsequently
synchronized to the server when
it becomes available.
Offline The client has a slow (below The user operates on the Loosely coupled
(slow slow link threshold files from the cache only. Any change is made only to the
connection) conditions) connection with cache and needs to be
the server. synchronized with the server
either in the background or
upon explicit user request.
Offline The user has put their folders The user operates on the Loosely coupled
(working into Offline (working offline) files from the cache only. Any change is made only to the
offline) through the user interface. cache and by default will only be
synchronized with the server
upon explicit user request. The
administrator can set a policy to
cause changes to be
automatically synchronized with
the server in the background.
Table 6 - Working states

26
States transitions
Figure 5 describes the different possible states and how to transition from one to another.

Offline (Not
Connected)

1
X 2
4

Online 5

Offline Offline
(Slow (Working
Connection) Offline)
3
6
Figure 5 – Offline Files state transition

1. Online to Offline (Not Connected)

This transition happens whenever the server cannot be reached during a file access operation.
2. Offline (Not Connected) to Online
This transition happens when server availability has been detected. The Offline Files engine will attempt
to reach the server periodically every 5 minutes or whenever a new network has been detected (such as
connection through RAS, plugging in a network cable, or connecting to a wireless network).
3. Online to Offline (Slow Connection)
This transition happens when the conditions of the network link between the client computer and the
server are deemed as slow. The detection happens when files are accessed. The administrator can
configure the definition of a slow link through Group Policy settings by using a throughput threshold
and/or a latency threshold. In Windows Vista there is no default latency threshold for Slow Link mode
whereas in Window 7 the default value is 80 ms.
4. Offline (Slow Connection) to Online
This transition happens when the user expresses the intent of working online through the user interface.
On Windows 7, the Offline Files engine will detect when the network connection between the client and
the server ceases to be slow and transitions back to online automatically if such a condition has been
detected. This detection happens during synchronization between client and server. Windows Vista and
operating systems prior to Windows Vista will not automatically transition from Offline (Slow Connection)
mode to Online mode.
5. Online to Offline (Working Offline)
This transition happens when a user clicks the “Work Offline” button in Windows Explorer.
6. Offline (Working Offline) to Online
This transition happens when a user clicks the “Work Online” button in Windows Explorer.

27
Background synchronization
When the redirected folders are in the Offline (Slow Connection) mode, it is possible to maintain consistency
between the client and the server by using manual (user-initiated) synchronizations or automatic background
synchronizations. While manual synchronization is available by default on both Windows Vista and Windows 7,
automatic background synchronization is only available on Windows 7. The background synchronization feature
allows the administrator to centrally configure the synchronization frequency and synchronization window. In
addition, on Windows 7, the administrator can set a policy to enable automatic background synchronization when
in Offline (Working Offline) mode. Although an automatic background synchronization feature is not built into
Windows Vista, it is simple to write a small application by using the Offline Files APIs launched via a scheduled task
to perform the same functionality. The implementation section will describe in more detail how this can be
achieved.

Optimizing folder states based on user categories

To guarantee the best user experience, we needed to correctly optimize the Offline Files settings based on the
characteristics of the underlying network used by clients to connect to the server. Table 7 represents the user
experience we expected based on our various user profiles.

User category Desired predominant state Desired user experience

Local users
Near branch office users
Far branch office users
Mobile users
Online Users are connected to the file server through a fast
LAN link. We expect them to access their files online
directly on the server. On rare occasions, if the server
is unavailable, users will temporarily work offline,
automatically transitioning back online when the
server becomes available again.
Usually offline Users are connected to the file server through a WAN
link. To maintain a level of performance satisfying our
requirements, we configured the system to have
users predominately working in Offline (Slow
Connection) mode with background synchronization
happening at regular intervals. Users can also
sporadically work offline if the server is unavailable.
Online Because the users for this branch have a local file
server, the experience is the same as that of the local
users’.
Variable For these users, we wanted the state of the folders to
adapt to the various types of network conditions that
would be encountered. For example, the state should
be Online if the user has a direct LAN connection with
the file server, Offline (Slow Connection) if the user
connects to the corporate server through Remote
Access Services, and Offline (Not Connected) if the
user has no connection to the file server.
Table 7 - Optimizing folder states based on users’ categories

Deploying Failover Clustering

The Offline Files technology diminishes the need for a highly available file server because users still maintain access
to their data through their local cache if the file server is down. However, an unavailable file server will provide a
degraded service because at least the following operations will not be possible during an outage:

28
 • Adding and removing users from the deployment
• Synchronizing files between client and server
• Accessing previous versions of files by using Shadow Copy for Shared Folders
• Recovering files from backup and placing the files in their original location

To maintain the highest level of service at all times, we decided to implement a highly available file server by using
the Windows Server Failover Clustering technology. We implemented a two-node cluster functioning in active-
passive mode.

To build an effective failover cluster, consider the following recommendations:

1. Servers: We recommend that all servers in a cluster are of the same make and model with similar system
specifications. Processor, memory, network adapters, and BIOS versions should be consistent across each
computer.

The deployment team implemented a dual server failover cluster configuration; the computer
specifications are defined in the Implementation section later in this white paper.

2. Network adapters: The network infrastructure that connects your cluster nodes is important to
maintaining effective communications. It is advised to avoid having single points of failure where possible
and to ensure that there are at least two networks, one to support application or file access and another
for internal cluster communications. The use of teamed network adapters for application or file access is
typically supported by solution providers. It is also advised to avoid mixed negotiation between the
network adapters and the network switch ports. If the network switch port is set to auto negotiate, it is
not recommended to force negotiation on the server network adapters.

The deployment team implemented two network adapters per cluster node, one for file access, and the
other for internal cluster communication. The network adapters allocated for file access are connected to
corporate 1-Gbps switch ports with both the switch ports and network adapters set to auto-negotiate.
The second network adapter, used for cluster communication, uses a crossover cable between both
nodes. The network adapters are set to auto-negotiate and automatically IPv6 LinkLocal IP address. No
configuration is required on this network.

3. Storage controllers and arrays for failover clusters:

 Serial Attached SCSI (SAS) or Fibre Channel: When using SAS or Fibre Channel, the mass-storage
device controllers that are dedicated to the cluster storage should be identical in all clustered
servers. It is not recommended to mix and match vendor adapters. Additionally, consistent
drivers and firmware versions should be used.
 iSCSI: When using iSCSI, each clustered server must have one or more network adapters or host
bus adapters that are dedicated to the clustered storage. The network used for iSCSI should not
be used for cross-cluster nodes communication. We also recommend using a Gigabit Ethernet
network or higher.
Additionally, teamed network adapters should not be used because they are not supported with
iSCSI.
For more information about iSCSI, see iSCSI Cluster Support: Frequently Asked Questions
(http://go.microsoft.com/fwlink/?LinkId=61375).
 Storage array: We recommend using shared storage that is compatible with Windows
Server 2008 failover clusters, which requires support for SCSI Primary Commands-3 (SPC-3). The
storage should also support Persistent Reservations (PR) as specified in the SPC-3 standard.

29
 Ensuring that the storage supports PR natively or with an appropriate firmware upgrade can be
achieved by consulting with the storage vendor or by running the Failover Cluster Validation
Wizard included with the cluster feature.
For a two-node failover cluster, the storage should contain at least two separate volumes (LUNs),
configured at the hardware level. One volume will function as a witness disk (described in the
next paragraph). One volume will contain the files that are being shared to users. The witness
disk is a disk in the cluster storage that is designated to hold a copy of the cluster configuration
database. For a two-node cluster, the quorum configuration will be Node and Disk Majority, the
default for a cluster with an even number of nodes.
 Multipath I/O software: In a highly available storage fabric, it is possible to deploy failover
clusters with multiple host bus adapters by using multipath I/O software. This provides the
highest level of redundancy and availability. For Windows Server 2008, the multipath solution
must be based on Microsoft Multipath I/O (MPIO). Hardware vendors usually supply MPIO
device-specific modules for their devices. Windows Server 2008 includes several device-specific
modules as part of the operating system.

The deployment team chose to use an existing shared Fibre Channel storage array, which was used to
provide two volumes, one for a 10-GB witness volume, the other for a 2-terabyte volume to support user
data. Each host was connected to the fabric via a single host bus adapter without the use of MPIO.
Although this could be seen as a Single Point of Failure (SPOF), it was not the team’s objective to eliminate
all SPOFs within the deployment because of the added resiliency provided on the clients through Offline
Files.

4. Software requirements for a two-node failover cluster: The servers for a two-node failover cluster must
run the same version of Windows Server. They should also have the same software updates (patches) and
service packs. The deployment team implemented Windows Server 2008 R2 Enterprise on both nodes. No
hotfixes or service packs were available at the time of writing this white paper because the version used
for the solution was a pre-release build.

Data Protection and Portability

Prior to implementing the solution, users maintained their own user profile folders and corresponding
unstructured data on their various client computers, which were a mix of laptops and desktops. The content on
these computers was typically unprotected. Users were infrequently impacted by random data loss due to
hardware failure, or even accidental data loss due to users wiping and reinstalling their operating system. By
implementing data centralization, the end users were able to realize the benefits of a single representation of their
user profile folders across all their domain-joined client computers along with an effective data protection model.

The deployment team was tasked with implementing a data protection model that strived to achieve a Recovery
Point Objective (RPO) of near zero data loss. The goal was to use a backup infrastructure located in the head office
by using a near Continuous Data Protection (CDP) model for the unstructured data stored on the file servers.
Another goal was to mitigate performance impact on users while also minimizing WAN traffic as a result of backing
up the file server located in the branch offices. The final goal was to provide a service that allowed users to
perform their own data recovery operations for previous versions of files and folders without the need for
involving IT support staff.

30
Understanding the challenges
The first challenge for the deployment team was to achieve an effective yet consistent backup window against the
servers independent of their geographical location. This has become more of a challenge for many IT
administrators who are being put under increased pressure to reduce or even eliminate backup windows.
However, as data volumes continue to grow, so too does the required backup window. Data growth is exploding
and the constant need to have data accessible to everyone is also increasing dramatically. Often companies are left
with little to no backup window and need to continually look at ways to adjust their backup methodologies.

The second challenge was to mitigate the impact of backup itself on the WAN links, which is sometimes difficult to
achieve during Full, Incremental, or even Differential backups. With a goal to implement a centralized backup
solution that also provided a near CDP capability, it was clear to the team that the typical mid-market backup
product would make this challenge hard to achieve.

The third goal was to limit any sustained noticeable performance impact during Full, Incremental, or Differential
backups.

Backup methodologies
This section provides an overview of the differences between Full, Incremental, and Differential backups.

Full backup
The most complete type of backup is typically referred to as a Full backup. As the name implies, this type of backup
makes a copy of all data to another set of media, which can be tape, disk, or alternate media types. The primary
advantage of performing a Full backup during every operation is that a complete copy of all data is available on a
single set of media. However, the disadvantage is that it takes longer to perform a Full backup than other types, as
all the data on the file server to be protected (Source) has to be copied to the backup server (Target). The time to
complete the backup operation is dependent on the amount of data and the type of connectivity between the
Source and the Target. When using a centralized backup solution where content is to be moved over a WAN link,
completing a Full backup can be time consuming and costly especially when the WAN link is limited in bandwidth
and charged based on its utilization.

The recovery process from a full data loss event on the Source server requires a single stage restore operation.
Restoration is complete by restoring the last Full backup.

Many customers however, will choose to employ a weekly Full backup and complement it with an Incremental or
Differential backup on a daily or more frequent basis.

Incremental backups
An Incremental backup operation results in copying only the data that has changed since the last Full or previous
Incremental backup operation.
Because an Incremental backup will only copy data since the last backup of any type, it may be run as often as
desired, with only the most recent changes stored. The benefit of an Incremental backup is that it copies a smaller
amount of data than a Full backup. Thus, these operations will complete faster and require less storage to store
the backup.

However, the recovery process from a full data loss event on the Source server may require a multi-stage recovery
process. Restoration will require the last Full and all subsequent Incremental backups to be restored.

31
Differential backups
A Differential backup operation is similar to an Incremental backup the first time it is performed, in that it will copy
all data changed from the previous backup. However, each time it is run afterwards, it will continue to copy all
data changed since the previous Full backup. Thus, it consumes more storage than an Incremental on subsequent
operations, although typically far less than a Full backup.

The recovery process from a full data loss event on the Source server may require a multi-stage recovery process.
Restoration will require the last Full and the last Differential backup to be restored.

Data Protection Manager

The deployment team’s challenge to implement a backup solution that achieved a near Continuous Data
Protection (CDP) model with minimum impact on WAN links was realized with the implementation of Microsoft’s
own Data Protection Manager (DPM) 2007 SP1.

The far branch office file server had, at the time of initial deployment, approximately 118 GB of consolidated data.
Moving this data on a typical Full backup schedule would have taken more than six hours to complete based on
WAN bandwidth and utilization. This backup window was validated by using various mid-market backup engines
with both tape and disk as a backup target. Moving this amount of data on a daily basis was not viable due to the
impact on the WAN link between the head office and the far branch office. Implementing subsequent Incremental
or Differential backups was viable, but neither met the objective of achieving a near CDP model.

The team tested DPM to validate capability to meet their data protection challenges. The centralized DPM server
was used to protect the file servers in the head office and the far branch office. Enabling centralized data
protection for the server in the far branch office was the team’s biggest concern. These concerns, however, were
mitigated with the features offered by DPM.

The team created two DPM protection groups, one for the far branch office server and another for the head office
server. This resulted in the creation of an initial replica of the data for each server created on a storage pool on the
DPM server, the amount of data transferred over the network during this operation being comparable to a
standard Full backup implemented by other backup products. The time to complete the initial replica of
approximately 118 GB of data for the far branch office server over the corporate WAN link was similar to the time
to complete the initial replica of approximately 800 GB of data for the head office server over the LAN. Both initial
replica jobs completed within six hours. See Table 8 for reference.

Time to Complete Initial Full Replica with DPM

Location Data size Full replica time Network type

Head office ~800 GB 6 hours 40 minutes LAN
Far branch office ~118 GB 6 hours 27 minutes WAN
Table 8 - Time to complete initial full replica with DPM

After the initial replica was completed, there would be no need to repeat the operation because the replica would
be updated with periodic incremental synchronization operations according to a set schedule. This removed the
need to repeat scheduled Full backup operations and effectively allowed the team to remove 118 GB worth of
network traffic to protect the server located in the far branch office, which otherwise would have impacted the
WAN link on a daily or weekly basis depending on data protection needs.

The deployment team maintained the default incremental synchronization policy which runs every fifteen minutes
for the head office server and every two hours for the far branch office server. This synchronization ensures that

32
any data changes since the last synchronization are transferred and applied to the replica. The team was able to
achieve synchronization operations on average within a two-minute period. Albeit, a large data change of five
gigabytes occurred between synchronization intervals on the far branch office server which took over 3 hours and
30 minutes to complete. Synchronization times vary throughout the day and are impacted by the rate of change in
data on the protected servers and the WAN link utilization. Table 9 provides some statistics from the deployment.

Time to Complete Scheduled Synchronizations with DPM

Location Data size Synchronization time

Head office Max 221 MB 1 minute 36 seconds
Average 10 MB 1 minute 7 seconds
Far branch office Max 5,258 MB 3 hours 30 minutes
Average 50 MB 2 minutes 26 seconds
Table 9 - Time to complete scheduled synchronizations with DPM

DPM’s ability to enable an initial replica without a requirement to repeat the operation, along with subsequent
incremental synchronization capabilities, allowed the team to achieve most of their data protection requirements.

User-enabled data recovery

The final goal of data protection was to implement a solution that allowed end users to recover previous versions
of user profile folder content without the need for any IT involvement.

Shadow Copies for Shared Folders (also known as Previous Versions) enabled the team to achieve a point-in-time
copy of files that are located on the file servers. The solution allows end users to recover files that are accidentally
deleted or overwritten, or to compare versions of files if and when required. To complete these operations, a user
must be working in an Online mode from an Offline Files point of view. If connected to the network, this can be
easily achieved by manually transitioning online by clicking the “Work Online” button in Windows Explorer.

Implementing Shadow Copy for Shared Folders is relatively easy, requiring less than four mouse clicks. Most
administrators maintain the default snapshot schedule, which is two snapshots per day (7:00 A.M. and 12:00 P.M.),
five days per week (Monday to Friday). The frequency can obviously be adjusted and extended throughout the
weekend with a maximum of 64 snapshots per volume. Shadow Copy for Shared Folders can have a slight
performance impact due to copy on write semantics; on a lightly loaded server, no noticeable performance impact
should be detected. However, if the server is expected to be heavily loaded, we suggest that you allocate
dedicated disks to offload I/O activity. The default is to allocate 10% additional capacity to cater for snapshot
space.
The deployment team chose to maintain two snapshots per day but extended the operation to occur on Saturday
and Sunday. The server load was not expected to be too heavy, so storage was not dedicated specifically for the
snapshots. Snapshot allocation was maintained on the same volume that stored the data, with the default space
allocation of 10%.

DPM provides a similar capability to Shadow Copy for Shared Folders known as End-User Recovery, which is an
effective solution. DPM can increase the amount of snapshots that an end user can recover from and does not
require the 10% storage allocation or have any performance impact on the file servers. The deployment team
chose not to implement End-User Recovery because some of the dependencies were outside the group’s control,
specifically the requirement to complete an Active Directory® schema update on corporate domains.

For more information, see Planning for End-User Recovery (http://go.microsoft.com/fwlink/?LinkId=166655).

33
Data recovery planning
Some organizations may consider that using Offline Files will eliminate the need to maintain normal backup
activities. They incorrectly believe that having their users’ unstructured data located on all client computers and
subsequently on the file servers will meet their data protection needs. This is not the case, and backing up the file
servers is a key requirement and the only way to ensure a full recovery of data in the unlikely event that the
integrity of the data is compromised on the file servers.

Consider the scenario where the back-end storage array is impacted by a multi-drive failure that compromises a
RAID group resulting in the loss of the NTFS volume storing all users’ data. In this case an IT administrator will have
to repair the RAID group and recreate a new volume to enable recovery of the data. It should be made clear that
the content in the Offline Files cache cannot be resynchronized back to the new volume as a mechanism to
recreate the data set because the Offline Files synchronization algorithm will interpret the missing files and folders
on the share to mean that those files or folders were intentionally deleted and need to be deleted from the client’s
local cache on the next synchronization operation. Therefore, if the IT administrator recreates the new volume and
subsequently creates a share without restoring the data first, this can result in the deletion of Offline Files cache
content.

The correct mechanism in the failure scenario described above is for the IT administrator to repair the RAID group,
create a new volume, and follow this with a full volume restore from the last known good backup without creating
a share for the users to access the data. Only when the restore is complete should the original share be recreated,
which will allow users to reconnect and synchronize the changes in their Offline Files cache back to the file server.
This will allow for a complete recovery to achieve the zero data loss Recovery Point Objective.

Having a well-documented step by step procedure to enable data restoration is a key requirement to prevent data
loss in any Folder Redirection and Offline Files solution deployment.

Protecting the Data Protection Manager infrastructure

Microsoft Data Protection Manager 2007 (DPM) enables protection for file and application data, and provides fast
and efficient recovery. DPM, like any other infrastructure server, needs to be protected from data loss or
corruption.

For more information about protecting the DPM server, see Preparing for Disaster Recovery
(http://go.microsoft.com/fwlink/?LinkId=166657).

34
Data Security and Privacy Considerations
Before implementing the solution detailed in the planning section, it is important to discuss the security and
privacy considerations. In this section, we will talk about the different security threats, vulnerabilities, and possible
mitigation options.

Figure 6 shows the architecture of the planned solution.

Head Office
Far Branch Office
Folder Redirection
Infrastructure Folder Redirection
Users Users Infrastructure

Users
Failover Cluster DPM Server
Stand-alone Server
Users Users

Users
Node1 Node 2
Users Users
~220 users have LAN connectivity to File Serving ~100 users have LAN connectivity to
infrastructure File Serving infrastructure

WAN Link
155Mb/s
50 to 100ms RTT

Users Users Users Users

Mobile / Home Users
Near Branch Office Near Branch Office Connect to servers
through local VPN

Figure 6 - Solution architecture

From a security point of view, there are three areas of concern:

1. Back-end infrastructure (folder redirection and backup servers)

2. Client computers (desktops and laptops inside and outside corporate facilities)
3. Network (corporate and remote access)

For each of these areas, we will list the potential security risks and then discuss the mitigation options available.

Back-end infrastructure security

Threat #1 - Physical access to back-end infrastructure

An attacker with physical access to the back-end server infrastructure may be able to access user files and other
data resulting in data theft, tampering, or destruction. For example, an attacker who has physical access may be
able to use any of the following methods to access or tamper with its content:

 Remove the storage and attach to another computer to access its content.
 Perform a parallel operating system installation or boot the server to an alternate operating system to
enable access to content on the volumes.
 Use third-party utilities to change the administrator password.

35
Threat #1 mitigation
The simplest solution to help mitigate this threat is by placing the back-end infrastructure in a secure data center
where access can be limited to a set of known authorized personnel. For the case where an attacker still manages
to gain physical access to the system, data security can be enhanced by the use of encryption technologies, such as
Encrypted File System (EFS) and BitLocker™ Drive Encryption.

Threat #2 - Unauthorized data access by other users

An attacker tries to gain access to data belonging to other users residing on the same server.

Threat #2 mitigation
Folder Redirection, by default, grants users exclusive rights to their redirected content by setting appropriate
access control lists (ACLs) on the directories.

Threat #3 - Unauthorized data access by server administrator

A rogue administrator of the server tries to read, tamper, or delete files belonging to users.

Threat #3 mitigation
Folder Redirection ensures that the administrator of the server does not have NTFS permissions to user redirected
folders. However, the administrator could still gain access to the folders by taking ownership of the folders. This
kind of operation can be tracked by implementing effective event monitoring by using security auditing tools such
as Microsoft System Center Operations Manager.

Data on the server can also be secured by using Encrypted File System (EFS), which is a powerful feature for
encrypting files and folders on client computers and file servers. It enables users to help protect their data from
unauthorized access by other users or rogue administrators. For more information, see Encrypting File System
(http://go.microsoft.com/fwlink/?LinkId=166658).

The measures described above do not provide foolproof mitigations against a rogue administrator trying to access
the content because it is possible for any computer administrator to tamper with the operating system.

For more information, see The Administrator Accounts Security Planning Guide in the Microsoft Download Center
(http://go.microsoft.com/fwlink/?LinkId=166653).

Threat #4 - Host security

Attackers try to exploit known security flaws in the operating system. The potential impact of these attacks can
include server downtime, loss of data integrity, and stolen intellectual property. For more information about
security vulnerabilities, see The STRIDE Threat Model on MSDN (http://go.microsoft.com/fwlink/?LinkId=166659).

Countermeasure against threat #4

Host security can be enhanced by proper patching and update management of all the servers. Update
management is the process of controlling the deployment and maintenance of interim software releases including
patches into production environments. For more information, see the Update Management Process
(http://go.microsoft.com/fwlink/?LinkId=166661).

36
Client computer security

Threat #5 - Stolen laptops

The mobility of laptops demands additional protection of the data they store. A stolen laptop can mean loss of
sensitive data stored on that computer.

Threat #5 mitigation
The simplest mitigation to prevent this form of attack is to make sure that it doesn’t happen. Ensure that the
laptop with confidential information stays with you the whole time you are in a public environment. However,
thefts do occur and there are mechanisms in Windows that will make the data in the laptop difficult to read by the
thief, being:

 Use of password: If your laptop is joined to a domain, each time you start it—even when you aren’t
physically on the corporate network—you still have to enter your password.
 Encrypting files: The use of encryption techniques like EFS and BitLocker ensures that the data is not
readily readable by the thief.

For more information, see The Case of the Stolen Laptop: Mitigating the Threats of Equipment Theft
(http://go.microsoft.com/fwlink/?LinkId=166662).

Threat #6 - User data accessible to client computer administrators

This threat is different from the one discussed earlier about server administrators being able to access the
contents of the redirected folders on the server. The Offline Files solution adds an additional risk element because
the user’s data is now downloaded to all domain-joined computers to which the user logs on. The most common
scenario is when a user logs on to a shared computer or another person’s computer. Although the user logs off
from the computer, the user’s documents are downloaded into the local cache of that computer (provided Offline
Files has been enabled on that computer). The computer administrator can then access this data, for example by
taking ownership of the Offline Files cache folder.

Threat #6 mitigation
Offline Files cache encryption allows for cached copies of redirected content to be encrypted by using EFS. When
this option is enabled, each file in the Offline Files cache is encrypted with a public key from the user who cached
the file. Thus, only that user has access to the file, and even local administrators cannot read the file without
having access to the user's private keys. If multiple users share a computer and more than one user tries to use an
encrypted, cached copy of a particular file, only the first user to cache the file can access the offline copy of the
file. Other users will be able to access that file only when working online.

EFS protection policies can be centrally controlled and configured for the entire enterprise by using Group Policy.
When the Encrypt the Offline Files cache Group Policy setting is enabled, all files in the Offline Files cache are
attempted to be encrypted. The cached copy on the local computer is affected, but the associated network copy is
not affected. The user cannot decrypt Offline Files through the user interface. It should be noted that the cache is
sometimes in a partially encrypted state (for example, when some files attempted to being encrypted are open).
These files will be encrypted during subsequent logons. After all files are encrypted, the cache is put into a “fully
encrypted state.”

When this Group Policy setting is disabled, all files in the Offline Files cache are decrypted during the next logon.
Since the encryption/decryption task runs in the context of a given user, the task attempts to process any file to
which the given user has access.

37
When the Encrypt the Offline Files cache Group Policy setting is not configured, encryption of the Offline Files
cache can also be controlled by the user through the user interface.

An important point to note is that even though the data is encrypted on the client computer, it is transferred as
clear text over the network during synchronization or file access operations. We will discuss this further in the
network security section.

It is possible for administrators to implement the capability of enabling Folder Redirection on specific computers
belonging to the user instead of all computers (as is the default behavior). This can be implemented by using
Group Policy and some custom scripts. These are discussed in detail in the implementation section in this white
paper. Once enabled, the administrator can specify which computers they would like Folder Redirection to be
enabled on for each user, thereby not caching the content from the user’s profile folder on to all computers to
which they log on.

It is to be noted that the computer-specific Folder Redirection feature was not designed as a security mechanism
and can easily be overridden by the local administrator of a computer. In summary, a best practice is not to log on
to untrusted computers or computers with untrusted administrators.

Threat #7 - Re-use or decommissioning of computers

Computers can be reused by people other than the initial owner or user. The original owner’s data that is stored
on these computers is susceptible to being accessed by the new owners.

Similarly, computers that are decommissioned by the enterprise might contain data that can be stolen in the
process.

Threat #7 mitigation
To guard against threats mentioned above and to safeguard data stored on a stolen laptop, a data protection
feature named BitLocker Drive Encryption is available for both Windows Server and Windows client operating
systems. BitLocker Drive Encryption provides a seamless way to encrypt all data on an entire hard disk volume.
When BitLocker is configured, it works transparently in the background and does not affect typical use of the
computer or its applications. BitLocker encrypts the entire volume, so it can prevent many attacks that try to
circumvent the security protections in Windows that cannot be enforced before Windows has started.

BitLocker is a full-volume encryption mechanism that encrypts all sectors on the system volume on a per-computer
basis, including operating system, applications, and data files. BitLocker helps ensure that data stored on a
computer is not revealed if the computer is tampered with when the installed operating system is offline. It is
designed for systems that have a compatible Trusted Platform Module (TPM) microchip and BIOS. If these
components are present, BitLocker uses them to provide enhanced data protection and to help ensure early boot
component integrity.

BitLocker provides the following two primary capabilities:

 Per-computer encryption by encrypting the content of the operating system volume. Attackers who
remove the volume will not be able to read it unless they also obtain the keys, which in turn requires
attacking the recovery infrastructure or the TPM on the original computer.
 Full-volume encryption by encrypting the entire contents of protected volumes, including the files used
by Windows, the boot sector, and slack space formerly allocated to files in use. An attacker is therefore
prevented from recovering useful information by analyzing any portion of the disk without recovering the
key.

38
BitLocker can help create a simple, cost-effective decommissioning process. By leaving data encrypted by BitLocker
and then removing the keys, an enterprise can permanently reduce the risk of exposing this data. It becomes
nearly impossible to access BitLocker-encrypted data after removing all BitLocker keys because this would require
cracking 128-bit or 256-bit AES encryption.

For more information about EFS and BitLocker, see the Data Encryption Toolkit for Mobile PCs
(http://go.microsoft.com/fwlink/?LinkId=166663).

Network security

Threat #8 - Network security

With the measures discussed in the previous sections, we can secure the data on the client and server side. But the
network, if not properly secured, is susceptible to unauthorized monitoring and data access. An attacker could
monitor the network by obtaining and possibly tampering with sensitive data that is transferred through the
network.

Other network threats include interference and impersonation attacks. Examples of interference attacks are
viruses and worms, which are self-propagating malicious code that executes unauthorized computer instructions.

Impersonation attacks include IP address spoofing, when a rogue site or attacker intercepts authenticated
communications between legitimate users and presents altered content as legitimate; man-in-the-middle
spoofing, where captured packets are tampered and reinserted into an active session pipe; Trojan horses, which
are inserted to reconfigure network settings or grant administrator access and permissions to an unauthorized
person. All these attacks may cause unauthorized data access, data tampering, or loss.

Threat #8 mitigation
Before talking about network security, it is important to understand the different access scenarios possible. In the
case of our file server deployments, three access scenarios based on their geographical location and connectivity
to the corporate network are as follows:

• Client computers that connect to the server through the company’s local area network (LAN)
• Client computers that connect to the server through the company’s wide area network (WAN)
• Client computers that are mobile and connect to the server through remote access methods such as
Remote Access Service (RAS) and Direct Access (new in Windows 7)

Using features present in the Windows operating system, it is possible to isolate the domain and server resources
to limit access to authenticated and authorized computers. For example, a logical network consisting of computers
that share a common Windows-based security framework can be created with a set of requirements for secure
communication. Each computer on the logically isolated network can provide authentication credentials to the
other computers on this network to prove membership. Requests for communication that originate from
computers that are not part of the isolated network are ignored.

Network isolation is based on the Internet Protocol security (IPsec) and Windows Firewall with Advanced Security
suite of security protocols. Windows-based isolated networks do not require ongoing maintenance based on
changes in network topology or computers moving to different switch ports. The result is an isolated network that
leverages your existing Windows infrastructure with no additional costs associated with network reconfiguration
or hardware upgrades.

By leveraging Active Directory Domain Services (AD DS) domain membership and Group Policy settings, IPsec
settings can be configured at the domain, site, organizational unit, or security group level.

39
The computers on the isolated network are members of an Active Directory domain, which includes computers
that are locally connected to the organization network (through wireless or wired LAN connections) or are
remotely connected to the organization network (through a remote access connection) by using a virtual private
network (VPN) connection across the Internet .

The IPsec security mechanisms use cryptography-based protection services, security protocols, and dynamic key
management. IPsec transport mode is based on an end-to-end security model, establishing trust and security from
a source IP to a destination IP address (peer-to-peer). The only computers that must be aware of IPsec are the
sending and receiving computers. Each handles security at its respective end and assumes that the medium over
which the communication takes place is not secure.

For the home/remote access scenario, data security is implemented by using a VPN, enabling home-based or
mobile users to access the server on the corporate network. VPN encapsulates the data and uses a tunneling
protocol to transmit data. This document does not discuss in detail VPN security methods. For more information
about VPN, see Virtual Private Networks (http://go.microsoft.com/fwlink/?LinkId=166664).

For more information about network security using server and domain isolations, see Introduction to Server and
Domain Isolation (http://go.microsoft.com/fwlink/?LinkId=166666).

40
Implementation
The implementation part of this paper is not intended to be a step-by-step deployment guide. This section will
focus on providing guidance on the various customizations and hardware platforms that the deployment team
used to provide the Offline Files and Folder Redirection solution.

Server and Storage Hardware

The team did not acquire hardware specifically for the deployment. The servers and storage were allocated from a
pool of hardware available to the deployment team. The server hardware specifications are more than required to
support the deployment load and should not be considered as base requirements. The choice to use Failover
Clustering required the use of a shared storage array which was satisfied by an available Fibre Channel storage
area network (SAN) with enough capacity to cater to the team’s objective.

Domain Representation
The domain topology below is provided as a representation of the internal Active Directory forest. The actual
names of the domains are not representative of the internal deployment and are used here to highlight the
location of users and resources within the namespace as it relates to the Folder Redirection and Offline Files
deployment.

domain1 domain5
Folder Redirection
Infrastructure

Failover Cluster DPM Server

Head Office Users

Node1 Node 2

domain6 domain8
domain2 domain3 domain4

Head Office Near Branch Far Branch

Users Users Users

Far Branch
Folder Redirection
Infrastructure

Standalone Server
Head Office Head Office
Child Trust Users Users

Cross Forest Transitive Trust

domain7 domain9

Figure 7 - Domain representation

Figure 7 shows four Active Directory forests: domain1, domain5, domain6, and domain8. Each forest has a two-
way transitive trust established between each forest as represented by the dotted line. Domain1 has three child
domains: domain2, domain3, and domain4; the child trust relationships are represented by the solid lines. The
diagram is not intended to represent a required domain topology for enabling the solution, but more so is a
representation of the complexity that the deployment team had to take into consideration when planning the
deployment.

The Folder Redirection and Offline Files server resources are members of domain5. The servers maintain user
content and data protection needs as distributed across the various forests within the organization.

41
Failover cluster hardware
The failover cluster is a dual node configuration that uses identical server specifications, BIOS, and driver revisions
across both computers.

The amount of system memory (RAM) allocated is 32 GB, which is more than needed for the deployment but was
already configured in the hardware allocated from the pool. Having 4 GB to 8 GB of RAM would have sufficed for
the deployment, but the team chose to maintain the 32 GB to leverage a new feature in Windows Server 2008 R2,
known as block caching, that improves the time to complete a check disk (chkdsk) operation.

The operating system is installed on a pair of mirrored 146-GB drives connected to an internal SAS PCI RAID
Controller. The failover cluster has two Logical Unit Numbers (LUNs) allocated, a 10-GB RAID5 LUN for Quorum,
and a 2-terabyte RAID5 LUN to support a file server for Folder Redirection content and a script repository.

Table 10 defines clustered server specifications for reference.

Clustered Server Specifications

Processor 2 x Quad-Core - Processors (3.00 GHz)

Memory 32 GB
Network adapter 2 x 1 Gbps (1 for file traffic, 1 for cluster communication
connected at 1 Gbps)
Internal controller Embedded RAID Controller (read cache only)
Internal drives 2 x 146-GB SAS drives
OS LUN / volume 146-GB Mirror for C: Drive (operating system)
External controller Single 4-Gbps host bus adapter – default parameters
External drives (FC array) 9 x 300-GB FC
Data LUN / volume 2-terabyte RAID5 (Data and Scripts)
10-GB RAID5 (Quorum)
Table 10 - Clustered server specifications

Stand-alone server hardware

The stand-alone server configuration maintained in the far branch office location is a relatively basic specification.
The server uses a single 1-Gbps network adapter albeit connected into a 100-Mbps switch. The 100-Mbps setting
provides adequate throughput to support the local user community hosted on the server. The server uses direct-
attached storage (DAS) configured into a single RAID5 set across ten 146-GB drives with two logical volumes. The
first volume is 146 GB in size for the operating system; the second is a 1-terabyte volume for Folder Redirection
content and a script repository.

42
Table 11 defines stand-alone server specifications for reference.

Stand-alone Server Specifications

Processor 1 x Dual Core Processor (3.00 GHz)

Memory 4 GB
Network adapter 1 x 1 Gbps (file traffic at 100 Mbps)
Internal controller Embedded SAS Array Controller (read cache only)
Internal drives 10 x 146-GB RAID5 SCSI drives
OS LUN / volume 146 GB (operating system)
Data LUN / volume 1 terabyte (data & scripts)
Table 11 - Stand-alone server specifications

Operating system configuration

The operating system used for both the failover cluster and stand-alone server is Windows Server 2008 R2. The
initial deployment started on an early pre-released milestone build and rolled to various builds as they became
available, including Beta and Release Candidate. At the time of writing this paper, the final Release to
Manufacturing (RTM) version of Windows Server 2008 R2 was not available, so no hotfixes or service packs are
applicable.

More details about roles, role services, and additional features installed on the servers can be seen in Table 12.

Details Failover Cluster Servers Stand-alone Servers

Operating system version Windows Server 2008 R2 Enterprise Windows Server 2008 R2 Enterprise
Install drive C:\ C:\
Partition size 146 GB 72 GB
Domain membership Domain5 Domain4
Windows Update Download updates but let me Download updates but let me
choose whether to install them choose whether to install them
Hotfixes Not applicable at time of Not applicable at time of
deployment deployment
Roles installed File Services File Services
Role services installed File Server Resource Manager File Server Resource Manager
Features installed Windows Server Backup Windows Server Backup
Failover Clustering
Backup DPM Agent DPM Agent
Virus protection Microsoft Forefront™ Microsoft Forefront™
Table 12 - Operating system configuration

43
 FC Storage Array
File Server (Clustered)
Resources details:
Server Name: File-Server-1
Clustered Cluster Core IP Address (IPv4 and IPv6)
File Server 1 Quorum File Server:
Volume J$ Volume D$ Disk Drives: Volume J: (2TB)
2TB 10GB Shared Folders: J$
Share1_UserData_Domain2
Share1_UserData_Domain3
Share1_UserData_Domain4
Controller 1 Controller 2 Share1_UserData_Domain5
Share1_UserData_Domain7
Share1_UserData_Domain9

Cluster Core Resources

Resource Details
Server Name: File-Cluster-1
IP Address (IPv4 and IPv6
Fiber Switch Disk Drives: Volume E: (10GB)

Fiber Channel
Interconnect
Failover Cluster Failover Cluster
Node1 Node 2

Network 2
Heartbeat
Static IP Address
Cross Over Cable

Network 1
File Access
Cluster Management
DHCP IP Address User User

User User
Network Switch

Client Traffic

Figure 8 - Failover cluster representation

The failover cluster as represented in Figure 8 is relatively standard within a dual node configuration which we will
refer to as Node 1 and Node 2 for the purpose of documentation. There is a single Highly Available (HA) file server
instance which is active on only one node at a time. This model is typically classed as an active passive
configuration. The file server runs on Node 1 as an example and can be moved to Node 2 as part of controlled
move to address any maintenance needs on Node 1. In the unlikely event that Node 1 terminates due to hardware
or software failures, the HA file server will fail over to Node 2 automatically, restoring service to the users.

There are two network adapters per cluster node, one for client file and cluster management traffic, which we will
refer to as Network 1; the other for internal cluster heartbeat communications, which we will refer to as Network
2. Network 1 is connected to the corporate network and uses IPv4 and IPv6 DHCP assigned addresses. Network 2
uses a crossover cable that is ideal for a two-node cluster configuration and uses IPv6 Link Local IP address. All
network adapter properties are left at default.

Node 1 and Node 2 are connected via a single 4-Gbps host bus adapter to a Fibre Channel storage array that is
used to provision two LUNs as required for the deployment. The first LUN is a 10-GB LUN for the Quorum / Witness
resource; the second is a 2-terabyte LUN to support a highly available file server called “File-Server-1,” which is
used to maintain all user folder redirected content and a series of scripts required for the deployment.
The single host bus adapter connection could be seen as a possible single point of failure and ideally should be
eliminated by adding a second host bus adapter to Node 1 and Node 2. This would require a second fibre switch
and the installation of Microsoft Multipath I/O (MPIO) or an appropriate third-party device-specific module. The

44
team did not have access to a second switch at the time of deployment and moved forward understanding that the
single host bus adapter was not a best practice configuration.

No other modifications were made to the cluster or default parameters for resource restart. Failover and failback
policies were maintained.

File-Server-1 (Folder Redirection and Script Content – Head Office)

The highly available file server supporting “File-Server-1 ” maintains a number of resource types that include a
network name with corresponding IP addresses (both IPv4 and IPv6), file server, disk drive, and eight shares.

Figure 9 shows the Failover Cluster Manager snap-in layout for reference with the appropriate resources.

Figure 9 - Failover Cluster Manager MMC representation

The Logon scripts$ share is used to support a number of scripts required for the deployment with the Data$ share
used as a location to store information collected by the scripts. The scripts will be covered in more detail in the
following Group Policy Object (GPO) section.

The team chose to use six folders for redirection shares to provide granular access to users from the various
resource domains where their accounts are maintained. This allowed the team to view the data structure, assign
file screening and quota settings, while also achieving a granular Storage Report view within File Server Resource
Manager on a per domain basis.

45
Figure 10 highlights a Windows Explorer view of the share and directory structure for reference for File-Server-1.

Figure 10 - Windows Explorer share representation

File-Server-2 (Folder Redirection and Script Content – Far Branch Office)

File-Server-2 leverages the same directory structure to support the far branch office server. This is a stand-alone
non cluster configuration, but the same principles apply with regard to directory structures, etc.

File Server Resource Manager

File Server Resource Manager is implemented to enable Quota and File Screening. During the initial stage of
deployment, the team used Soft Quota and Passive File Screening to prevent users from being impacted during
initial deployment due to capacity or unsupported file types preventing folder redirection.

Implementing Quota
The team created a Quota template and set it to auto apply to each of the six folders corresponding to the shares
created on the file servers. The template initially enables a soft quota that generates an event log entry and an e-
mail notification to the administrator and user for users that breach 90% of their 10-GB quota followed by another
series of notifications if they breach 100% of their quota.

Users are not impacted if they exceed quota during enrollment, but are advised to clear up unneeded content or
request an increase in the 10-GB quota allocation with appropriate justification.

Below are sample representative figures of the Quota template and File Server Resource Manager MMC that show
a custom template setting for a 10-GB threshold with a Soft quota and appropriate threshold warnings using e-mail
and Event Log for reference.

46
 Figure 11 - File Server Resource Manager Quota template properties

Figure 12 - File Server Resource Manager MMC – Custom Quota template (Redirection)

Figure 13 - File Server Resource Manager MMC – Quotas

After the users are enrolled and running within the deployment for a period of time, the team changes the
individual quotas to enforce a hard quota threshold preventing users from exceeding their allocated limits. The
process for enrolling users will be covered in the Operational Procedures section of this white paper.

Implementing file screens

The team created a file screening template and applied it to each of the six folders corresponding to the shares
created on the file servers. The template enables a passive screen initially that generates an event log entry and an

47
e-mail notification to the administrator and user that attempts to save files with a screened extension. The team
chose to screen PST file types.

PST files are used by the Microsoft Outlook e-mail client to store content outside of the online mailbox. The
deployment team did not want to maintain PST files on the file servers to ensure that the users e-mail lifecycle is
managed within their online mail store.

During enrollment users are notified that they are not allowed to store PST files on the file servers. The users will
be warned that these files will not be backed up as part of our data protection model and that an active screen will
be applied to prevent PST files being stored on the server within a period of time. If the user has a PST file stored
on the server, they will be advised to move the file to an alternate storage location.

After an active screen is enforced, the user will be prevented from storing PST files in the future.

Below are sample representations of the File Server Resource Manager MMC showing File Group Properties, File
Screen Template Properties, File Screens, and File Screen Properties (passive screening).

Figure 14 - File Server Resource Manager MMC – Custom File Group Properties for *.pst files

Figure 15 - File Server Resource Manager MMC – File Screen Template Properties

48
 Figure 16 - File Server Resource Manager MMC – File Screens

Figure 17 - File Server Resource Manager MMC – File Screen Properties (Passive screening)

49
Shadow Copy for Shared Folders
Shadow Copy for Shared Folders is enabled on the volume supporting Folder Redirection content. The default
schedule settings are maintained with two snapshots per day, although the team extended the snapshots to run
on Saturday and Sunday to cater for possible changes that occur over the weekend. As per the Planning section of
this white paper, the team expected a relatively light I/O load and did not allocate dedicated storage for shadow
copies.

Figure 18 - Shadow Copy for Shared Folders and schedule

Group Policy settings

The deployment team implemented a number of Group Policy objects (GPOs) linked to the root of each domain to
enable folder redirection and to enhance the user experience based on location and client type. The GPOs are
scoped to the users and computers via global security group membership with further scoping by using WMI filters
to evaluate queries that detect operating system versions and classes of computers to include desktops or laptops
where appropriate.

50
The following tables (Table 13 and 14) provide the description of the GPOs and how they are scoped to security
groups.

Policy Name Description

Policy0 Computer Specific Enablement

Policy1 Computer Specific Folder Redirection for Head and Near Branch Offices

Policy2 Computer Specific Folder Redirection – Far Branch Offices

Policy3 Slow Link and Background Synchronization for Near Branch Office
Desktops

Policy4 Slow Link and Background Synchronization for Windows Vista Laptops

Policy5 Background Synchronization for Windows 7 Laptops

Policy6 Exclusion List

Policy7 Offline Directory Rename Delete – Windows Vista

Table 13 - Policy setting definitions

User Location and Security Groups and Object

Headquarters Far branch Near branch Object added

Domain2 Domain5 Domain7 Domain9 Domain3 Domain4

Policy0_SG Policy0_SG Policy0_SG Policy0_SG Policy0_SG Policy0_SG User & Computer

Policy1_SG Policy1_SG Policy1_SG Policy1_SG Policy1_SG Policy1_SG User

n/a n/a n/a n/a n/a Policy2_SG User

n/a n/a n/a n/a Policy3_SG n/a User & Computer

Policy4_SG Policy4_SG Policy4_SG Policy4_SG Policy4_SG Policy4_SG User & Computer

Policy5_SG Policy5_SG Policy5_SG Policy5_SG Policy5_SG Policy5_SG Computer

Policy6_SG Policy6_SG Policy6_SG Policy6_SG Policy6_SG Policy6_SG Computer

Policy7_SG Policy7_SG Policy7_SG Policy7_SG Policy7_SG Policy7_SG Computer

Table 14 - User location and security groups and object

51
The GPO identified as Policy1, for example, enables Computer Specific Folder Redirection for head offices and near
branch offices for users that are made members of a global security group called Policy1_SG within Domain2. The
same GPO ,which is duplicated across the other domains, is applied to users that are made members of the
corresponding global security group called Policy1_SG in Domain5, Domain7, Domain9, Domain3, and Domain4.

The GPO identified as Policy6, as another example, enables an Exclusion List against all computers that are made
members of a global security group called Policy7_SG within Domain2. The same GPO, which is duplicated across
the other domains, is applied to computers that are made members of the corresponding global security group
called Policy7_SG in Domain5, Domain7, Domain9, Domain3, and Domain4.

Further scoping is achieved with the use of WMI filters that are discussed within the following GPOs.

Computer-specific Folder Redirection GPOs

The team implemented a custom solution requiring two GPOs to enable computer-specific folder redirection for all
users enrolled in the service. For the purpose of documentation we will refer to the GPOs as “Computer-Specific
Enablement” and “Computer-Specific Folder Redirection.”

Computer-specific enablement GPO

The first GPO, “Computer-Specific Enablement,” defined in the table below, invokes both user configuration and
computer configuration parameters to call logon and startup scripts. This GPO prepares the client computer for
Folder Redirection by creating a custom WMI namespace, creating a registry key, and querying a database table to
determine if a user has Folder Redirection enabled on a specific client computer. This GPO does not perform Folder
Redirection, but establishes a series of prerequisites.

Computer-Specific Enablement

General policy settings

Links Applied to: See the “User Location and Security Groups and Object” table
Security filtering Applied to: Policy0_SG
Delegation Deployment team delegated Edit settings permission
User Configuration
Policies\Windows Settings\Scripts\Logon See Appendix A (Computer Specific Folder Redirection Logon
Script)
Computer Configuration
Policies\Windows Settings\Scripts\Startup See Appendix A (Computer Specific WMI Namespace Installation)
Table 15 - Computer specific enablement

The Startup Script which we identify as the “Computer-Specific WMI Namespace Installation” (outlined in
Appendix A) is used to create a WMI namespace called “MachineBasedFR” on all client computers enrolled in the
service. The namespace is created by using the “Computer Specific MOF” also outlined in Appendix A. The policy is
applied at startup, so the client computer will need to be restarted to create the WMI namespace.

The Logon Script which we identify as the “Computer-Specific Folder Redirection Logon Script” (outlined in
Appendix A) is run during user logon and determines if Folder Redirection has been enabled for the specific user on
the client computer. The Logon Script verifies that the client operating system is Windows Vista or above, creates
a temporary working location on the client computer, copies two custom files (MachineBasedFR.exe and
MachineBasedFR.config), and executes MachineBasedFR.exe.

52
The executable performs two tasks.

1. The first task uses the MachineBasedFR.config file (a standard .NET application configuration file) to query
a database table and determine if the user has the client computer enabled for redirection.
2. The second creates a registry key called MachineSpecificFR within the HKEY_CURRENT_USER hive,
containing a REG_DWORD named ApplyFR.

The sample table below maps the users to specific client computers on which redirection should be enabled:

<User1>:<Machine1>,<Machine2>,<Machine3>
<User2>:<Machine2>
<User3>:<Machine4>,<Machine5>

If Folder Redirection is enabled for the client computer based on the table query, the MachineBasedFR.exe will set
the ApplyFR registry value to 1. If it is not, the default value of 0 is maintained.

Computer Specific Folder Redirection GPO

The second GPO called “Computer-Specific Folder Redirection” defined in the table below specifies User
Configuration parameters and is scoped to users via a WMI filter that evaluates a WMI query to be true where:
“SELECT ApplyFR FROM MachineBasedFR where ApplyFR = 1”.

The Folder Redirection setting defines a path “\\File-Server -1\UserData_Domain(“X”)\%username%\documents\”

which represents the path to the users “My Documents” folder. Other folders redirected within the policy setting
not listed in the table are Contacts, Desktop, Downloads, Favorites, Links, My Music, My Pictures, My Videos,
Saved Games, and Searches.

The default settings are maintained to grant user’s exclusive rights to their redirected content and move the
contents of Documents to the new location. The team chose to enable a non-default parameter to redirect content
back to the local user profile location if a user is removed from the deployment.

Computer-Specific Folder Redirection – Head and Near Branch Offices

General policy settings

Links Applied to: See the “User Location and Security Groups and Object” table
Security filtering Applied to: Policy1_SG
WMI filtering WMI filter to identify:
SELECT ApplyFR FROM MachineBasedFR where ApplyFR = 1

Note: MachineBasedFR refers to a custom WMI namespace

Delegation Deployment team delegated Edit settings permission
User Configuration
Windows settings
Folder Redirection Documents folder used for reference in this policy setting example

Target Tab
Setting: Advanced-Specify location for various user groups

Security Group Membership

Group: Domain X Advanced Folder Redirection Global Security Group
Path: \\File-Server-1\UserData_domain(“X”)\%username%\documents\

53
 Note: “X” represents the user’s domain name for redirecting content to the
appropriate directory/folder on the file server

Settings Tab
Enabled – Grant user exclusive rights to Documents
Enabled – Move the contents of Documents to the new location
Enabled – Redirect the folder back to the local user profile location when
policy setting is removed
Table 16 – Computer-specific folder redirection – head and near branch offices

The “Computer-Specific Enablement” and “Computer-Specific Folder Redirection” GPOs are duplicated for users in
the far branch office to support redirection of their folders with a different path and an alternate script location.

Background Sync and Slow Link GPO Definition

The following table provides an overview of the various policy settings used to enable Slow Link and Background
Synchronization for different categories of users (local, near branch office, far branch office, and mobile) and client
type (Windows Vista and Windows 7). There are three applicable GPOs that are detailed below: (Policy 3), (Policy
4), and (Policy 5).

Slow Link and Background Synchronization Group Policy Assignments

User type Applied to Slow Link Background Synchronization

Laptop Desktop Windows Windows 7 Windows Vista Window 7

Vista

Local X Default Default N/A Default

Near branch X 1 ms 1 ms Custom Script 48 hours
(Policy 3) (Policy 3) (Policy 3) (Policy 3)
Far branch X Default Default N/A Default
Mobile X 35 ms Default Custom Script 48 hours
(Policy 4) (Policy 4) (Policy 5)
Table 17 - Slow Link and Background Synchronization Group Policy assignments

Policy 3 GPO is targeted for users located in near branch offices; these are locations that are connected via a WAN
link within the same geographical location as the head office. Round Trip time (RTT) during typical daily usage is in
a range between 80 and 120 ms.

The GPO has two elements that impact both Windows Vista and Windows 7 clients. The first element is to
configure Slow Link mode with a latency value of 1 ms (0 ms is not a supported value). This forces clients to work in
an offline mode so that all read and write activity in satisfied from the Offline Files cache on their local computer.
This provides the clients a better experience than having them access their file content located on the head office
file server over a WAN link.

The second element sets Background Synchronization for both Windows Vista and Windows 7 clients. The
synchronization interval for Windows Vista (via a custom executable calling Offline Files APIs) and Windows 7 is set
to six hours. Windows 7 clients that have not achieved synchronization within the default period will be forcibly
synchronized after 48 hours. The forced synchronization is not available for Windows Vista clients.

54
Policy 4 GPO is specific to Windows Vista-based mobile users and has two elements. The first element sets the
Slow Link mode with a latency value of 35 ms. This enables mobile users to work in an offline mode when
connected to the corporate network via RAS or alternate locations that offer high latency network access to their
file server. When that user reconnects via a LAN link with limited to no latency, they can revert to working in an
online mode.

Note: Windows Vista will not revert to an online mode from an offline slow connection state unless the user
selects the “Work Online” button in Windows Explorer. This behavior has changed in Windows 7 in that the client
will automatically switch between online and offline mode based on network latency detection without user
interaction.

The second element of the GPO enables synchronization every six hours if the Windows Vista client is maintained
in an offline state. This again is achieved via custom script and executable.

Policy 5 GPO sets Background Synchronization for Windows 7 mobile users. If the client has not synchronized
within the default interval of six hours, it will be forcibly synchronized after 48 hours.

Slow Link and Background Synchronization for Near Branch Office Desktops
This GPO is applied to all desktop users in the near branch office location.

Scoping is enabled via a WMI filter that evaluates a WMI query to be true: “Win32_ComputerSystem WHERE
PCSystemType <>2”, which defines a laptop class computer.

The GPO sets the Slow Link latency to 1 ms to ensure that users are maintained in offline mode, and sets the
Background Sync to 48 hours to force synchronization if the client has not successfully synchronized by using
Computer Configuration and User Configuration settings.

Slow Link and Background Synchronization for Near Branch Office Desktops

General GPO settings

Links Applied to: See the “User Location and Security Groups and Object” table
Security filtering Applied to: Policy3_SG
WMI filtering WMI filter to identify:
Win32_ComputerSystem WHERE PCSystemType <>2
Delegation Deployment team delegated Edit settings permission
Computer Configuration
Policies\Administrative Templates\Network\Offline Enabled
Files\ Options: UNC Paths:
Setting - Configure Slow Link mode Value name
\\FileServer\Share_UserData_Domain1\*
Value
Latency = 1
Policies\Administrative Templates\Network\Offline Enabled
Files\ Maximum Allowed Time Without A Sync (minutes)
Setting - Configure Background Sync 2880
User Configuration
Policies\Windows Settings\Scripts (Logon/Logoff) See Appendix A (Windows Vista Background Sync
logon script and associated files)
Table 18 - Slow Link and Background Synchronization for near branch office desktops

55
Slow Link and Background Synchronization for Windows Vista Laptops
This GPO is applied to all laptops running Windows Vista.

Scoping is enabled via a WMI filter that evaluates two WMI queries to be true: Win32_ComputerSystem WHERE
PCSystemType = 2, which defines a laptop class computer, and Win32_OperatingSystem WHERE (BuildNumber >=
6001) or (BuildNumber < 7000), which includes all Windows Vista clients with service packs, and excludes Windows
Vista RTM and any Windows 7 client build.

The GPO sets the Slow Link latency to 35 ms to ensure that Windows Vista mobile users are maintained in offline
mode by using Computer Configuration and User Configuration settings.

Slow Link and Background Synchronization for Windows Vista Laptops

General GPO settings

Links Applies to: See the “User Location and Security Groups and Object” table
Security filtering Applies to: Policy4_SG
WMI filtering WMI filter to identify:
Win32_ComputerSystem WHERE PCSystemType = 2
Win32_OperatingSystem WHERE (BuildNumber >= 6001) or (BuildNumber < 7000)
Delegation Deployment team delegated Edit settings permission
Computer Configuration
Policies\Administrative Templates\Network\Offline Enabled
Files\ Options: UNC Paths:
Setting - Configure Slow Link mode Value name
\\FileServer\UserData _Domain(“X”)\*
Value
Latency = 80
User Configuration
Policies\Windows Settings\Scripts (Logon/Logoff) See Appendix A (Windows Vista Background Sync logon
script and associated files)
Table 19 - Slow Link and Background Synchronization for Windows Vista laptops

Background Synchronization for Windows 7 Laptops

This GPO is applied to all laptops running Window 7.

Scoping is enabled via a WMI filter that evaluates two WMI queries to be true: Win32_ComputerSystem WHERE
PCSystemType = 2, which defines a laptop class computer, and Win32_OperatingSystem WHERE (BuildNumber >=
7000), which includes any Windows 7 build and above.

56
The GPO sets the Background Sync to force clients to synchronize content from their offline cache every 48 hours
by using Computer Configuration settings.

Background Synchronization for Windows 7 Laptops

General GPO settings

Links Applies to: See the “User Location and Security Groups and Object” table
Security filtering Applies to: Policy5_SG
WMI filtering WMI filter to identify:
Win32_ComputerSystem WHERE PCSystemType = 2
Win32_OperatingSystem WHERE (BuildNumber >= 7000)
Delegation Deployment team delegated Edit settings permission
Computer Configuration
Policies\Administrative Templates\Network\Offline Enabled
Files\ Maximum Allowed Time Without A Sync (minutes)
Setting - Configure Background Sync 2880
Table 20 - Background Synchronization for Windows 7 laptops

Exclusion List
This GPO is applied to all Windows 7 clients.

Scoping is enabled via a WMI filter that evaluates a WMI query to be true: Win32_OperatingSystem WHERE
BuildNumber >= 7000, which includes any Windows 7 build and above.

The Exclusion List GPO prevents Windows 7 clients from creating unsupported file types whether in online or
offline mode by using Computer Configuration settings.

Exclusion List

General GPO settings

Links Applies to: See the “User Location and Security Groups and Object” table
Security filtering Applies to: Policy6_SG
WMI filtering WMI filter to identify:
Win32_OperatingSystem WHERE BuildNumber >= 7000
Delegation Deployment team delegated Edit settings permission
Computer Configuration
Policies\Administrative Templates\Network\Offline Files Enabled
Setting - Exclude files from being cached Options: Extensions: *.PST
Table 21 - Exclusion List

Offline Directory Delete Rename - Windows Vista

This GPO is applied to all Windows Vista users.

Scoping is enabled via a WMI filter that evaluates a WMI query to be true: Win32_OperatingSystem WHERE
(BuildNumber >= 6001) or (BuildNumber < 7000), which includes all Windows Vista clients with service packs, and
excludes Windows Vista RTM and any Windows 7 client build.

57
The GPO enables Windows Vista users post SP1 to delete or rename folders that were cached by Offline Folders
when working in offline mode. The GPO creates a registry key and sets two DWORDs within the
HKEY_LOCAL_MACHINE registry hive by using a script invoked via the Computer Configuration settings.

Note: The registry key is read when the Offline Files service starts. Computer startup scripts are run after services
such as Offline Files are started. Therefore, the client computer must be restarted after the registry key is set to
enforce the change.

Offline Directory Rename Delete – Windows Vista

General GPO settings
Links Applies to: See the “User Location and Security Groups and Object” table
Security filtering Applies to: Policy7_SG
WMI filtering WMI filter to identify:
Win32_OperatingSystem WHERE (BuildNumber >= 6001) or (BuildNumber < 7000)
Delegation Deployment team delegated Edit settings permission
Computer Configuration
Policies\Windows Settings\Scripts See Appendix A (Windows Vista offline rename delete
(Startup/Shutdown) script)
Table 22 - Offline Directory Rename Delete script – Windows Vista

Data Protection Manager 2007 Configuration

The team leveraged an existing Data Protection Manager (DPM) 2007 SP1 deployment to enable backup for the
failover cluster and stand-alone file servers. The DPM infrastructure is physically located within the same campus
as the failover cluster file server enabling LAN based connectivity, whereas the stand-alone file server is located
over a WAN link that typically has an RTT (Round Trip Time) of approximately 250 ms.

The server is a stand-alone configuration as per specification below. The DPM server uses iSCSI Storage with eleven
1-terabyte SATA drives in a RAID 6 configuration. The storage is configured as four 2-terabyte LUNs to support
backup content for the folder redirection deployment and other infrastructure managed by the deployment team.

Data Protection Manager Server Specifications

Processor 2 x Quad-Core Processors (2.33 GHz)
Memory 8 GB
Network adapter 2 x 1 GB (1 for Corp Network, 1 for iSCSI Storage Connectivity)
Internal controller Embedded RAID Controller (read cache only)
Internal drives 2 x 146-GB SAS drives
OS LUN / volume 146-GB Mirror for C: Drive (Operating System)
External controller 1-GB network adapter to external iSCSI storage array
External drives 11 x 1-terabyte SATA drives
9Data+2Parity (RAID6)
Data LUN / volume 4 x 2-terabyte (DPM backup)
Table 23 - Data Protection Manager server specifications

The team has configured two separate DPM protection groups, one for each file server. This allows for selective
optimizations as required to cater for LAN- and WAN-based backup methods.

The protection group details for the failover cluster file server (File-Server-1) and for the stand-alone file server
(File-Server-2) are highlighted in the following table. The team maintained many of the default settings, but did

58
modify settings to exclude protection for PST files and adjust synchronization frequency to every two hours for
File-Server-2 located in the far branch office.

Protection Group Details

Failover cluster Stand-alone

Group members
Available members
Selected members
Excluded folders
Excluded file types
Data protection method
Short term protection
Short-term-goals
Retention range
Synchronization frequency
Recovery points to file
Optimize performance
Network
Consistency check
File-Server-1 (agents deployed to File-Server-2
Node1 and Node2)
J:\FRCSC Deployment\ E:\FSCSC Deployment\
J:\Logon_Scripts E:\Logon_Scripts
0 0
1 (.pst) 1 (.pst)
Disk Disk
14 days 14 days
Every 15 minutes Every 2 hours
8:00 A.M., 12:00 P.M., and 9:00 P.M. 8:00 A.M., 12:00 P.M., and 9:00 P.M.
Everyday Everyday
N/A Enable on-the-wire-compression
Schedule daily consistency check Schedule daily consistency check
11:00 P.M. 1:00 A.M.
Maximum duration (hours): 8 Maximum duration (hours): 8
Table 24 - Protection group details

Another area of interest is a requirement to enable over-the-wire compression, throttling, and consistency checks
to address different optimization requirements based on the protected servers’ geographical location.

Network throttling
The team chose to minimize the impact that data protection replication has on the network by enabling DPM’s
network throttling capability.

Given the capabilities on the Microsoft WAN link between the head office and the far branch office and its
utilization, the team chose the following settings as in the Throttle Properties dialog box:

59
 Figure 19 - Far branch office throttle settings

On-the-wire compression
This setting allows more data throughput without negatively affecting network performance. However, this option
does add to the CPU load on both the DPM server and the protected file servers. Compression decreases the size
of data being transferred during replica creation and synchronization.

The team enabled on-the-wire compression for the server located in the far branch office but maintained the
default for the server located in the head office.

Far Branch Office Compression Settings Head Office Compression Settings

Figure 20 - DPM compression settings

Consistency checks
The team schedules a daily consistency check during off-peak hours to ensure that the replica is consistent with
the protected data. A scheduled consistency check will only run if inconsistencies are detected during
synchronization. Keep in mind that the performance of the file server will be affected while the consistency check
is running.

60
Far Branch Office Consistency Settings Head Office Consistency Settings

Figure 21 - DPM optimization performance

61
Operational Procedures
Adding Users to the Service
The process of adding users to the service is done in two stages. As part of the first stage, all Group Policy settings
are applied with the exception of the Offline Files Exclusion List policy. During the second stage, directory quotas
are changed from soft to hard quotas, file screens are changed from passive to active, and the Offline Files
Exclusion List policy setting is deployed.

Figure 22 defines a flow chart explaining the user enrollment procedure:

Notification of new
user and allocated
machine names

Initial enrollment steps:

User contacted to resolve any quota
and/or excluded files issues (6)
 User and computer objects added to appropriate
security groups (1)
 List of machines specified for folder redirection
inserted into the database (2)
 User is sent instructions and information about the
settings (3)

No

Is quota below
threshold and are Are folders redirected? User contacted to
Yes No
Issues resolved

excluded files (4) resolve any issue

removed? (5)

Folders are redirected

Yes Final enrollment steps:

 Directory quota changed from soft to hard quota (7)
 File screen changed from passive to active file screen (8)
 Computer objects added to Offline Files exclusion list
security group and user notified to reboot machine (9)

Figure 22 - Overview of adding users to the deployment

Stage one
The administrator adds user and computer objects to the appropriate security groups listed in Table 14 (1) which
causes all Group Policy settings to be applied with the exception of the Offline Files Exclusion List policy setting.
Then, the names of the computers specified for folder redirection for given users are added into the appropriate
database (2). Following this step, users are notified about their enrollment and instructed to restart their
computers and log on (3). After the initial user logon, the user profile folders’ content is moved to the centralized
file server location, and soft directory quotas and passive file screens are automatically applied.

62
Stage two
After successful folder redirection, File Server Resource Manager storage reporting is used to check the status of
the soft directory quotas and passive file screens (5). Users above the quota threshold are instructed to remove
content and comply with their allocated storage space limit or to provide justification for an exception allowing
them to store more data on the server. Similarly, users with excluded file types on the server are instructed to
remove the files (6). After the quota and excluded file requirements are met by the user, directory quotas are
changed from soft to hard (7), file screens are changed from passive to active (8), computer objects are added to
the appropriate security group for the Offline Files Exclusion List policy setting, and the user is notified to restart
the computer (9).

Removing Users from the Service

Removing users from the service is accomplished by removing user and computer objects from the appropriate
security groups. Just as adding the objects caused the Group Policy settings to be applied, the removal from the
security group membership causes the Group Policy settings to be reverted back to the default settings.

After the user and computer objects are removed from the security groups, users are instructed to restart their
computers and log on. While logging on to computers previously specified for folder redirection, the data from the
centralized file server is copied back to the local hard drive. In addition, the user profile folders are reverted to
their default locations. Because Folder Redirection is removed during the logon process, the user logon will take
longer if there is a large amount of redirected content.

63
Conclusion
In this document, we explained how to successfully put in place an end-user data centralization and backup
solution by using Microsoft technologies. We delved into the key planning considerations critical to a successful
deployment and detailed how the solution was implemented within Microsoft.

Besides providing guidance to help customers replicate such a solution, the primary objective of this effort was for
the Microsoft File Server Quality Assurance group to validate technologies under development within a
production environment. This ensured that the solution being shipped to our customers was proven to be capable
of fulfilling the business needs established in this document.

While, through this deployment, we presented a cohesive solution responding to typical end user data
centralization and backup needs, some organizations may have additional requirements going beyond the scope of
what has been discussed in this white paper. Additional requirements that were considered during the initial
phases of the project included:

• User documents classification

Ability to classify documents and perform automatic tasks based on the document class. For example,
this can be useful to manage data of people who left the deployment by automatically moving their
files from the file servers to an alternate location. You can use Windows Server 2008 R2 File
Classification Infrastructure (http://go.microsoft.com/fwlink/?LinkId=166667) for that purpose.
• Disaster recovery with continuous availability
Ability to continuously maintain service availability (including adding or removing users) in case of a
disaster at the site where the file servers are located. You can use the Distributed File System
Replication (DFSR) and Distributed File System Namespace (DFSN) features in Windows Server 2008
R2 to achieve this result.
• Further service health monitoring
Ability to closely monitor the health of the system from the server infrastructure to the client
computers. You can use Microsoft System Center Operations Manager 2007
(http://go.microsoft.com/fwlink/?LinkId=166668) for that purpose.
• Virtualization
Reduction of hardware and management costs through virtualization and consolidation of the servers
composing the solution by using the Hyper-V feature
(http://go.microsoft.com/fwlink/?LinkId=166669), which is shipped as part of Windows Server
2008 R2.

These requirements will be investigated to enhance the existing solution with a plan to implement the Microsoft
technologies mentioned above.

64
Index of Tables
Table 1 - SMB version negotiation ...............................................................................................................................11

Table 2 - Facility classification .....................................................................................................................................15

Table 3 - Head office server capacity sizing .................................................................................................................18

Table 4 - Far branch server capacity sizing ..................................................................................................................18

Table 5 - Network characteristics impact ....................................................................................................................23

Table 6 - Working states ..............................................................................................................................................26

Table 7 - Optimizing folder states based on users’ categories ....................................................................................28

Table 8 - Time to complete initial full replica with DPM .............................................................................................32

Table 9 - Time to complete scheduled synchronizations with DPM ............................................................................33

Table 10 - Clustered server specifications ...................................................................................................................42

Table 11 - Stand-alone server specifications ...............................................................................................................43

Table 12 - Operating system configuration .................................................................................................................43

Table 13 - Policy setting definitions .............................................................................................................................51

Table 14 - User location and security groups and object ............................................................................................51

Table 15 - Computer specific enablement ...................................................................................................................52

Table 16 – Computer-specific folder redirection – head and near branch offices ......................................................54

Table 17 - Slow Link and Background Synchronization Group Policy assignments .....................................................54

Table 18 - Slow Link and Background Synchronization for near branch office desktops ............................................55

Table 19 - Slow Link and Background Synchronization for Windows Vista laptops ....................................................56

Table 20 - Background Synchronization for Windows 7 laptops .................................................................................57

Table 21 - Exclusion List ...............................................................................................................................................57

Table 22 - Offline Directory Rename Delete script – Windows Vista ..........................................................................58

Table 23 - Data Protection Manager server specifications ..........................................................................................58

Table 24 - Protection group details .............................................................................................................................59

65
Index of Figures
Figure 1 - Geographic distribution .................................................................................................................................7

Figure 2 - Network infrastructure and server locations ..............................................................................................16

Figure 3 - FSCT report output ......................................................................................................................................19

Figure 4 – FSCT server scenarios throughput ..............................................................................................................20

Figure 5 – Offline Files state transition ........................................................................................................................27

Figure 6 - Solution architecture ...................................................................................................................................35

Figure 7 - Domain representation ...............................................................................................................................41

Figure 8 - Failover cluster representation ...................................................................................................................44

Figure 9 - Failover Cluster Manager MMC representation ..........................................................................................45

Figure 10 - Windows Explorer share representation ...................................................................................................46

Figure 11 - File Server Resource Manager Quota template properties .......................................................................47

Figure 12 - File Server Resource Manager MMC – Custom Quota template (Redirection) .........................................47

Figure 13 - File Server Resource Manager MMC – Quotas ..........................................................................................47

Figure 14 - File Server Resource Manager MMC – Custom File Group Properties for *.pst files ................................48

Figure 15 - File Server Resource Manager MMC – File Screen Template Properties ..................................................48

Figure 16 - File Server Resource Manager MMC – File Screens ..................................................................................49

Figure 17 - File Server Resource Manager MMC – File Screen Properties (Passive screening) ...................................49

Figure 18 - Shadow Copy for Shared Folders and schedule ........................................................................................50

Figure 19 - Far branch office throttle settings .............................................................................................................60

Figure 20 - DPM compression settings ........................................................................................................................60

Figure 21 - DPM optimization performance ................................................................................................................61

Figure 22 - Overview of adding users to the deployment ...........................................................................................62

66
Appendix A – Scripts
Computer Specific Folder Redirection

Computer Specific Folder Redirection logon script

The script runs at logon and determines if Folder Redirection should apply for the specified user on the specified
computer. The script calls an executable named “MachineBasedFR.exe” which retrieves the name of the logged on
user and the name of the computer. It then queries a database to determine if the user needs to have Folder
Redirection enabled for the specific computer. The executable creates the following registry entry:
HKCU\MachineSpecificFR\ApplyFR and initializes it with 1 if Folder Redirection needs to be applied to the specific
computer for the user or to 0 otherwise.

Computer Specific Folder Redirection

:: // Description:
:: // The script runs at logon & determines if Folder Redirection
:: // should apply for the specified user on the specified computer.
:: // It creates a following registry entry: HKCU\MachineSpecificFR\ApplyFR

@echo off

:: //
:: // SET GLOBAL VARIABLES
:: //

SET LOCAL_PATH=%TEMP%
SET LOCAL_LOG_FILE=%USERNAME%_%COMPUTERNAME%.log
SET OUTPUT_PATH=\\File-Server-1\data$\Machine_Specifc_FR\DomainX
SET COMMAND_PATH=\\File-Server-1\Logon_scripts$\Machine_Specifc_FR\DomainX

:: //
:: // Get the OS VERSION
:: //

VER > %TEMP%\Machinespecificfolderredirection.OSVersion.txt

FINDSTR /I /C:"Version 5." %TEMP%\Machinespecificfolderredirection.OSVersion.txt
IF %ERRORLEVEL% EQU 0 (
echo This Machine is running pre-vista, Exiting ... >> %LOCAL_LOG_FILE%
goto :eof
)

:: //
:: // Create a temp directory & copy the user logon script
:: //

md %LOCAL_PATH%\Machinespecificfolderredirection.UserLogon
xcopy /y %COMMAND_PATH%\MachineBasedFR*
%LOCAL_PATH%\Machinespecificfolderredirection.UserLogon

:: //
:: // Execute the script
:: //

Pushd %TEMP%\Machinespecificfolderredirection.UserLogon
MachineBasedFR.exe >> %LOCAL_LOG_FILE%

:: //
:: // Copy Local Log File to Server
:: //

COPY /Y %LOCAL_LOG_FILE% %OUTPUT_PATH%

goto :eof

67
Computer Specific WMI Namespace Installation startup script
This startup script creates a custom WMI namespace on the client. The custom WMI namespace properties are
defined in the MachineBasedFR.mof support file.

Computer-Specific WMI Namespace Installation

:: // Description:
:: // This is the machine startup script for the Computer Specific Folder Redirection
:: // Deployment. This script installs a custom WMI Namespace on the computer.

@echo off

:: //
:: // SET GLOBAL VARIABLES
:: //

SET LOG_FILE=\\File-Server-1\data$\Computer_Specific_FR\DomainX\%COMPUTERNAME%.log
SET MOF_SOURCE=\\File-Server-1\logon_scripts$\Computer_Specific_FR\DomainX\MachineBasedFR.mof

:: Install the MOF

mofcomp -class:forceupdate %MOF_SOURCE%

:: Update the log file

echo %DATE% %TIME% : Computer Startup Executed >> %LOG_FILE%

goto :eof

Computer Specific (MOF) support file

This is a support file used in the Computer Specific Folder Redirection startup script. The name of the support file
is MachineBasedFR.mof and defines the properties of a custom WMI namespace.

MachineBasedFR.mof
#pragma namespace ("\\\\.\\Root\\cimv2")

[DYNPROPS]
class MachineBasedFR
{
[key]string Keyname="";
uint32 ApplyFR;
};

[DYNPROPS]
instance of MachineBasedFR
{
KeyName="MachineBasedFR";
[PropertyContext("local|HKEY_CURRENT_USER\\MachineBasedFR|ApplyFR"), Dynamic,
Provider("RegPropProv")] ApplyFR;
};

Windows Vista Background Synchronization

The Windows Vista Background Sync logon script creates a scheduled task to periodically synchronize offline
content on Windows Vista clients. Clients in Offline (Slow Connection) and Offline (Working Offline) modes will get
the benefit of keeping their files up to date by using this task. This script uses Scheduler Task to create a
Background Sync task named "BackgroundSync Task For User %USERNAME%" on the client. This task can be
viewed from the Task Scheduler. The logon script uses an XML file that provides information such as user name
and how often the task should run to create the scheduled task. Here, the timer is set to sync every 6 hours. In

68
addition, the script checks for updates to fullsync.exe and provides the option to delete the task from the user’s
computer.

Required support files:

Support file Description Location

Tool to determine version of Download from
Filever.exe FullSync.exe http://go.microsoft.com/fwlink/?LinkId=166670
Binary executed by scheduled
FullSync.exe task See below
Settings used to create
FullSync.xml scheduled task See below

Vista Background Sync

:: // Description:
:: // This script copies the tools necessary for Background Sync from a remote
:: // location to a local directory. It then creates a scheduler task to Sync
:: // the offline files at predetermined time intervals.

@echo off

setlocal ENABLEDELAYEDEXPANSION
:: //
:: // Initialize Global Variables
:: //

SET COMMAND_PATH=\\File_Server-1\Logon_Scripts$\Vista_Background_Sync_Task\DomainX
SET OUTPUT_PATH="\\File_Server-1\data$\Vista_Background_Sync_Task\DomainX\"
SET VISTA_BG_SYNC_TASK_TEMP_FILE=%TEMP%\VISTA_BG_SYNC_TASK_%USERNAME%_%COMPUTERNAME%.TXT
SET VER_COMMAND_BIN=%SANDBOX_DIR%\FILEVER.EXE
SET CurrentDir=%TEMP%
SET SANDBOX_DIR=%TEMP%\FS_SANDBOX
SET OPTION=%1

:: //
:: // Validate Parameters
:: //

IF /I {"%OPTION%"} == {"/?"} goto :USAGE

:: //
:: // COLLECT BUILD INFORMATION.
:: //

call :ECHOANDLOG Checking Version of OS ...

ECHO VERSION_INFORMATION: > %VISTA_BG_SYNC_TASK_TEMP_FILE%
VER >> %VISTA_BG_SYNC_TASK_TEMP_FILE%

:: //
:: // Check Build Version is not Win7 or higher
:: //

FINDSTR /I /C:"Version 6.1" %VISTA_BG_SYNC_TASK_TEMP_FILE%

IF %ERRORLEVEL% EQU 0 (
call :ECHOANDLOG This Machine is running Win7 or higher, Exiting ...
goto :COPYLOGS
)

:: //
:: // Force delete the existing task and create a new one
:: //

69
IF /I {"%OPTION%"} == {"/D"} goto :DELETE

:: //
:: // Validate the presence of FULLSYNC tool on the Network Location
:: //

md %SANDBOX_DIR%

:: //
:: // Copy the binaries to the local Sandbox directory
:: //

call :ECHOANDLOG Copying necessary binaries to Sandbox ....

COPY /Y %COMMAND_PATH%\%PROCESSOR_ARCHITECTURE%\* %SANDBOX_DIR%

:: if not exist %COMMAND_PATH%\%PROCESSOR_ARCHITECTURE%\fullsync.exe (

:: call :ECHOANDLOG FULLSYNC tool is not present on the specified network location

%COMMAND_PATH%\%PROCESSOR_ARCHITECTURE%; Exiting...
:: goto :COPYLOGS
::)

cd /d %TEMP%

:: //
:: // Check if FULLSYNC tool is already installed for the current user
:: //

if not exist %TEMP%\fullsync.exe goto :CREATE

%VER_COMMAND_BIN% %TEMP%\fullsync.exe >> %VISTA_BG_SYNC_TASK_TEMP_FILE%

:: //
:: // Compare and copy the new version of the tool
:: //

call :ECHOANDLOG Comparing Local and Network File Version for any updates in the FULLSYNC tool
...

for /f "tokens=5" %%I in ('%SANDBOX_DIR%\FILEVER.EXE %TEMP%\fullsync.exe') do (

SET LOCAL_FILE_VER=%%I
call :ECHOANDLOG Local File Version=%%I
)

for /f "tokens=5" %%I in ('%SANDBOX_DIR%\FILEVER.EXE %SANDBOX_DIR%\fullsync.exe') do (

SET NETWORK_FILE_VER=%%I
call :ECHOANDLOG Network File Version=%%I
)

if /I %LOCAL_FILE_VER% EQU %NETWORK_FILE_VER% (

call :ECHOANDLOG FULLSYNC tool is Up to date, Exiting ...
goto :COPYLOGS
) else (
call :ECHOANDLOG New Version of FULLSYNC tool is available, Updating the Scheduled Task
"Vista Background Sync for User=%USERNAME%, Domain=%USERDOMAIN%"
goto :DELETEANDCREATE
)

:CREATE
:: //
:: // Copy the binaries to the local directory
:: //
call :ECHOANDLOG Copying necessary binaries ....
COPY /Y %COMMAND_PATH%\%PROCESSOR_ARCHITECTURE%\* %TEMP%

:: //
:: // Create Schedule Task for FULLSYNC
:: //
call :ECHOANDLOG Creating a Schedule task for FULLSYNC tool
schtasks /create /XML %TEMP%\FULLSYNC.xml /tn "Vista Background Sync for User=%USERNAME%,
Domain=%USERDOMAIN%"

70
if %ERRORLEVEL% NEQ 0 (
call :ECHOANDLOG Creating Scheduled Task for FULLSYNC Task Failed with Error:%ERRORLEVEL%
;Exiting...
goto :DELETE
)

:: //
:: // Run Schedule Task for FULLSYNC
:: //
:: call :ECHOANDLOG Running Schedule task: "Vista Background Sync for User=%USERNAME%,
Domain=%USERDOMAIN%"
:: schtasks /Run /tn "Vista Background Sync for User=%USERNAME%, Domain=%USERDOMAIN%"
:: if %ERRORLEVEL% NEQ 0 (
:: call :ECHOANDLOG Running Scheduled Task for FULLSYNC failed with Error:%ERRORLEVEL%
;Exiting...
:: goto :DELETE
::)

goto :COPYLOGS

:: //
:: // Display Usage
:: //

:USAGE
ECHO [USAGE]:
ECHO Vista_Background_Sync_Logon_Script.cmd [/D]
ECHO Script to Create and Schedule a Background Sync task
ECHO The Scheduler task that it creates: "Vista Background Sync for User=%USERNAME%,
Domain=%USERDOMAIN%"
ECHO /D: To Delete the existing Scheduled Task

goto :EOF

:ECHOANDLOG

:: //
:: // Log messages in a temp file
:: //
ECHO. >> %VISTA_BG_SYNC_TASK_TEMP_FILE%
ECHO %*
ECHO %* >> %VISTA_BG_SYNC_TASK_TEMP_FILE%
goto :EOF

:DELETEANDCREATE

:: //
:: // Delete and Create the existing Scheduled Task
:: //
call :ECHOANDLOG End the existing scheduled Task "Vista Background Sync for User=%USERNAME%,
Domain=%USERDOMAIN%"
schtasks /End /tn "Vista Background Sync for User=%USERNAME%, Domain=%USERDOMAIN%"
call :ECHOANDLOG Delete the existing scheduled Task "Vista Background Sync for User=%USERNAME%,
Domain=%USERDOMAIN%"
schtasks /Delete /tn "Vista Background Sync for User=%USERNAME%, Domain=%USERDOMAIN%" /F
goto :CREATE

:DELETE

:: //
:: // Simply Delete and existing Scheduled Task
:: //

call :ECHOANDLOG End the existing scheduled Task "Vista Background Sync for User=%USERNAME%,
Domain=%USERDOMAIN%"
schtasks /End /tn "Vista Background Sync for User=%USERNAME%, Domain=%USERDOMAIN%"
call :ECHOANDLOG Delete the existing scheduled Task "Vista Background Sync for User=%USERNAME%,
Domain=%USERDOMAIN%"
schtasks /Delete /tn "Vista Background Sync for User=%USERNAME%, Domain=%USERDOMAIN%" /F

for /f %%I in ('dir /b /s %SANDBOX_DIR%') do (

71
 call :ECHOANDLOG Deleting %TEMP%\%%~nxI ...
del /F %TEMP%\%%~nxI
)

:COPYLOGS

:: //
:: // Copy Local Log File to Server
:: //

copy /y %VISTA_BG_SYNC_TASK_TEMP_FILE% %OUTPUT_PATH%

rmdir /s /q %SANDBOX_DIR%

:EOF

FullSync.exe
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF
// ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO
// THE IMPLIED WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A
// PARTICULAR PURPOSE.
//
// Copyright (c) Microsoft Corporation. All rights reserved
//
//
// This program uses the COM APIs to trigger a data synchronization through
// Sync Center. Once built, this executable can be used in conjunction with
// a scheduled task to trigger periodic synchronization of data when that
// synchronization is managed through Sync Center. Offline Files is an example
// of data that is managed in this way.
//
// The progress and final status of this sync activity can be seen through
// the Sync Center UI.
//

#include "stdafx.h"
#include <windows.h>

#include <stdio.h>
#include <tchar.h>

#include <SyncMgr.h> // Needed for SyncMgr interfaces

#include <comutil.h>

//
// This routine issues a synchronization request to Sync Center using its
// ISyncMgrControl COM API. The "silent" parameter determines whether the
// program prints out the status of its steps or not.
//
HRESULT
SyncCenter_SyncAll(
BOOL silent
)
{
HRESULT hr;
ISyncMgrControl *m_pSyncControl; // Reference to SyncMgr that is used to control sync
activity

if( !silent )
{
printf( "Binding to ISyncMgrControl...\n" );
}

//
// Get instance of Sync Manager

72
 //
hr = CoCreateInstance( __uuidof(SyncMgrControl),
NULL,
CLSCTX_ALL,
IID_PPV_ARGS(&m_pSyncControl) );

if( SUCCEEDED(hr) )
{
if( !silent )
{
printf( "Calling SyncAll...\n" );
}

//
// Issue the sync request to Sync Center. Sync Center processes requests
// sequentially. If any other sync is already running, this sync task
// will run once that task finishes. The StartSyncAll() will return
// once the sync task is queued, not once it has completed.
//
m_pSyncControl->StartSyncAll( NULL );
m_pSyncControl->Release();
}
else
{
if( !silent )
{
printf( "Bind failed : %x\n", hr );
}
}

return hr;
}

void __cdecl wmain( int argc, WCHAR** argv )

{
CoInitializeEx( NULL, COINIT_MULTITHREADED );

SyncCenter_SyncAll( (argc > 1) ? TRUE : FALSE );

CoUninitialize();
}

FullSync.xml
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Source>Microsoft Corporation</Source>
<Author>Microsoft Corporation</Author>
<Description>This task controls periodic synchronization of Offline Files when the user is
logged on</Description>
<URI>\Microsoft\Windows\SyncCenter\FullSync</URI>
</RegistrationInfo>
<Triggers>
<TimeTrigger>
<Repetition>
<Interval>PT360M</Interval>
<StopAtDurationEnd>false</StopAtDurationEnd>
</Repetition>
<StartBoundary>2008-01-01T00:00:00</StartBoundary>
<Enabled>true</Enabled>
<ExecutionTimeLimit>PT30M</ExecutionTimeLimit>
</TimeTrigger>
</Triggers>
<Settings>
<IdleSettings>
<Duration>PT10M</Duration>
<WaitTimeout>PT1H</WaitTimeout>
<StopOnIdleEnd>true</StopOnIdleEnd>

73
 <RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>false</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>true</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>true</RunOnlyIfNetworkAvailable>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>P1D</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>%TEMP%\fullsync.exe</Command>
<Arguments>none</Arguments>
</Exec>
</Actions>
</Task>

Windows Vista Offline Rename Delete

This script enables the Offline Rename Directory for Windows Vista SP1 and Windows Vista Service Pack 2 (SP2)
clients.

Vista offline rename delete

:: // Description:
:: // This script enables Offline Rename Directory for Vista SP1 and Vista SP2 clients
:: // Note that Machine should have installed with KB942845.
:: // Reference http://support.microsoft.com/kb/942845

:: // The script creates a local log file and copies the local log file to the path defined
in OUTPUT_PATH
:: // The script uses the redirected folders location defined in REDIRECTED_FOLDERS_LOCATION

@echo off

:: //
:: // Initialize Global Variables
:: //

SET REDIRECTED_FOLDERS_LOCATION=\\File-Server-1\RedirectedFoldersShareName
SET OUTPUT_PATH="\\File-Server-1\data$\Offline_Rename_Delete\DomainX\"
SET OFFLINEDIRRENAME_TEMP_FILE=%TEMP%\OFFLINEDIRRENAME_%USERNAME%_%COMPUTERNAME%.TXT
SET CurrentDir=%TEMP%

:: //
:: // Delete existing Local Log File if Present
:: //

IF EXIST %OFFLINEDIRRENAME_TEMP_FILE% DEL %OFFLINEDIRRENAME_TEMP_FILE%

:: //
:: // Create Header Information for Log File
:: //

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO EXECUTION DATE AND TIME: %DATE% %TIME% >> %OFFLINEDIRRENAME_TEMP_FILE%
ECHO COMPUTERNAME: %COMPUTERNAME% >> %OFFLINEDIRRENAME_TEMP_FILE%
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

74
cd /d %TEMP%

:: //
:: // Check if OfflineDirRenameDelete Key Exists
:: // If Registry Key Exist Skip Creation of Keys
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG Check if OfflineDirRenameDelete Key Exists...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

REG QUERY "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\NetCache" /V

OfflineDirRenameDelete
IF %ERRORLEVEL% EQU 0 GOTO :OfflineDirRenameDelete_Exists

:: //
:: // Registry Key Does Not Exist and Key Needs to be Created
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG OfflineDirRenameDelete Key Does Not Exist. Continuing Script...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

GOTO :ENABLE

:OfflineDirRenameDelete_Exists

:: //
:: // Registry Key Exists and Exiting Script
:: //

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

call :ECHOANDLOG OfflineDirRenameDelete Key Exists. Exiting Script...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

GOTO :LOG_SETTINGS

:ENABLE

:: //
:: // Set the necessary Reg Key for Offline File Directory Rename and Delete...
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG Setting the necessary Registry for Offline File Directory Rename and Delete
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

REG ADD "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\NetCache" /v

OfflineDirRenameDelete /t REG_DWORD /d 1 /f
REG ADD
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\NetCache\OfflineDirRenameDeleteList
" /v %REDIRECTED_FOLDERS_LOCATION% /t REG_DWORD /d 1 /f

:: //
:: // Verify OfflineDirRenameDelete Registry Key was created successfully.
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG Check that OfflineDirRenameDelete was created...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

REG QUERY "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\NetCache" /V

OfflineDirRenameDelete
IF %ERRORLEVEL% EQU 0 GOTO :OfflineDirRenameDelete_Creation_Successful
IF %ERRORLEVEL% NEQ 0 GOTO :OfflineDirRenameDelete_Creation_Failed

75
GOTO :EOF

:OfflineDirRenameDelete_Creation_Successful

:: //
:: // OfflineDirRenameDelete was created successfully.
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG OfflineDirRenameDelete created successfully...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
GOTO :CheckOfflineDirRenameDeleteList

:OfflineDirRenameDelete_Creation_Failed

:: //
:: // OfflineDirRenameDelete was NOT created successfully.
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG Error....OfflineDirRenameDelete Registry Key Not created...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
GOTO :LOG_SETTINGS
:CheckOfflineDirRenameDeleteList

:: //
:: // Verify OfflineDirRenameDeleteList Registry Key was created successfully.
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG Check that OfflineDirRenameDeleteList was created...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%

REG QUERY
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\NetCache\OfflineDirRenameDeleteList
" /v %REDIRECTED_FOLDERS_LOCATION%
IF %ERRORLEVEL% EQU 0 GOTO :OfflineDirRenameDeleteList_Creation_Successful
IF %ERRORLEVEL% NEQ 0 GOTO :OfflineDirRenameDeleteList_Creation_Failed
GOTO :EOF

:OfflineDirRenameDeleteList_Creation_Successful

:: //
:: // OfflineDirRenameDelete created successfully.
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG OfflineDirRenameDelete created successfully...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
GOTO :LOG_SETTINGS

:OfflineDirRenameDeleteList_Creation_Failed

:: //
:: // OfflineDirRenameDeleteList was NOT created successfully.
:: //

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
call :ECHOANDLOG Error....OfflineDirRenameDeleteList Not created...
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
GOTO :LOG_SETTINGS
:LOG_SETTINGS

:: //
:: // Log settings to Local Log File
:: //

76
ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
ECHO NetCache Registry Key Settings: >> %OFFLINEDIRRENAME_TEMP_FILE%
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
REG QUERY "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\NetCache" >>
%OFFLINEDIRRENAME_TEMP_FILE%

ECHO. >> %OFFLINEDIRRENAME_TEMP_FILE%

ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
ECHO NetCache\OfflineDirRenameDeleteList Registry Key Settings: >> %OFFLINEDIRRENAME_TEMP_FILE%
ECHO ---------------------------- >> %OFFLINEDIRRENAME_TEMP_FILE%
REG QUERY
"HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\NetCache\OfflineDirRenameDeleteList
" >> %OFFLINEDIRRENAME_TEMP_FILE%

:: //
:: // Copy Local Log File to Server
:: //

COPY /Y %OFFLINEDIRRENAME_TEMP_FILE% %OUTPUT_PATH%

goto :EOF

:ECHOANDLOG

:: //
:: // Log messages to Local Log File
:: //
REM echo. >> %OFFLINEDIRRENAME_TEMP_FILE%
echo %*
echo %* >> %OFFLINEDIRRENAME_TEMP_FILE%

goto :EOF

:EOF

77