diff --git a/Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md b/Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md
index c27c6cf..2f1d733 100644
--- a/Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md	
+++ b/Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md	
@@ -20,7 +20,9 @@ Install the roles on **both servers**:
 * **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.
+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).
@@ -35,8 +37,8 @@ Create (or identify) the folders you want to publish in the namespace, and share
 | 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.
+!!! 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: