Update Workflows/Windows/Windows Server/Roles/DFS/Setting Up DFS Across Multiple File Servers.md

Workflows/Windows/Windows Server/Roles/DFS/Setting Up DFS Across Multiple File Servers.md

@@ -1,93 +1,100 @@
 ## Purpose
-If you want to ensure that data is safely replicated across multiple file servers in a domain environment, you will want to set up DFS "namespaces".  These are network shares that are distributed across multiple file servers, and appear as one network share.  They replicate to eachother automatically, keeping both in sync with eachother.  The document below outlines the process of deploying DFS across two (2) file servers.  
+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"
-    It is assumed that you have at least two Windows Server based servers already set-up, both are running the correct Editions of Windows Server (e.g. "Standard"), are activated, and are domain joined with sensible hostnames (e.g. `LAB-FPS-01` and `LAB-FPS-02`), and that both have statically-assigned IP addresses.
+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
-The first step you want to perform is installing the necessary roles on *both servers*.
+Install the roles on **both servers**:
 
-- Navigate to "**Server Manager > Manage > Add Roles and Features**
-- Click "Next" through the windows of the role wizard until you reach the "**Server Roles**" page
-- Expand "**File and Storage Services**"
-    - Expand "**File and iSCSI Services**"
-        - Check "**File Server**"
-        - Check "**DFS Namespaces**"
-        - Check "**DFS Replication**"
-- Click the "**Next**" button
-- Click the "**Next**" button
-- Click the "**Install**" button and wait for the installation to finish.
+* **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
-The next step in the process is to ensure that the network shares that will be shared via DFS have sane permissions.  You will want to ensure the following minimum permissions are configured.
+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 "Replicate Folders and Permissions Across all File Servers"
-    It is important for you to understand that every member server of the DFS namespaces and replication need to be configured identically, with the same shared folder structures.  To clarify, you can have the underlying files in different locations on-disk, but they need to have the same permissions and paths on the network shares themselves under `\\SERVER\<share$>`
+!!! 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.
 
-    **NOTE**: The data for the shares only needs to exist on one server to ensure it can be replicated across to the other member servers of the DFS namespaces.  During DFS configuration, this server is designated as the "Primary Member". This server's folder contents are treated as authoritative for the initial sync and replicate to the other members of the DFS namespace.
+| **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` and `Administrators` | Full Control | Required for DFSR service and local admin management. |
+| NTFS | `Share_Admins` | Full Control | Optional admin group for data management. |
+| NTFS | *Business groups needing access* | Modify | Grant least privilege to required users/groups. |
 
-| **Permission Type** | **User / Group** | **Access Level** | **Details** |
-| :--- | :--- | :--- | :--- |
-| Share | `Authenticated Users` | Full Control | This is to ensure that only domain authenticated users can access the share. |
-| NTFS | `SYSTEM` | Full Control | This is so DFS replication can properly function. |
-| NTFS | `Share_Admins` | Full Control | This is a security group I created for admins to manage the data on network shares unilaterally. |
-| NTFS | *<Any Users / Groups That Need Access>* | Modify | This is for anyone who needs access to these specific files / folders. |
-
-!!! info "Disable Permission Inheritance"
-    It's just more organized to keep permission inheritance turned-off for the share, so parent folder permissions don't influence it, which could cause unexpected issues in the future if the parent's permissions were changed.
+!!! 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
-At this point, we need to create a DFS "Namespace".  This is basically a logical representation of either a single or a group of individual folders on one or more file servers.  The files and folders appear under a singular location like `\\bunny-lab.io\Projects\Scripting`.  In this example, `Projects` is the namespace (Its not a real folder with data), and `Scripting` is a folder replicated across one or more file servers, mapping to a real (generally hidden) network share like `\\LAB-FPS-01\Projects$\Scripting`.  In this example, there is a network share located at `Projects$` that (organizationally) correlates to the `Projects` DFS namespace, but you should not put files and folders in this root location, as it can cause issues or introduce potential corruption.
+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
-Now, we need to start working on actually setting up DFS now that the shares exist (and are configured identically) on all member servers.  You can choose to do these steps on any of the member servers, but I recommend using the lowest number server (e.g. `LAB-FPS-01`).  The configurations will be automatically replicated across to all member servers from the server you choose to configure, so in reality, it really doesn't matter which server you choose.
+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
-- Navigate to "**Server Manager > Tools > DFS Management**"
-- In the left-hand sidebar, right-click "Namespaces" > "**New Namespace...**"
-    - Choose a member server (e.g. `LAB-FPS-01`) then click "**Next**"
-    - Give a name to the namespace (e.g. `Projects`) then click "**Next**"
-        - You do *not* need to click on the "Edit Settings" button.  Just leave all of the settings as-is with `All users have read-only permissions` as this permission controls the namespace configuration data permissions in `C:\DFSRoots\<Namespace>`
-    - Click "**Next**"
-    - Ensure that the "**Domain-based namespace**" radio button is checked, and the "**Enable Windows Server 2008 mode**" is checked.
-        - The domain-based namespace example should look something like this: `\\bunny-lab.io\Projects`
-    - Click "**Next**"
-- At this point, the namespace was created and you can move onto linking folders to the namespace to make their data appear inside of it and replicate to other member servers.
+
+* **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
-At this point, we need to configure folders on every member server to be linked to the namespace we created.  In this context, the "Folders" are the subfolders of the network share we want to share and replicate in DFS.
+Create the DFS folders and add targets:
 
-- Right-click the namespace we just created (e.g. `\\bunny-lab.io\Projects`)
-- Click on "**New Folder**"
-    - This is the point where we link subfolders to folders inside of the namespace.  For example, if we have a folder located at `\\LAB-FPS-01\Projects\Scripting`, the folder name we create here would be named `Scripting`.
-    - Under "Folder Targets" you will click on the "**Add**" button
-        - Browse the "Path to folder target" and navigate to the equivalant location on all member servers, one entry per server:
-            - `\\LAB-FPS-01\Projects$\Scripting`
-            - `\\LAB-FPS-02\Projects$\Scripting`
-        - Click the "**OK**" button
-    - You will be prompted with "*A replication group can be used to synchronize the folder targets of the folder you just created.  Do you want to create a replication group?*".  You will click the "**Yes**" button and proceed to the next section. 
+* 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**: it takes about a minute to load the replication group wizard"
+!!! info "**Be patient**"
+    The Replication wizard can take ~1 minute to appear.
 
 #### Configure Replication Group
-As mentioned in the previous section, you clicked "**Yes**" to the automatic replication group wizard and arrived at the replication wizard.  Follow the steps below to finalize replication for the share.
+In the Replication wizard that appears after about a minute, you can configure the replication group for the folder:
 
-- Replication Group Name: `<Leave Value As-Is>`
-- Replicated Folder Name: `<Leave Value As-Is>`
-- Click "**Next**" > "**Next**"
-- When prompted for the "Primary Member", you need to select the server that currently hosts the live data.  It will completely overwrite the other member servers when it begins replicating itself across the file servers. (e.g. `LAB-FPS-01`)
-- Click "**Next**"
-- Topology: `Full mesh` > Click "**Next**"
-- Configure a replication schedule; I recommend leaving it with the default settings to enable continuous 24/7 365 synchonization between all member file servers, then click "**Next**"
-- Click "**Create**"
+* **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.
 
-!!! success "Replication Group Created"
-    At this point, you should see successful creation of the replication group and can click on the "**Close**" button and move onto the next folder / namespace and wait for replication to take-place.
+* **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**
 
-    - ✅Create replication group: Success
-    - ✅Create members: Success
-    - ✅Update folder security: Success
-    - ✅Create replicated folder: Success
-    - ✅Create membership objects: Success
-    - ✅Update folder properties: Success
-    - ✅Create connections: Success
+!!! 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