Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments نسخه متنی

Deploying File Servers

Deploying file servers involves installing Windows Server 2003 on the physical servers, adding the servers to the network, and then implementing the design decisions you made throughout this chapter. Organizations that plan to deploy clustered file servers must take the additional step of configuring the clusters; all other organizations can begin by choosing the installation method. Figure 2.19 describes the file server deployment process.

Figure 2.19: File Server Deployment Process

Installing Windows Server 2003

Before you install Windows Server 2003, you need to decide whether to perform clean installations or upgrades. You also need to decide if you want to perform an automated installation.

Choosing Between Clean Installations and Upgrades

If your servers are new and do not contain operating systems, you must perform clean installations. If you have existing servers, you can perform clean installations or upgrades. Consider the following points when choosing between a clean installation and an upgrade.

Choosing a new installation:

If you reformat your hard disk and then perform a new installation, the efficiency of your disk might improve (compared to not reformatting it). Reformatting also gives you the opportunity to modify the size or number of disk partitions to make them match your requirements more closely.

If you want to practice careful configuration management (for example, for a server where high availability is important), you might want to perform a new installation on that server instead of an upgrade. This is especially true on servers on which you have upgraded the operating system several times in the past.

Choosing an upgrade:

With an upgrade, configuration is simpler, and you retain your existing users, settings, groups, rights, and permissions.

With an upgrade, you do not need to reinstall files and applications. As with any major changes to the hard disk, however, it is recommended that you back up the disk before beginning an upgrade.

Preparing for a Clean Installation on Existing File Servers

Review the following issues before performing a clean installation on existing file servers:

If you are performing a clean installation on a file server that contains a domain-based DFS root, remove the server as a DFS root before you begin the installation.

If you are performing a clean installation on a member of an FRS replica set, use the Distributed File System snap-in (available in Windows Server 2003 or in the Windows Server 2003 Administration Tools Pack) to remove all inbound and outbound FRS connections to the server before beginning the clean installation.

Upgrading Existing File Servers

If you plan to upgrade file servers to Windows Server 2003, review the following issues:

Service pack requirements for servers running Windows NT 4.0. Before you can upgrade a server that is running Windows NT 4.0 to Windows Server 2003, you must first install Windows NT 4.0 Service Pack 5 or a later version.

Upgrading servers that contain multidisk volumes. If a server contains multidisk volumes, review the following issues:

If you are upgrading from Windows NT Server 4.0 to Windows Server 2003, verify that your backup software and hardware are compatible with both Windows NT Server 4.0 and Windows Server 2003. Next, back up and then delete all multidisk volumes (volume sets, mirror sets, stripe sets, and stripe sets with parity) before you upgrade, because Windows Server 2003 cannot access these volumes. Be sure to verify that your backup was successful before deleting the volumes. After you finish upgrading to Windows Server 2003, create new dynamic volumes, and then restore the data.

If you are upgrading from Windows NT Server 4.0 to Windows Server 2003, and the paging file resides on a multidisk volume, you must use System in Control Panel to move the paging file to a primary partition or logical drive before beginning Setup.

If you are upgrading from Windows 2000 Server to Windows Server 2003, you must use Disk Management to convert all basic disks that contain multidisk volumes to dynamic disks before beginning Setup. If you do not do this, Setup does not continue.

Upgrading servers that contain multiple DFS roots. If you are running a prerelease version of Windows Server 2003, Standard Edition, and the server hosts multiple DFS roots, only one of those roots will be available after the upgrade. For more information about this and other DFS issues during upgrades, see "Deploying DFS" later in this chapter.

Upgrading servers that are part of FRS replica sets. To keep the data in a replica set available during the upgrade, stagger the upgrades of replica members.

Choosing Automated Installations

Many large organizations use automated installations to install Windows Server 2003. Bulk installations are faster, easier, less expensive, more consistent, and more efficient than having users or IT professionals sit at servers and enter data manually. Windows Server 2003 provides the following tools and methods that you can use to design and deploy very simple or very sophisticated automated installations:

Remote Installation Services (RIS)

System Preparation Tool (Sysprep)

Unattended Installation

These automated installation methods address a variety of specific issues, and each method has inherent advantages and disadvantages, depending on the environment in which you use these methods. To determine the best methods to use in the context of your specific environment, see "Choosing an Automated Installation Method" in Automating and Customizing Installations of this kit.

Deploying Clustered File Servers

The cluster installation method you choose depends on whether you have existing clustered file servers. If you do have existing clustered file servers, you have several options when upgrading server clusters:

Perform a new installation of Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition, and configure the cluster at the same time.

Upgrade a cluster that is running Windows NT Server 4.0, Enterprise Edition.

Upgrade a cluster that is running Windows 2000, possibly through a rolling upgrade.

There are two major advantages to a rolling upgrade. First, there is minimal interruption of service to clients. (However, server response time might decrease during the phases in which fewer nodes handle the work of the entire cluster.) Second, you do not have to recreate your cluster configuration. The configuration remains intact during the upgrade process.

You cannot perform a rolling upgrade directly from Windows NT Server 4.0, Enterprise Edition to Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition. Instead you have two options:

You can maintain cluster availability by performing an upgrade to Windows 2000 first (as specified in the Windows 2000 documentation), and then upgrade to Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition.

You can perform a nonrolling upgrade directly from Windows NT 4.0 to Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition. Note that a nonrolling upgrade does not allow you to maintain cluster availability.

For comprehensive information on choosing the cluster installation method and performing the actual installation, see "Designing Server Clusters" in this book and see "Installing and upgrading on cluster nodes" in Help and Support Center for Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition.

Regardless of the installation type, evaluate your cluster hardware for compatibility with Windows Server 2003. For more information about choosing cluster hardware, see "Designing and Deploying Server Clusters" in this book.

After you have installed Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition and configured the server cluster, use the following sections for information about creating mounted drives and File Share resources on server clusters.

Creating Mounted Drives on Server Clusters

If you assign drive letters to the cluster storage devices, Windows Server 2003, Enterprise Edition, and Windows Server 2003, Datacenter Edition, limit the total number of such devices to 23. Mounted drives are not subject to this limit; you can use mounted drives to access more than 23 cluster storage devices in your server cluster.

When using NTFS mounted drives with server clusters, follow these recommendations:

Make sure that you create unique mounted drives so that they do not conflict with existing local drives on any node in the cluster.

Do not create mounted drives between disks on the cluster storage device (cluster disks) and local disks.

Do not create mounted drives from the cluster disk that contains the quorum resource (the quorum disk). You can, however, create a mounted drive from the quorum disk to a clustered disk.

Mounted drives from one cluster disk to another must be in the same cluster resource group, and they must be dependent on the root disk.

Use Event Viewer to check the system log for any Cluster service errors or warnings indicating mount point failures. These errors are listed as ClusSvc in the Source column and as Physical Disk Resource in the Category column.

For more information about creating mounted drives, see "Create a mounted drive" in Help and Support Center for Windows Server 2003.

Creating File Share Resources

After you choose the cluster installation method and create the server cluster, migrate existing data on existing file servers, if necessary, and then create one or more File Share resources by using the Cluster Administrator snap-in or by creating scripts. For more information about creating a cluster-managed file share, see "Create a cluster-managed file share" in Help and Support Center for Windows Server 2003.

If you prefer to use scripts to create File Share resources, see article Q284838, "How to Create a Server Cluster File Share with Cluster.exe" in the Microsoft Knowledge Base. To find this article, see the Microsoft Knowledge Base link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. For more information, see "Managing a server cluster from the command line" in Help and Support Center for Windows Server 2003.

After you create the File Share resources, you can enable shadow copies on cluster storage. For more information about enabling shadow copies on server clusters, see "Enable Shadow Copies of Shared Folders in a cluster" in Help and Support Center for Windows Server 2003.

Migrating File Server Data

If you plan to consolidate file servers or replace outdated servers with new servers, migrate existing applications and data to the new servers. To ensure the success of the migration, create a detailed and well-tested migration plan that does the following:

Minimizes the amount of time that data is unavailable to users

Minimizes the impact on network bandwidth

Minimizes the cost of the migration

Ensures that no data loss occurs during the migration

The following sections describe the tasks for creating a migration plan

Identifying Data to Migrate

Large organizations rarely have time to take all production data offline before migrating it. Instead, they typically move data gradually, migrating different classes of data in stages. A migration plan should identify which data to move, where to move it, and the order in which it should be moved. File server data can usually be classified in the following classes:

Business-critical data

Application data

Personal data (such as home directories)

Profiles or other configuration data

Departmental or group data

Other data types, such as special projects or temporary data

When creating your migration plan, determine whether you want to consolidate different classes of data at different rates, onto different hardware, onto servers with different SLAs, or to different locations. Also, consider the importance of the data when planning your migration. For example, to minimize the impact of any problems during the migration, you might choose to move nonessential data first, followed by business-critical data.

In addition to identifying which data to move, you can also identify data that you do not need to move, such as duplicate, obsolete, or non-business-related files. Eliminating these files from your migration plan decreases the number of files that you need to migrate and increases the amount of available storage on the target server after the migration.

Identifying Migration Risks

The next step is to assess the risks associated with data migration. The best way to identify these risks is to set up a test lab with clients and servers, similar to those in your production environment, and conduct trial migrations. In addition to testing your actual migration method, test any applications that are installed on client computers to determine if the applications are affected by the migration. For example, applications that depend on components stored on a particular file server might not work correctly if the file server or share is renamed after the migration is complete. If you identify problems, update your migration plan so that you prevent or mitigate those problems.

There are a number of solutions you can implement either before or during the migration to prevent problems from occurring. For example, you can ensure that shortcuts and links on client computers work correctly after the migration by doing one of the following:

Implementing DFS. If you have implemented DFS before the migration, the migration is transparent to users; you just need to update the link target location.

Migrating to clustered file servers. In this case, the migration is transparent if you create virtual servers that use the same name as the previously used file servers. You can also transparently migrate any stand-alone DFS namespaces to clustered file servers. Using the previous server names, create your virtual servers, and then migrate the namespaces by using Dfsutil.exe.

Using a third-party migration tool. Use a tool that can identify and fix broken links, such as OLE links or application-related links in the registry.

No migration plan is complete until you develop and test "back-out" procedures to follow if the migration fails at any stage in the process. Verify that you can restore data to its previous state and location in the event that you need to roll back the migration.

The following sections describe additional risks to consider during the migration.

NTFS permissions

When evaluating migration methods, determine whether the methods support migrating NTFS permissions. If you use domain local groups to assign permissions to files and folders, members of those groups will have the same access to the files and folders after they are moved to the new server. However, if you assign permissions to computer local groups, members of those groups cannot access the files after the migration. Either reconfigure permissions to use domain local groups before the migration, or plan to create new computer local groups on the target server and give those groups the appropriate permissions to the files after the migration is complete.

NTFS compression

If you use compression on the source servers, determine if you still require compression on the target server. Hardware on the target server is typically more powerful, with greater storage capacity. Therefore, compression might not be necessary, although you do need to account for the additional space required by the uncompressed data. Also, when you copy compressed files from one server to another, the compression attribute is lost unless you enable compression on the target volume.

Files encrypted by using EFS

Migrating encrypted files has a number of risks. Only administrators who are EFS recovery agents can copy or move files that are encrypted by other users. When these administrators copy or move encrypted files to a remote shared folder, the files are decrypted locally, transmitted in plaintext, and then re-encrypted on the target server only if the remote computer is trusted for delegation and the target volume uses NTFS. When the files are encrypted again on the target server, they have new file encryption keys that are encrypted by using the administrator's public key, if it is available, or by using a new public key, which EFS generates if the profile is unavailable. As a result, the users who originally encrypt the files are no longer able to access them. Therefore, do not copy or move encrypted files from one server to another; use a backup and restore method instead.

For more information about EFS recovery agents, see "Designing a Public Key Infrastructure" in Designing and Deploying Directory and Security Services of this kit.

Choosing a Migration Method

Because many migration methods require downtime to move data, migrating data can be challenging in the following situations:

The data has high uptime requirements as specified by SLAs in your organization, and the migration method might require more downtime than the SLA allows.

Users expect to be able to access that data throughout their workday or at all times.

When planning your migration, consider the advantages and disadvantages of each migration method that is available to you, such as those described in the following sections. Your organization might use other methods not described here.

Backup and restore data

This method involves making a backup of the source server and restoring the data on a target server. Depending on your backup method and hardware, this method might involve moving tapes from one backup device to another (for direct-attached backup hardware) or restoring data from a tape library.

Advantages:

Large organizations routinely back up and restore data, so you can use existing backups to begin the migration.

