docs/Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md

## 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.  You only need to ensure that the folders exist on one of the servers, it will be created on-the-fly and replicated automatically.

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 network shares 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**

#### Make Namespace Highly-Available
We have to perform an extra step to ensure that every file server can act as within a multi-master context, allowing for high availability.  To do this in this example, we will add `LAB-FPS-02` as a secondary namespace server for every namespace that we create.

- Right-Click **DFS Management** > **Namespaces** > `\\bunny-lab.io\Projects`
- Click **Add Namespace Server...**
- Under "Namespace Server" enter `LAB-FPS-02` then click **OK**.

#### Enable Access-Based Enumeration on Namespace

- Right-Click **DFS Management** > **Namespaces** > `\\bunny-lab.io\Projects`
- Click **Properties**
- Click **Advanced**
- Check **Enable access-based enumeration for this namespace**
- Click **OK**

#### Link Folders to Namespace
Create the DFS folders and add folder 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`
      * You can simply copy-paste the previous server location and substitute the hostname (e.g. switching `01` to `02`) instead of browsing for the folder.
        * You *may* be prompted to create the folder because it does not exist on `LAB-FPS-02`, in this circumstance, you can tell it to create the folder automatically with read-only permissions.  *Don't worry, when replication from `LAB-FPS-01` occurs, NTFS permissions will be overwritten to the correct users and groups.* 
  * 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