Windows 2003 DFS

BCAS Windows 2003 DFS (Distributed File System)

1

Windows 2003 DFS (Distributed File System) Introduction The Distributed File System is used to build a hierarchical view of multiple file servers and shares on the network. Instead of having to think of a specific machine name for each set of files, the user will only have to remember one name; which will be the 'key' to a list of shares found on multiple servers on the network. Think of it as the home of all file shares with links that point to one or more servers that actually host those shares. DFS has the capability of routing a client to the closest available file server by using Active Directory site metrics. It can also be installed on a cluster for even better performance and reliability. Medium to large sized organizations are most likely to benefit from the use of DFS - for smaller companies it is simply not worth setting up since an ordinary file server would be just fine. Understanding the DFS Terminology It is important to understand the new concepts that are part of DFS. Below is an definition of each of them. Dfs root: You can think of this as a share that is visible on the network, and in this share you can have additional files and folders. Dfs link: A link is another share somewhere on the network that goes under the root. When a user opens this link they will be redirected to a shared folder. Dfs target (or replica): This can be referred to as either a root or a link. If you have two identical shares, normally stored on different servers, you can group them together as Dfs Targets under the same link. The image below shows the actual folder structure of what the user sees when using DFS and load balancing.

The actual folder structure of DFS and load balancing Windows 2003 offers a revamped version of the Distributed File System found in Windows 2000, which has been improved to better performance and add additional fault tolerance, load balancing and reduced use of network bandwidth. It also comes with a powerful set of command-line scripting tools which can be used to make administrative backup and restoration tasks of the DFS namespaces easier. The client windows operating system consists of a DFS client who provides additional features as well as caching. Setting Up and Configuring DFS


2

The Distributed File System console is installed by default with Windows 2003 and can be found in the administrative tools folder. To open, press Start > Programs > Administrative Tools > Distributed File System or in the Control Panel, open the Administrative Tools folder and click on the Distributed File System icon. This will open the management console where the entire Configuration takes place. The first thing you need to do is create a root. To do this, right click the node and select New Root. Press next on the first window to be brought to the screen where you will have to make the choice of creating either a stand alone or domain root. A domain root will publish itself in Active Directory and supports replication, whereas a stand alone root does not. If you have an AD Domain Controller set up on your machine, I recommend choosing the domain root. Note: The root would be the top level of the hierarchy. It is the main Active Directory container that holds Dfs links to shared folders in a domain. Windows 2003 allows your server to have more than one root - which wasn't the case in Windows 2000. The next screen is the one where you have to select which trusted domains will be hosted. Since I only have one domain in my network, only domain.com is visible. Once this is done you have to select a server on that domain - in my example it is netserv. The FQDN (Fully Qualified Domain Name) of this host server is netserv.domain.com.

The following screen allows you to specify the root name of your primary DFS root. You should give it something which will accurately define the contents of that share. In my example I have called this root "Company" - which would be a real name of an organization. You can change this to anything you want. You might wish to have a root called "Documents" - which would clearly state that one can expect to find anything related or specific to documents, and documentation in that root.


3

Figure: entering the dfs root name

You will now have to select the location of a folder in which all the files will be stored.

Figure : selecting the root share Tip: for added security, when selecting a folder, try to choose one that is located on a partition other than that of the operating system. Your DFS root is now configured and visible in the configuration console. Right click the root target and press Status to check if it is online or not. A green check mark verifies that everything is working properly and that the node is online, whereas a red X means that there is a problem. To add a new link, right click the root for which you want the link to be created, and select New Link. In the "New Link" screen, enter a name and path for the link and click OK. Repeat this for as

many links as you need to create. Figure: creating a new link


4

Links are visible right under the node. Below is a screenshot displaying the three links I have created for the COMPANY root.

Publishing the root in Active Directory

By publishing dfs roots in AD as volume objects, network users will be able to search for shares more easily and administration can be delegated. To do this right click the desired dfs root, select Properties and go to the Publish tab. Enter the appropriate details in each box and press OK. In the keywords section you can specify certain words that will help locate the dfs root when it is being searched for.

File Replication Services There are two types of replication: * Automatic - which is only available for Domain DFS * Manual - which is available for stand alone DFS and requires all files to be replicated manually. The four ways in which replication can be achieved between two or more servers are:


5

- Ring - Hub and Spoke - Mesh - Custom The first three refer to network topologies and the last allows you to specify an advanced method of replication, which can be tuned to your needs. The advantages and disadvantages of replication are as follows: Advantages - client caching, integration with IIS, easy to administer and setup. Disadvantages - limited configuration options, there is no method of programmatically initiating a replication session. Conclusion We have seen how with the use of the Windows 2003 Distributed File System, one is able to manage data more efficiently. The new and improved features make data management and distribution faster and more efficient because users are able to find what they need when they need it. Having highly available and reliable file services means that the total cost of ownership is kept low - making the life of an administrator much easier when it comes to managing data!

IMPLEMENTING DFS NAMESPACES DFS (Distributed File System) was first introduced in Windows 2000 as a way of managing shared disk resources across a network and making it easier for users to find and access these resources. With the release of Windows Server 2003 R2 however, a fresh release based on Windows Server 2003 Service Pack 1, DFS has been significantly enhanced in several ways. I’ll describe these enhancements and show how to implement them in various enterprise scenarios.

Installing DFS

What used to be DFS in Windows 2000 and Windows Server 2003 is now two separate components in Windows Server 2003 R2:


6

DFS Namespaces - This component allows you to create a namespace, which is a

virtual free of shared folders located on different servers.

DFS Replication - This component allows you to replicate the contents of shared folders using a new replication engine that replaces the File Replication Service (FRS) used by DFS in Windows 2000. Note that FRS is still used for replicating SYSVOL on domain controllers however.

The simplest way of installing these new DFS components is to use the Manage Your Server Wizard to add or upgrade the File Server role. Doing this installs the new DFS Management console and provides you the option of installing DFS Replication also if desired (Figure). If you only want to implement DFS Namespaces, you don’t need to install the additional DFS Replication component . if you want to take advantage of all the R2 enhancements to DFS Namespaces, you should ensure that:

All servers that host namespaces are running Windows Server 2003 R2 (or at least SP1).

All domain controllers are running SP1 or later.

All servers from which you plan on performing DFS namespace management tasks are running SP1 or later.

In addition, all desktop computers that will be accessing your namespaces should be running Windows XP SP2 or later.

Creating a Namespace Let’s use the new DFS Management console to create a new namespace. Our new namespace will be domain-based, that is, rooted at the domain (standalone namespaces are also supported and will be discussed later). Here’s the scenario we’re going to use for our example:

The Accounting department uses two file servers, BOX 162 and 163.

BOX162 hosts the following shares: Payables and Receivables.

BOX 163 hosts the following shares: Invoices, Inventory, and Reports.

The department wants to use DFS Namespaces to consolidate these resources into a single virtual folder tree that looks something like this: Accounting Ledger Accounts Payable (maps to Payables share) Accounts Receivable (maps to Receivables share) Catalog Inventory (maps to Inventory share) Billing Invoices (maps to Invoices share) Report Database (maps to Reports share) For purposes of this example, we’ll create our namespace on BOX162 on which we’ve installed the DFS Management console using the procedure outlined in the previous section. Start by opening the DFS Management console on this server and select the Namespaces node in the console tree (Figure )


7

Note that there are no namespaces until we choose to create one. To create a namespace, click New Namespace in the Action pane or right-click the Namespaces node and select New Namespace. The New Namespace Wizard starts and asks you to specify the server that will host your new namespace. Since we’ve installed DFS Namespaces on BOX162 we’ll use this server to host our namespace (Figure)


8

Click Next to proceed with the wizard. If the DFS service is not running on BOX612, you’ll now be prompted to start it. Next you’ll specify a name for your namespace, and considering the requirements of the Accounting department previously, we’ll name our new namespace “Accounting” (Figure)

Note that we didn’t previously create an Accounting share on this server, so the wizard will create this for us. Click Next and select domain-based namespace as the type of namespace we want to create (Figure)


9

A quick aside here concerning namespace types:

Domain-based namespaces - These namespaces are stored on both your namespace servers and within Active Directory. Storing namespaces in Active Directory makes them easier to search for in a domain-based networking environment, but the size of domain-spaced namespaces is limited to around 5000 folders. Also, a domain-based namespace can be hosted on more than one namespace server to provide fault tolerance.

Standalone namespaces - These namespaces are stored only on name servers and not within Active Directory. The advantage of this approach is that you can host ten times more folders (up to 50,000 folders) in your namespace, but to make your namespace fault-tolerant you have to use clustering since a standalone namespace can only be hosted on a single server.

Clicking Next and then Create will create a new namespace named Accounting in the R2.local domain of our sample forest. This namespace will be rooted in a shared folder named C:\DFSRoots\Accounting on BOX162, and this root folder will also be created by the wizard shared with Everyone being given Read permission. Figure shows the new namespace, which as yet has no folders in it:


10

Adding Folders to the Namespace Now let’s add our folders to the namespace. There are two kinds of folders we need to add:

Folders with targets - These are virtual (DFS) folders that map to real (physical) shared folders. For example, the folder Accounts Payable folder needs to have the Payables share on BOX162 as its target, the Report Database folder needs to have the Reports share on BOX163 as its target, and so on.

Folders - These are virtual folders that don’t map to any real shared folders on the network but are simply used to organize how shared resources are presented to users by the namespace. For example, the Ledger folder needs to be created to contain the

Accounts Payable and Accounts Receivable folders, which are both folders with targets located on BOX612.

To create a new folder in our Accounts namespace, select the namespace in the console tree and click New Folder in the Action pane or right-click the namespace and select New Folder. This opens the New Folder properties sheet, which lets you specify a name for your new folder and optionally a target. For example, to create the Ledger folder which has no target, enter the information shown in Figure


11

Then select the Ledger folder in the console tree, click New Folder again, and create the Accounts Payable folder as shown in Figure

Continue creating folders, with and without targets, until the desired namespace is complete (Figure)

Figure: Finished namespace for the Accounting department


12

Testing the Namespace To try accessing resources in our new namespace, we’ll log on as ordinary user Bob Smith to a desktop computer running Windows XP. Then, once logged on, we’ll click Start, then Run, type \\R2.local\Accounting (which is the root of our namespace) and click OK. This opens a window that displays four folders (Billing, Catalog, Ledger and Report Database) as if they are shared folders on a single server (Figure ). By clicking into each of these folders we can access further folders and the documents stored within their target folders.

Figure : Viewing the namespace and its contents

CONFIGURING DFS NAMESPACE How to configure namespaces in enterprise environments where there are multiple sites. Since a site, in Active Directory terminology, basically refers to a collection of computers that are connected together as a LAN, a multi-site environment usually means multiple LANs, each located at a different geographical site. For example, a company that has its headquarters in Vancouver (Canada) might have a secondary site or branch office located a few hours south in Seattle (USA). Even though both locations may belong to the same domain, they may be separate sites to better manage replication traffic over a slow WAN link connecting them. DFS Namespaces includes new features that makes DFS work more efficiently for scenarios like this than the older DFS component of Windows 2000 worked in such scenarios. We’ll look at several ways you can improve the operation of your namespace in an enterprise environment like this. Adding Namespace Servers When deploying domain-based namespaces, you can add additional namespace servers to host a namespace. This has several advantages:


13

If one namespace server hosting the namespace goes down, the namespace will still be

available to users who need to access shared resources on your network. Adding another namespace thus increases the availability of your namespace.

If you have a namespace that must be available to users all across your organization but your Active Directory network has more than one site, then each site should have a namespace server hosting your namespace. That way, when users in a site need to contact a namespace server for referrals, they can do so locally instead of sending traffic requests to other sites. This improves performance and reduces unnecessary WAN traffic.