Backing up and restoring data does not impact network bandwidth when it is performed on the local servers.

You can use this method to migrate encrypted files.

Disadvantages:

Both the source server and the target server must support the backup device and its related software.

If users are accessing files during the backup, you must make arrangements to migrate files that change while the backup occurs.

Backup programs do not migrate shared folder information to the destination server. As a result, folders that are shared on the source server are not shared when you restore them on the destination server. You must share the destination folders manually or by using scripts, and then use Permcopy.exe, which is available on the Windows Server 2003 Deployment Kit companion CD, to migrate any share permissions. For more information about Permcopy.exe, click Tools in Help and Support Center for Windows Server 2003, and then click Windows Resource Kit Tools.

Use third-party migration tools, hardware, or services provided by hardware vendors

A number of third-party migration tools can automate the entire migration process. These migration tools typically offer features such as bandwidth throttling, scheduling, incremental file migration, and monitoring. Many hardware vendors also provide hardware solutions and services that can assist you in migrating data.

Copy the data

This method involves using Robocopy.exe to copy data from one server to another and then using Permcopy.exe to migrate share permissions. Use the /SEC parameter in Robocopy.exe to copy NTFS permissions from the source folder to the destination folder. After you finish moving the data, share the folders on the target server (either manually or by using scripts), and then use Permcopy.exe to copy share permissions from the source server to the target server.

Permcopy.exe and Robocopy.exe are available on the Windows Server 2003 Deployment Kit companion CD. For more information about Permcopy.exe and Robocopy.exe, click Tools in Help and Support Center for Windows Server 2003, and then click Windows Resource Kit Tools.

Advantages:

These tools are available as part of the Windows Server 2003 Deployment Kit.

This method is simple if you are migrating a small amount of data.

Robocopy.exe gives you a number of options for migrating data, including the following:

Using file names, wildcard characters, paths, or file attributes to include or exclude source files as candidates for migrating.

Controlling the number of times that Robocopy.exe retries an operation after encountering a recoverable network error.

Scheduling copy jobs to run automatically.

Disadvantages:

Files are copied across the network, which can impact network bandwidth.

This method should not be used to migrate encrypted files.

If users are accessing files as the files are copied, you must make arrangements to migrate files that change while the copy occurs.

This method might take a long time to complete if you are migrating large amounts of data.

This method does not migrate shared folder information to the destination server. As a result, folders that are shared on the source server are not shared when you copy or restore them on the destination server. You must share the destination folders manually or by using scripts, and then use Permcopy.exe to migrate any share permissions.

Completing the Migration

After you migrate data, verify that users can access the data on the new servers by completing the following tasks:

Verify that NTFS and share permissions are migrated correctly.

If a logon script maps drives to the old file servers, update the scripts so that they point to the new file servers.

If the migrated folders are DFS link targets, update the link information so that it points to the new file server.

If the migrated folders are redirected My Documents folders, use Group Policy to specify the new file server.

If you migrate data to a clustered file server, create the necessary File Share resources.

Deploying DFS

Before you upgrade a server containing a DFS root, ensure that the namespace will be available after the upgrade. After Windows Server 2003 is installed, either through a clean installation or upgrade, you can create new DFS namespaces or migrate existing DFS namespaces to servers running Windows Server 2003. If you create a new namespace, you can use the information provided by the design team in the "DFS Configuration Worksheet" (Sdcfsv_1.xls).

Upgrading Servers That Contain DFS Namespaces

If a file server contains existing DFS roots, they are converted as follows:

When you upgrade a server running Windows NT 4.0 to Windows Server 2003, any DFS roots are converted to Windows Server 2003 stand-alone DFS roots.

When you upgrade a server running Windows 2000 to Windows Server 2003, stand-alone DFS roots and domain-based DFS roots are converted to Windows Server 2003 stand-alone DFS roots and domain-based DFS roots, respectively.

In the following scenarios, DFS roots are not available after upgrade:

If you upgrade a server that hosts a root on a FAT volume, the namespace is unavailable until you convert the volume to NTFS.

If you are running a prerelease version of Windows Server 2003, Standard Edition, and that server hosts multiple DFS roots, only one of those roots will be available after the upgrade. The other roots are unavailable because servers running Windows Server 2003, Standard Edition support only one root per server. To work around this issue, you can do either of the following:

Before upgrading to Windows Server 2003, Standard Edition, use Dfsutil.exe to export all but one of the namespaces to text files, and then remove the roots for the namespaces you exported. After you complete the upgrades, use Dfsutil.exe to import each namespace to a separate server running Windows Server 2003, Standard Edition.

Upgrade to Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition, which both support multiple roots per server.

If you do not remove the additional roots before upgrading to Windows Server 2003, Standard Server, take the following steps to remove the extra roots from the server by using Dfsutil.exe:

To remove domain-based DFS roots

If the domain-based DFS root has multiple root targets, you must repeat this procedure for every root target. The DFS service will be briefly unavailable when the service is stopped and restarted, so perform this procedure during a period of low namespace usage.

Use the /UnmapFtRoot parameter in Dfsutil.exe to remove the extra roots from the server.





Use the /Clean parameter in Dfsutil.exe to remove the root-related registry entries from the server.





At the command prompt, type net stop dfs & net start dfs

To remove stand-alone DFS roots

Use the /Clean parameter in Dfsutil.exe to remove the root-related registry entries from the server.

Delegating the Administration of DFS Namespaces

Use the procedures below to allow members of the local Administrators group on each root server to create and manage domain-based DFS namespaces. For more information about delegating permission to manage a DFS namespace, see "Designing a DFS Namespace" earlier in this chapter.

The following procedure grants the selected user the ability to create new DFS namespaces as well as administer existing ones.

To delegate a user to administer DFS

In the Active Directory Users and Computers snap-in, on the View menu, click Advanced Features.






In the console tree, double-click the System folder to expand it.





Click the DFS-Configuration folder.

Any existing root objects appear in the details pane.





Right-click DFS-Configuration, and then click Properties.






On the Security tab, click Add.






Type the name of the user to whom you want to delegate administrative rights, and then click OK.






Select the user Full Control permission, and then click OK.

Use the following procedure to allow a user to have DFS administrative permissions only within a single DFS namespace.

To grant a user permission to administer only a single DFS namespace

In the Active Directory Users and Computers snap-in, on the View menu, click Advanced Features.






In the console tree, double-click the System folder to expand it.





Click the DFS-Configuration folder.

Any existing root objects appear in the details pane.





Right-click the root object that you want to allow the user to administer, and then click Properties.






On the Security tab, click Add.






Type the name of the user, and then click OK.






Verify that the user is granted the Full Control permission, and then click OK.

Creating New DFS Namespaces on Stand-Alone Servers

Use the Distributed File System snap-in or the command-line tools Dfscmd.exe and Dfsutil.exe to create the root and link targets on stand-alone (nonclustered) file servers. The following topics in Help and Support Center for Windows Server 2003 provide information on using these tools:

"Checklist: Creating a distributed file system"

"Dfscmd"

For more information about installing Dfsutil.exe, click Tools in Help and Support Center for Windows Server 2003, and then click Windows Support Tools.

If you plan to enable FRS on link targets in the DFS namespace, see "Deploying FRS" later in this chapter.

Creating New DFS Namespaces on Clustered Servers

Use the Cluster Administrator snap-in to create a stand-alone DFS namespace on a clustered file server. For more information about creating a DFS root on server clusters, see "Create a cluster-managed file share" in Help and Support for Windows Server 2003.

Migrating or Consolidating Existing Namespaces on New Servers

If you have namespaces on existing file servers that you want to consolidate onto a file server that is running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition, or if you want to move a namespace from one server to another, you can use the Dfsutil.exe support tool to export the namespace from the source server to the destination server.

In the following example, an administrator wants to migrate the following namespaces on different servers to a single server running Windows Server 2003, Enterprise Edition.

\\NT4SVR\Marketing (a stand-alone DFS root on a server running Windows NT Server 4.0)

\\W2KSVR\Public (a stand-alone DFS root on a server running Windows 2000 Server)

First, the administrator creates the following stand-alone DFS roots on the server running Windows Server 2003, Enterprise Edition:

\\NETSVR\Marketing

\\NETSVR\Public

Next, the administrator installs Windows Support Tools from the Windows Server 2003 operating system CD and then uses the Dfsutil.exe tool to run the following commands:

Dfsutil /Root:\\NT4SVR\Marketing /export:Nt4.txt
Dfsutil /Root:\\W2KSVR\Public /export:w2k.txt

Finally, the administrator runs the following commands to import the namespaces onto the server running Windows Server 2003, Enterprise Edition:

Dfsutil /Root:\\NETSVR\Marketing /import:Nt4.txt /set
Dfsutil /Root:\\NETSVR\Public /import:w2k.txt /set

Using Dfsutil.exe to Customize the Namespace

Use the Dfsutil.exe parameters listed in Table 2.22 to customize the namespace. For more information about using Dfsutil.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click Windows Support Tools.

Deploying FRS

After you have deployed a domain-based DFS namespace, you are ready to deploy FRS. This section describes the following FRS deployment scenarios:

Deploying a new replica set

Adding a new replica member to an existing replica set

This section also provides an overview of the tasks required to deploy each scenario. For detailed procedures for each scenario, see the worksheets specified in the relevant sections. The worksheets also provide information about using Sonar.exe to monitor the status of your FRS deployment. Sonar.exe is available on Windows Server 2003 Deployment Kit companion CD. For more information about Sonar.exe, click Tools in Help and Support Center for Windows Server 2003, and then click Windows Resource Kit Tools.

Deploying a New Replica Set

If you are deploying a new replica set, use the "FRS Configuration Worksheet" (Sdcfsv_2.xls) that was completed by the file services design team to begin the deployment. If the design team did not use this job aid, you will need the following information:

The names of the link targets to be replicated. These link targets form the replica set.

The FRS topology (ring, full mesh, hub and spoke, or custom) to use for each replica set. If the topology is custom, you also need the inbound and outbound connections for each replica member.

The FRS replication schedule for each connection.

The location and size of the staging directory.

The connection priorities for each inbound connection.

Use the following information to choose the appropriate FRS deployment scenario:

See "Deploying an Empty Replica Set" later in this section if you have two or more existing link targets on which you want to enable replication and the link targets do not contain data.

See "Deploying a Replica Set with Existing Content" later in this section if you have two or more existing link targets that contain data and the link targets are currently in use in your organization.

See "Adding a New Member to an Existing Replica Set" later in this chapter if you have an existing replica set and you want to add a new member.

Deploying an Empty Replica Set

This scenario requires that you have deployed your domain-based DFS namespace but you do not have any files and folders in the link targets that you plan to replicate. This scenario is the most efficient way to deploy FRS, because replica members perform their join operation on an empty tree. When you add files to the tree, FRS builds a single staging file for each file in the tree and uses those files to source all direct outbound partners.

Before you begin, choose a procedure for either a standard topology (ring, hub and spoke, or full mesh) or a custom topology.

Deploying a standard FRS topology

To deploy a ring, hub and spoke, or full mesh topology, perform the following tasks:

Disable referrals to the link targets to be replicated.





Configure the USN journal.





Configure replication for a standard topology, and choose the staging directory location.





Adjust the size of the staging directory.





Verify that replication is working.





Set the initial replication schedule.





Configure filters to exclude files or folders from replication (optional).





Copy the data into the replica tree, and verify that the data is consistent.





Optimize the replication schedule (optional).





Enable referrals to the replicated link targets.





Configure connection priorities (optional).

For a Word document that provides detailed instructions on completing each of these tasks, "Deploying a Standard FRS Topology for an Empty Replica Set" (Sdcfsv_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Deploying a Standard FRS Topology for an Empty Replica Set" on the Web at http://www.microsoft.com/reskit). After you complete these tasks, you can notify users that the DFS namespace is available.

Deploying a custom FRS topology

To deploy a custom FRS topology, perform the following tasks:

Disable referrals to the link targets to be replicated.





Configure the USN journal.





Configure replication for a custom topology, choose the staging directory location, and configure connection priorities.





Adjust the size of the staging directory.





Verify that replication is working.





Set the initial replication schedule (optional).





Configure filters to exclude files or folders from replication (optional).





Copy the data into the replica tree, and verify that the data is consistent.





Enable referrals to the replicated link targets.





Optimize the replication schedule (optional).

For a Word document that provides detailed instructions on completing each of these tasks, see "Deploying a Custom FRS Topology for an Empty Replica Set" (Sdcfsv_4.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Deploying a Custom FRS Topology for an Empty Replica Set" on the Web at http://www.microsoft.com/reskit). After you complete these tasks, you can notify users that the DFS namespace is available.

Deploying a Replica Set with Existing Content

In this scenario, you have deployed a DFS namespace with existing content in one or more link targets, but you are not using FRS to keep those link targets synchronized. Users know about and use the namespace, and they might be accessing files from the link targets. This scenario is more complex than deploying FRS in an empty directory tree for a number of reasons:

Users or applications might have locks on files or folders, which can prevent FRS from originating outgoing changes and receiving incoming changes.

If files exist on the initial master, FRS builds a unique staging file for each file in the tree for each direct outbound partner. In other words, each partner gets its own set of files, which is more disk I/O and disk space intensive.

The files in the replica tree of the initial master become authoritative, which means that after replication completes, the replica tree on each member is identical to the replica tree on the initial master. For servers that are not the initial master, FRS moves any files that existed in the replica tree to a folder named "NtFrs_PreExistin____See EventLog."

For these reasons, it is recommended that you create a new link and link targets (essentially setting up an empty replica set), configure replication as desired, and copy the existing data into the new replica tree. After replication is complete, change the name of the link that is associated with the replica set so that users can access the new replica set by using the existing link name.

In the following procedures, "existing link" refers to the link that already contains data in its link targets, and "new link" is the link that you create with replicated link targets.

To create a new link and link targets

If users can modify files in the link targets, disable referrals to the link targets for the existing link, and then close all open files.





Create a new link, and then follow the procedure in one of the following documents to set up an empty replica set:





"Deploying a Standard FRS Topology for an Empty Replica Set" (Sdcfsv_3.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Deploying a Standard FRS Topology for an Empty Replica Set" on the Web at http://www.microsoft.com/reskit).





"Deploying a Custom FRS Topology for an Empty Replica Set" (Sdcfsv_4.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Deploying a Custom FRS Topology for an Empty Replica Set" on the Web at http://www.microsoft.com/reskit).





Be sure to disable referrals to the new link targets so that users do not access them.





Copy the data to be replicated into the replica tree.

This step is complete when the files are replicated successfully to all replica members.





In the Distributed File System snap-in, under the existing link, add the same link targets that you added under the new link. Be sure to clear the Add this target to the replication set check box.





If you have not done so already, disable referrals, and then close all open files so that users are no longer accessing any files in the existing link targets.





Under the existing link, remove the link targets that are not replicated. After you complete this step, the existing link and the new link have identical link targets.

Figure 2.20 shows how two example links, Existing Link and New Link, appear in the Distributed File System snap-in at the end of this procedure.

Figure 2.20: Two Links in the Distributed File System Snap-in

Next, use the following procedure to change the link name that is associated with the new replica set to match the existing link name.

To match the new link name with the existing link name

In the Active Directory Users and Computers snap-in, click the View menu, and then click Advanced Features.






In the console tree, under the domain where the DFS root is located, navigate to System, File Replication Service, DFS Volumes.


When you expand DFS Volumes, you should see existing DFS replica sets, including the one that you created in the previous procedure. The replica set is identified as rootname|newlinkname. Identify the correct replica set before you continue.





To change the name of the link that is associated with the replica set, right-click the replica set, and then click Rename.






After rootname|, type the name of the existing link over the name of the new link.

Figure 2.21 shows how the rootname|newlink name appears at Step 2 and after Step 4.

Figure 2.21: Changing the Link Name

To complete the deployment, delete the new link.

To delete the new link

In the Distributed File System snap-in, locate the new link.

The new link should no longer have replication enabled. It might be necessary to close and reopen the snap-in for the updates to appear.





Right-click the new link, and then click Delete Link.






Enable referrals to the link targets for the existing link.

Adding a New Member to an Existing Replica Set

Before you add a new member to an existing replica set, determine how to source the new member. You have two choices:

Replicate the files to the new member across the network. When you replicate files across the network to the new member, you add the server as a link target within an existing replica set. When you add the new member to the topology, you can create a single inbound connection so that you source from a specific server, such as a server with fast connectivity, or you can add a computer with redundant inbound connections where it sources according to connection priority and schedule.

Prestage the files on the new member. When you prestage files, you use a backup program to back up the replica tree and restore it on the new member. Using a backup program is required to preserve the file object IDs and security descriptors. (Command-line tools such as Copy.exe, Xcopy.exe, and Robocopy.exe do not preserve these items, and they cannot be used to prestage files.) After you restore the files, FRS replicates to the new member any files that changed since the backup was created, thus minimizing the number of files that are replicated across the network.

The method you choose typically depends on the size of the replica set and the available network bandwidth. You should replicate files over the network only if one of the following conditions exists:

You have a high-bandwidth network, and you can afford to use part of that bandwidth for the initial replication.

You have a low-bandwidth network, and you can afford to use that bandwidth for initial replication, and you also have the time to wait for the initial replication to complete.

If neither of these conditions exists, you should prestage the new member.

The following sections describe three possible scenarios for adding a new replica member:

Prestaging a new replica member to avoid replicating files across the network.

Adding a new replica member that contains no content. In this scenario, files are replicated across the network.

Adding a new replica member that contains a copy of the content. In this scenario, the new member has an existing copy of the files, but these files are not prestaged. The files from the initial master are replicated across the network.

Prestaging a New Replica Member

In this scenario, you have an existing replica set, and you want to add a new replica member by prestaging it. After you prestage the new member and enable replication, FRS moves the prestaged files in the replica tree on the new member to the

NtFrs_PreExisting____See_EventLog folder, but FRS then moves back to the replica tree any files that have the same object ID and content as the files in the master replica set. FRS replicates across the network only the files that were added or changed since you prestaged the files.

Before you can prestage a new replica member, one of the following events must occur:

At least seven days have passed since you enabled replication between the first two members.

You clear the outbound change log by modifying the registry on all direct upstream partners.

To prestage a new replica member, perform the following tasks:

Configure the USN journal.





Prestage the new replica member.





Create a new link target, add it to the replica set, and then specify the staging directory location.





Disable referrals to the new link target.





Configure connection objects, the initial schedule, and connection priorities (custom topologies only).





Adjust the size of the staging directory.





Verify that replication is working on the new member.





Enable referrals to the link target.





Optimize the replication schedule.





Configure connection priorities (standard topologies only).

For a Word document to assist you in completing each of these tasks, see "Sdcfsv_5.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Pre-staging a New Replica Member" on the Web at http://www.microsoft.com/reskit). After you complete these tasks, you can notify users that the DFS namespace is available.

Adding a New Replica Member That Contains No Content

In this scenario, the new replica member does not contain a copy of the replica tree. Data will replicate across the network according to the replication schedule.

To add a new replica member that contains no content, perform the following tasks:

Configure the USN journal.





Create a new link target, add it to the replica set, and then specify the staging directory location.





Disable referrals to the new link target.





Configure connection objects, the initial schedule, and connection priorities (custom topologies only).





Adjust the size of the staging directory.





Verify that replication is working on the new member.





Enable referrals to the link target.





Optimize the replication schedule (optional).





Configure connection priorities (standard topologies only).

For a Word document to assist you in completing each of these tasks, see "Sdcfsv_6.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Adding a New Replica Member that Contains No Content" on the Web at http://www.microsoft.com/reskit). After you complete these tasks, you can notify users that the DFS namespace is available.

Adding a New Replica Member That Contains a Copy of the Content

In this scenario, the new replica member already contains a copy of the replica tree. You might have copied the data to the server manually (using Robocopy, for example), but you have not prestaged the new member. (Remember that prestaging preserves the file object IDs and security descriptors.) Because the data is not prestaged, the initial master replicates the entire replica tree to the new member, even if the new member already contains identical files. On the new replica member, FRS moves any files that existed in the replica tree to a folder named "NtFrs_PreExisting_____See_EventLog." After replication completes, you can either delete this folder or move any unique files back into the replica tree.

To add a new replica member that contains a copy of the content, perform the following tasks:

Follow the procedures in "Sdcfsv_6.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Adding a New Replica Member that Contains No Content" on the Web at http://www.microsoft.com/reskit).





After replication completes, locate the folder "NtFrs_PreExisting_____See_EventLog" on the new replica member.





Do one of the following:





If the folder contains unique files that are not part of the replica set, copy those files back into the replica tree.





If you do not want to save any of the files, delete the folder.

Configuring File Server Settings

Many procedures for configuring file server settings are provided in Help and Support Center for Windows Server 2003. Table 2.23 lists subjects and file server topics that can be useful for configuring file server settings. For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set search options. Under Help Topics, select the Search in title only checkbox.