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 8367f20..236318b 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,7 @@ 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 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.
+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 files exist on one of the file servers,then you need to create empty top-level folders with the same names on the replica servers, data will be replicated automatically from the file server to the empty folders.  
 
 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.*