Update Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md
All checks were successful
GitOps Automatic Deployment / GitOps Automatic Deployment (push) Successful in 9s
All checks were successful
GitOps Automatic Deployment / GitOps Automatic Deployment (push) Successful in 9s
This commit is contained in:
@@ -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.*
|
||||
|
||||
|
||||
Reference in New Issue
Block a user