## 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 for additional security. Additionally, it is recommended (if possible) to set the share names to be hidden. For example `\\LAB-FPS-01\Projects$`, that way it ensures that users access the share via DFS at `\\bunny-lab.io\Projects` and users don't accidentally access the file servers directly, bypassing DFS. For example, the local path would be `Z:\Projects` but the network share would be `\\LAB-FPS-01\Projects$`. *This wouldn't break things like replication, but it would muck things up a little bit organizationally.* !!! 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 "Note 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. ### 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 **Namespaces** → **New 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** #### Link Folders to Namespace 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