Windows Server 2008

Planning a DFS Architecture, Part 2

In the first part of this article series, I talked about the differences between a stand-alone DFS namespace and a domain based DFS namespace.  The next thing I want to discuss is the replication topology that will be used by your DFS servers.

Why Replicate?

When I have introduced the concept of DFS to clients in the past, one of the first questions that they always ask me is why in the world they need multiple DFS servers.  Technically, you don’t have to have multiple DFS servers, but there are some advantages to using multiple replica servers.  For starters, using multiple replicas provides you with a degree of scalability.  Rather than having every user in your organization access their files from the same server, you can distribute the user workload across multiple DFS replicas rather than over burdening a single server.

Another reason for having multiple DFS replicas is because doing so provides you with a degree of fault tolerance.  For example, suppose that you need to install a service pack onto your servers.  Most of the time when you install a service pack for Windows, the installation process requires you to reboot the server when you’re done.  Normally, rebooting a server is disruptive to the users who are accessing files on that server.  If you know that you’re going to be doing maintenance on one of your servers though, you can remove the server from the DFS namespace, and perform your maintenance without disrupting the users.  When you’re done, you can designate the server to act as a part of the namespace once again.

Sponsored Content

What is “Inside Microsoft Teams”?

“Inside Microsoft Teams” is a webcast series, now in Season 4 for IT pros hosted by Microsoft Product Manager, Stephen Rose. Stephen & his guests comprised of customers, partners, and real-world experts share best practices of planning, deploying, adopting, managing, and securing Teams. You can watch any episode at your convenience, find resources, blogs, reviews of accessories certified for Teams, bonus clips, and information regarding upcoming live broadcasts.

DFS can also provide fault tolerance from the standpoint of protecting you against network link failures.  For example, suppose that your company has a branch office that is connected to the main office by means of a WAN link.  Normally, if the WAN link were to fail then users in the branch office would lose access to any of the servers in the main office.  If you place a DFS replica in the branch office though, then the users in the branch office can continue to access their files even during a WAN link failure.  When the link is eventually reconnected, any modifications to files in either office will be synchronized with the other server.

Replication Topology

Windows Server 2008 supports a couple of different types of replication topologies for DFS servers.  Each of these topologies have their good points and their bad points. If you are having trouble deciding which replication topology is right for your organization, then you should give serious consideration to using the same DFS replication topology as you’re using for your Active Directory infrastructure.

The Hub and Spoke Topology

One of the most popular replication topologies is the hub and spoke topology, shown in Figure A. The hub and spoke topology involves placing the initial master in the middle of the topology.  Each replica performs two way replication with the initial master, but does not replicate with any of the other replicas.  This type of topology tends to be very efficient, but the problem with it is that if the initial master were to fail, then all replication would cease to function until it came back online.

Figure A This is what the hub and spoke topology looks like.

The Full Mesh Topology

Another commonly used replication topology is the full mesh topology. This topology, shown in Figure B, allows every replica to replicate with every other replica.  The advantage of using this topology is that replication will still continue to function even if a server drops off-line.  Of course the disadvantage to using this method is that it can result in an excessive amount of replication traffic.

Figure B The full mesh topology provides replication connectivity between every replica.

No Topology?

When you configure a replication group in Windows Server 2008, one of the topology options that Windows allows you to choose from is No Topology.  As strange as it might sounds to not define a replication topology, there is actually a really good reason for using this option.  The No Topology option allows you to create a replication group without defining a replication topology.  This allows you to create your own custom replication topology later on.


As you can see, the replication topology plays an important part in the overall DFS architecture.  In Part Three of the series, I will talk about some best practices for planning your DFS architecture.

Got a question? Post it on our Windows Server 2008 forums!

Related Topics:

External Sharing and Guest User Access in Microsoft 365 and Teams

This eBook will dive into policy considerations you need to make when creating and managing guest user access to your Teams network, as well as the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

You will learn:

  • Who should be allowed to be invited as a guest?
  • What type of guests should be able to access files in SharePoint and OneDrive?
  • How should guests be offboarded?
  • How should you determine who has access to sensitive information in your environment?

Sponsored by:

Office 365 Coexistence for Mergers & Acquisitions: Don’t Panic! Make it SimpleLive Webinar on Tuesday, November 16, 2021 @ 1 pm ET

In this session, Microsoft MVPs Steve Goodman and Mike Weaver, and tenant migration expert Rich Dean, will cover the four most common steps toward Office 365 coexistence and explain the simplest route to project success.

  • Directory Sync/GAL Sync – How to prepare for access and awareness
  • Calendar Sharing – How to retrieve a user’s shared calendar, or a room’s free time
  • Email Routing – How to guarantee email is routed to the active mailbox before and after migration
  • Domain Sharing – How to accommodate both original and new SMTP domains at every stage

Aimed at IT Admins, Infrastructure Engineers and Project Managers, this session outlines both technical and project management considerations – giving you a great head start when faced with a tenant migration.the different layers of guest access and the common challenges that accompany a more complicated Microsoft 365 infrastructure.

Sponsored by: