Files
docs/Workflows/Windows/Windows Server/Roles/DFS/Setting Up DFS Across Multiple File Servers.md
Nicole Rappe 9428d24a67
All checks were successful
GitOps Automatic Deployment / GitOps Automatic Deployment (push) Successful in 8s
Update Workflows/Windows/Windows Server/Roles/DFS/Setting Up DFS Across Multiple File Servers.md
2025-10-13 23:29:42 -06:00

5.7 KiB

Purpose

If you want data available from a single, consistent UNC path while hosting it on multiple file servers, use DFS Namespaces (DFSN). A namespace presents a virtual folder tree (for example, \\bunny-lab.io\Projects) whose folders point to one or more folder targets (actual SMB shares on your servers). DFS Replication (DFSR) is a separate feature you configure to keep the contents of those targets in sync.

This document walks through creating a domain-based DFS namespace and enabling DFS Replication for two servers.

!!! info "Assumptions" You have two Windows Server machines (e.g., LAB-FPS-01 and LAB-FPS-02) running an edition that supports DFS (Standard or Datacenter), both activated, domain-joined, and using static IPs.

Installing Server Roles

Install the roles on both servers:

  • Server Manager → Manage → Add Roles and Features
  • Click Next to Server Roles
  • Expand File and Storage Services
    • Expand File and iSCSI Services
      • Check File Server
      • Check DFS Namespaces
      • Check DFS Replication
  • Next → Next → Install, then finish.

Create & Configure Network Shares

Create (or identify) the folders you want to publish in the namespace, and share them on each server. Be sure to enable Access-based Enumeration on all of the folder shares.

!!! warning "What must match vs. what can differ"

  • Must exist on each server: a shared folder to act as the folder target (path can differ per server).
  • Share permissions: are not replicated; set them on each server.
  • NTFS permissions inside the replicated folder: are replicated by DFSR and should be consistent.
  • Targets do not have to use identical share names/paths, but keeping them consistent simplifies things.
Permission Type User / Group Access Level**
Share Everyone (or Authenticated Users) Full Control Best practice is to grant broad Full Control on the share and enforce access with NTFS.
NTFS SYSTEM Full Control Required for DFSR service.
NTFS Share_Admins Full Control Optional admin group for data management.
NTFS Business groups needing access Modify Grant least privilege to required users/groups.

!!! info "On Inheritance" Disabling inheritance is not required for DFS/DFSR. Keep it enabled unless you have a clear reason to flatten ACLs; inheritance often reduces long-term admin overhead. Disabling permission inheritance is simply my personal preference.

DFS Breakdown

A namespace is a logical view like \\bunny-lab.io\Projects. Inside it, you create DFS folders (e.g., Scripting) that point to one or more folder targets, such as:

  • \\LAB-FPS-01\Projects$\Scripting
  • \\LAB-FPS-02\Projects$\Scripting

The namespace root itself isn't where you store data; it's a directory of links. Place data in the folder targets the DFS folder points to.

DFS Configuration

You can run these steps from either server (or any admin workstation with the RSAT tools). DFSN configuration is stored in AD and on namespace servers and applies across members automatically.

Create Namespace

  • Server Manager → Tools → DFS Management
  • Right-click NamespacesNew Namespace…
    • Choose a server to host the namespace (e.g., LAB-FPS-01) → Next
    • Name the namespace (e.g., Projects) → Next
      • You can leave Edit Settings at defaults; those control the local folder that backs the namespace root, not your data.
    • Choose Domain-based namespace and check Enable Windows Server 2008 mode (required for larger scale and Access-based enumeration).
      • Resulting path: \\bunny-lab.io\Projects
    • Next → Create

Create the DFS folders and add targets:

  • Right-click the new namespace (e.g., \\bunny-lab.io\Projects) → New Folder…
    • Name: Scripting
    • Add folder targets (one per server), e.g.:
      • \\LAB-FPS-01\Projects$\Scripting
      • \\LAB-FPS-02\Projects$\Scripting
    • When prompted "Create a replication group to synchronize the folder targets?", click Yes to launch the DFS Replication wizard.

!!! info "Be patient" The Replication wizard can take ~1 minute to appear.

Configure Replication Group

In the Replication wizard that appears after about a minute, you can configure the replication group for the folder:

  • Replication Group Name: (leave as suggested)
  • Replicated Folder Name: (leave as suggested)
  • Next → Next
  • Primary member: pick the server with the most up-to-date copy of the data (e.g., LAB-FPS-01).

!!! warning "Important" In DFSR, "Primary member" is used only for initial sync conflict resolution. It does not permanently dominate, and DFSR will not blindly wipe unique files on other members; conflicts are handled via versioning (e.g., "ConflictAndDeleted"). For large datasets, consider pre-seeding to reduce initial replication time via robocopy.

  • Topology: Full mesh (good for two servers; for many sites, consider hub-and-spoke).
  • Replication schedule: leave Full (24x7) unless you need bandwidth windows.
  • Create

!!! success "Replication group created" You should see green ticks for the following. Give everything some time to replicate as it depends on active directory replication speeds to push out the configuration across the DFS member servers and begin the replication.

- Create replication group
- Create members
- Update folder security
- Create replicated folder
- Create membership objects
- Update folder properties
- Create connections