Note that adding additional namespace servers is only supported for domain-based namespaces, not standalone namespaces. Before showing how to add a namespace server to a namespace, let’s quick ly review the scenario from my previous article:

Our domain is R2.local and our domain controller is BOX161.

We created a domain-based namespace named Accounting.

This namespace is hosted on server BOX162.

The namespace contains targets on servers BOX162 and BOX163.

All servers are located in Default-First-Site, which is company headquarters in Vancouver.

All servers are running Windows Server 2003 R2. To make our scenario more enterprise-level, we’ll now add the following:

We’ll create a second site named Seattle-Site, which is a branch office located in Seattle.

Seattle-Site is in the same domain R2.local.

Domain controller BOX171 is located in Seattle. Let’s now add BOX171 as a new namespace server for our Accounting namespace. Open the DFS Management console, select the \\r2.local\Accounting namespace in the console tree, and click the Namespace Servers tab in the Details pane (Figure)


14

Note that the Accounting namespace only has one namespace server at present (BOX162). Now let’s add BOX171 as an additional namespace server for this namespace. Click the Add Namespace Server link in the Action pane, or right-click on the namespace and select Add Namespace Server. Then browse to specify BOX171 as the additional namespace server for the Accounting namespace (Figure)

Note that a folder named Accounting will now automatically be created on BOX171 and shared with the appropriate permissions (Read permission for Everyone). You can override this default behavior if you like by clicking Edit Settings. Now you have two namespace servers defined for the Accounting namespace. One of these servers is BOX162 in Vancouver and the other is BOX171 in Seattle. The question is, when a user in Seattle tries to access the namespace, which namespace server will it use? This brings us to our next topic—referrals. Configuring Referrals To understand the importance of configuring referrals in an enterprise environment, you first need to understand how DFS Namespaces works. Going back to our scenario above, let’s say a user named Bob Smith located in Vancouver (Default-First-Site) wants to access resources in the Accounts namespace, which is spread over (targeted to) servers located in both Vancouver and Seattle (Seattle-Site). Here’s what typically happens:

1. Bob tries to access the root folder of the namespace \\R2.local\Accounting by contacting BOX162, one of two namespace servers for this namespace (the other namespace server being BOX171 located in Seattle).

2. BOX162 returns a referral to Bob. This referral contains a list of servers that host the particular folder (Accounting, the root of the namespace) Bob is trying to access. In this particular scenario, a root referral is returned; if Bob tried accessing a folder higher up in the namespace, a folder referral would be returned instead.

3. Bob’s Windows XP desktop computer caches the referral returned to it by BOX162 and proceeds to contact the first server in the referral list, which it turns out is BOX162 itself.

4. From there Bob starts browsing the namespace, and BOX162 continues to return referrals to folder targets for each folder browsed.

So what happens then when a user in one site tries to access a shared resource in a different site using DFS? By default, the list of targets returned by a referral for a particular shared resource are ordered thusly:


15

1. Targets in the user’s site are listed first. 2. If the user’s site has multiple targets, these are listed in random order. 3. Targets outside the user’s site are listed next, and if there are multiple targets in other

sites, the targets are listed according to their connection costs with lowest cost first (targets with the same cost are listed in random order).

This approach means that by default, DFS tries to connect a client with a target in the client’s own

site first whenever possible to prevent the client from having to use a WAN link to access the resource. Furthermore, DFS also tries to randomly load-balance such access when there are multiple targets available in the client’s site. There are several ways this process can be configured however. For example, instead of using lowest cost for accessing targets outside the client’s site, you could specify that DFS never use targets outside the client’s site at all. This might be useful, for example, if all the shared resources needed by that site are found locally at that site (or replicated to that site—I’ll cover DFS Replication in a future article). To configure this, right-click on the namespace and select Properties, then switch to the Referrals tab and select the Exclude Targets option as shown in Figure

Alternatively, you could leave the namespace configured so referrals outside the client’s site are done using least cost (the default setting) and then override this setting for individual folder targets. For example, right-click on the Accounts Payable folder target, select the Referrals tab, and select the first checkbox as shown in Figure below:


16

Another way of fine-tuning referrals is to change the priority of the folder targets for a particular folder. Since a folder can have more than one folder target (this is usually used in conjunction with DFS Replication) there is a default ordering to how these targets are returned in a referral. You can override this default ordering by selecting the folder in the console tree, right-clicking one of the targets listed in the Details pane for this folder, selecting Properties, selecting the Advanced tab, and configuring the override settings as desired (Figure)

For example, you could specify that a particular target is listed first in the referral, as shown in the figure above. Or you could specify it as last if the target is your “server of last resort” i.e. a standby server just in case everything else goes down. Finally, if your WAN links are unreliable, you might find your clients frequently accessing different targets for the same folder. This can be a problem, for by default, DFS caches referrals for a period of time (300 seconds or 5 minutes) so if a target server suddenly goes down the client will keep trying to connect to the target and give an error instead of making the resource available to the client from a different target. Eventually (by default after 300 seconds or 5 minutes) the referral will expire in the client’s cache and a new referral will be obtained to a target that is online and the client will be able to access the desired resource, but in the meantime the user may grow frustrated since (a) the user has to wait for the referral to expire and (b) after the referral expires and a new one is obtained, the referral may direct the client to access a remote target over the WAN link which is not an optimal situation. To prevent this from happening (especially non-optimal targets), you can configure client failback on the namespace (or on specific folders in your namespace) so that when the failed target comes back online the client will fail back to that target as its preferred target. This setting is also configured on the Referral tab as shown in Figure previously.


17

IMPLEMENTING DFS REPLICATION DFS Replication is basically just a service that can be used to replicate files from one server to another so you can maintain multiple copies in different locations of a single file. Of course, in pre-R2 Windows Server 2003 there was already such a service named (quite obviously) the File Replication Service or FRS, and this was used for two different purposes:

Replicating the contents of shared folders from one DFS tree to another.

Replicating the contents of the SYSVOL folder between one domain controller and another.

The trouble with FRS is that it did a good job of the second task but a lousy job of the first. For example, say you had two DFS trees set up to replicate using FRS, and the shared folders in these trees contained very large files like video files. If you made a small change to one such file (maybe by editing out a single video frame) then FRS had to replicate the entire file from one tree to the other, which meant lots of bandwidth being used for replication. This could be a particular problem when the two trees were located in different sites connected by a slow WAN link—replication of files could easily eat up the entire bandwidth of the link! On top of that, FRS in pre-R2 was also a bit shaky and prone to failure, which meant sometimes DFS didn't work properly at all, which could be a pain to say the least. Enter Remote Differential Compression File replication has changed however as of Windows Server 2003 R2. In particular, there are now two different replication services built into the platform, namely:

DFS Replication. This service is new and can be used not just for replicating DFS trees to provide fault tolerance and better performance, but even simply just replicating files between servers for any purpose. More about this new service in a moment.

File Replication Service (FRS). This is the original replication service, first released with Windows Server 2000, though somewhat enhance. In R2, the FRS is only used for replicating SYSVOL content on domain controllers and nothing else.

What's great is that the new DFS Replication service has a totally revamped replication engine that uses a new replication algorithm called Remote Differential Compression (RDC). This new algorithm replicates only the changes to files and not the files themselves, which means that DFS now works much better over slow WAN links than before. In addition, the new replication engine supports bandwidth throttling and replication scheduling, plus it operates on a multimaster replication model. The overall result is that DFS in Windows Server 2003 is much more solid in terms of its reliability and performance than before.

Setting Up DFS Replication In that scenario, the Accounting department used two file servers, BOX 162 and 163, with BOX162 having the shares Payables and Receivables while BOX163 had the shares Invoices, Inventory, and Reports. These shares were consolidated using DFS Namespaces into a virtual folder tree rooted in a shared folder named Accounting, which was created on BOX162 when we created the DFS namespace itself on that server. The following table describes how the folders in the DFS tree map to the shared folders on the two servers:


18

:

Shared Folder Server DFS Path

Accounting BOX162 \\r2.local\Accounting (root)

Payables BOX162 \\r2.local\Accounting\Ledger\Accounts Payable

Receivables BOX162 \\r2.local\Accounting\Ledger\Accounts Receivable

Invoices BOX163 \\r2.local\Accounting\Billing\Invoices

Inventory BOX163 \\r2.local\Accounting\Catalog\Inventory

Reports BOX163 \\r2.local\Accounting\Report Database

Note that the Invoices share is located on BOX163 and can be accessed using the DFS path \\r2.local\Accounting\Billing\Invoices where r2.local is the name of the Active Directory domain we are working with (this example uses a domain-based DFS namespace and the domain controller is BOX161). In other words, the Invoices share (C:\Invoices on BOX163) is the folder target associated with the \\r2.local\Accounting\Billing\Invoices folder in the \\r2.local\Accounting namespace. Note: The terminology for DFS differs in R2 than in Windows 2000 Server and pre-R2 Windows Server 2003. In the old version of DFS, the Invoices share was called the link target and \\r2.local\Accounting\Billing\Invoices the link associated with that target, while \\r2.local\Accounting was called the root. So be sure you understand the new DFS terminology R2 uses before you start working with it. In other words, roots are now called namespaces, links are called folders, and link targets are folder targets! Let's now use DFS Replication to replicate the contents of the Invoices share from BOX163 to BOX162. That way, should the share on BOX163 somehow become unavailable, users will still be able to access its content using BOX162. Of course, for true fault-tolerance you also need to replicate the namespace too. What we'll do here though is simply create a second Invoices share on BOX162, replicate the contents of \\BOX163\Invoices to \\BOX162\Invoices, and add \\BOX162\Invoices to the list of folder targets for the \\r2.local\Accounting\Billing\Invoices folder in the namespace. That way if a client (for example XP-191) tries to access a file named Sample.doc found in \\r2.local\Accounting\Billing\Invoices on BOX163 but BOX163 is down, it can access the copy of the file on BOX162.

To accomplish this, the first thing you need to do is install the DFS Replication component if you haven't already done so. As mentioned in my previous articles, when you add or upgrade the File Server role you have the option of installing DFS Namespaces but leaving DFS Replication uninstalled, and that's what we did previously. So to add DFS Replication now, you can use Add or Remove Programs in Control Panel. Start this utility, select Add/Remove Windows Components, select Distributed File System, click Details and select DFS Replication Service (see Figure ):


19

Insert Disk 2 of R2 when prompted or browse to the \CMPNENTS\R2 folder on your network distribution share to complete the installation of the component. Then create a new folder named C:\Invoices on BOX162 and share it with Full Control permission for Everyone (this choice does not mean the folder is not secure as NTFS permission are really used to secure resources, not shared folder permissions). Then be sure to install the DFS Replication component on BOX163 also since every file server that needs to participate in replicating DFS content must have the DFS Replication Service installed and running. You can again use Add or Remove Programs to do this, or use Manage Your Server. Now let's add \\BOX162\Invoices as a second folder target for \\r2.local\Accounting\Billing\Invoices. Open the DFS Management console and select the following node in the console tree: DFS Management, Namespaces, \\r2.local\Accounting, Billing, Invoices. Note that there is currently only one folder target for this folder (Figure ):

Verify from a client machine like XP-191 that a user can open the Sample.doc file by clicking Start, then Run,

typing \\r2.local\Accounting\Billing\Invoices and double-clicking on the file. Now let's add a second folder target (\\BOX162\Invoices) for this folder as follows. Right-click the Invoices folder in the console tree and select Add Folder Target. Then specify the path to the new target as shown in Figure


20

Once the second target is added, you'll be prompted to create a replication group (see next Figure)

A replication group is a collection of file servers that participate in the replication of one or more folders in a namespace. In other words, if we want to replicate the contents of \\BOX163\Invoices with \\BOX162\Invoices, then BOX163 and BOX162 must first be added to a replication group. Replication groups can be created manually by right-clicking on the DFS Replication node in the DFS Management console, but it's easier here if we just create one on the fly by clicking Yes to this dialog box. This opens the Replicate Folder Wizard, an easy-to-use method for replicating DFS content on R2

file servers (see figure) We won't walk through all of the steps of this wizard here, instead we'll just summarize what the various steps of the wizard do:

Replication Eligibility. Displays which folder targets can participate in replication for the selected folder (Invoices). Here the wizard displays \\BOX163\Invoices and \\BOX162\Invoices as expected.

Primary Member. Makes sure the DFS Replication Service is started on the servers where the folder targets reside. One server is initially the primary member of the replication group, but once the group is established all succeeding replication is multimaster. We'll choose BOX163 as the primary member since the file Sample.doc resides in the Invoices share on that server (the Invoices share on BOX162 is initially empty).

Topology Selection. Here you can choose full mesh, hub and spoke, or a custom topology you specify later. Selecting Full Mesh here jumps to the Replication Group Schedule and Bandwidth screen next.

Replication Group Schedule and Bandwidth. Lets you replicate the content continuously up to a maximum specified bandwidth or define a schedule for replication (we'll choose the first option, continuous replication).


21

After reviewing your settings and confirming, two one-way replication connections are created between the two servers and initial replication is performed. Depending on how many other domain controllers you have and where they are located, initial replication may take awhile to complete.

Testing Replication To view replication status for this folder, select the Replication tab as shown in this figure:

A quick check of the C:\Invoices folder on BOX162 using Windows Explorer shows that the Sample.doc file has been replicated from BOX163 to BOX162 as expected. If you disable Local Area Connection on BOX163 and browse \\r2.local\Accounting\Billing\Invoices on client XP-191, the Sample.doc file is still available because the user is transparently referred to the next available folder target on BOX162. Finally, if a change is made to the Sample.doc file on BOX162 or BOX163, the change is replicated almost immediately to the folder target on the other box.

CONFIGURING DFS REPLICATION This article continues the previous one by first examining some of the configuration options for DFS Replication and then looking at two scenarios where you might use DFS Replication in enterprise environments. Configuring DFS Replication In the previous article we used DFS Replication to provide fault-tolerance for \\r2.local\Accounting\Billing\Invoices, a folder within the \\r2.local\Accounting namespace in the


22

r2.local domain. This folder originally had only one folder target, the shared folder \\BOX163\Invoices, and to make this folder redundant we had to do two things:

Add a second folder target, namely the shared folder \\BOX162\Invoices, so that if the first folder target was unavailable, client machines could obtain a referral from the namespace server so they could connect to the second target instead.

Replicate the contents of the first folder target (\\BOX163\Invoices) to the second folder target (\\BOX162\Invoices) and keep the contents of these two shared folders in sync so that if one of them becomes unavailable, clients can still access the files stored in this namespace folder.

Using the Replicate Folder Wizard, we saw how easy this task is to perform. Let's spend a moment looking more closely at the results of the previous walkthrough and the configuration options that are available to us. The first figure shows the two folder targets created for the \\r2.local\Accounting\Billing\Invoices of our namespace:

Clicking the Add Folder Target link in the Actions pane at the right (or right-clicking on the Invoices folder in the console tree and selecting Add Folder Target) lets us easily add additional folder targets for this folder if greater redundancy is needed. Let's switch to the Replication tab in the middle pane and see what options are available:


23

Here we see the two folder targets that replicate with each other to provide fault-tolerance for the Invoices folder. Right-clicking on either of these folder targets and selecting Properties will bring up read-only properties for these targets. Clicking the Stop Replicating link in the Action pane will stop replication between these folder targets and delete the replication group that the Replicate Folder Wizard created earlier for these targets. To further configure replication settings, we first

need to select the


24

previously created replication group in the console tree, which can be found under the Replication node as shown here: The Memberships tab lets us add additional members to this replication group. A member is a server that participates in replication of folders, so for example if we want to create a third folder target for Invoices and point this folder target to a share on a server named BOX164, we first need to make BOX164 a member of the replication group for Invoices and then add the folder target to the share on that box. DFS Replication makes this easy—click the New Member to start a wizard that guides you through the process of adding a new server to the replication group. Alternatively, let's say you want to make another folder in the namespace redundant. For example, the folder \\r2.local\Accounting\Catalog\Inventory currently has a single folder target, namely \\BOX163\Inventory. If you wanted to add a second folder target for this folder, say \\BOX162\Stuff, simply click the New Replicated Folder link in the Action pane to start a wizard that guides you through the process. Once this is done, the new replicated folder will be displayed on the Replicated Folders tab. The Connections tab displays the two one-way connections created by DFS Replication between \\BOX163\Invoices and \\BOX162\Invoices, the two folder targets for the Invoices folder:

We'll see the advantage of having one-way connections in a moment. But first, recall that when we ran the Replicate Folder Wizard we chose to have files replicated continuously between the two targets for Invoices. What if we want to change this and schedule when replication occurs instead? This might be useful for example if the two members of the replication group are in different sites connected by a WAN link that is so highly utilized during the day that you would prefer to have replication occur only at night. You can configure your replication schedule in two ways. First, you can define a schedule for the entire replication group and all folders that it


25

replicates by right-clicking the replication group under Replication in the console tree at the left and selecting Properties:

Then click the Edit Schedule button and edit the schedule for the replication group as desired.

Note that these schedules operate according to the schedule of the receiving member of a replication action over a replication connection i.e. DFS Replication is a pull process not a push process. You can also limit how much absolute bandwidth is used by the replication process, but be aware that this is only an average bandwidth and peak bandwidth may exceed this value occasionally. The second way of scheduling replication is to configure it on a per-connection basis, which can be done by opening the properties sheet of the appropriate connection instead. There are other DFS Replication settings we could look at, but let's move on now and talk about


26

two enterprise scenarios where DFS Replication can be especially useful, namely branch office backups and publishing content. Using DFS Replication for Branch Office Backups When we walked through the Replicate Folder Wizard in the previous article, we saw that two pre-defined topologies could be selected:

Full Mesh. Every member of the replication group replicates with every other member of the group.

Hub and Spoke. Every hub member replicates with the hub member, and if desired you can add a second hub member for fault tolerance (the two hub members replicate with each other).

The full mesh topology is useful mainly in large LAN environments where all subnets have high speed connectivity and you are using DFS Namespaces together with DFS Replication to provide fault-tolerant shared file resources to users. Note that Microsoft recommends that replication groups with full mesh topologies have no more than 10 members in them. The hub and spoke topology is more interesting and can have a particular use for enterprises that have large headquarters where the company's permanent IT staff are located and multiple small branch offices with little or no on-site IT staff present. For such branch offices, one big concern is ensuring that reliable backups are done. Performing backups however costs money (tape drives and tapes) and effort (rotation and archiving of tapes) at such branch offices, and using DFS Replication you can workaround this as follows:

1. Create a replication group that has the hub member at headquarters and an additional spoke member at each branch office.

2. Create a folder target on the hub member for each branch office member, where the branch office folder target points to the shared file resources that need to be backed up at that branch office.

3. Configure DFS Replication to replicate between the hub and each branch office at 1 a.m. each night.

4. Finally, disable the connections that go from the hub to each branch office so that replication occurs only from the branch offices to the hub and not vice versa.

Now all you have to do is configure your tape backup system at headquarters to back up the folder targets on the hub each night at 3 a.m. and you've automatically got each branch office's file resources backed up at headquarters without cost or effort to the branch offices themselves. Using DFS Replication to Publish Content The hub and spoke topology can also be useful for publishing content from headquarters to branch offices in enterprise environments similar to the one described above. Just create a replication group with two hub members at headquarters (the second hub member is used to ensure fault-tolerance in case the first one fails) and with one spoke member at each branch office. DFS Replication will then automatically take files created at headquarters and replicate them out to branch offices. This is a great way of disseminating information throughout an enterprise, and again you can disable inbound connections to the hubs if you only need to publish content to the branches and not the other way.

Windows 2003 DFS

Documents

Transcript of Windows 2003 DFS