bunny-lab/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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 8s
Details

Browse Source
This commit is contained in:
Nicole Rappe
2025-10-14 04:59:34 -06:00
parent a5ad8243b0
commit 478e73afee
1 changed files with 3 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
Workflows/Windows/Windows Server/Roles/DFS/Creating and Configuring DFS Namespaces with Replication.md
View File

@@ -20,9 +20,9 @@ Install the roles on **both servers**:
* **Next → Next → Install**, then finish. * **Next → Next → Install**, then finish.
### Create & Configure Network Shares ### 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. 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 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.* 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" !!! 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). - **Must exist on each server:** a shared folder to act as the *folder target* (path can differ per server).
@@ -77,6 +77,7 @@ Create the DFS folders and add folder targets:
* **Add** folder targets (one per server), e.g.: * **Add** folder targets (one per server), e.g.:
* `\\LAB-FPS-01\Projects$\Scripting` * `\\LAB-FPS-01\Projects$\Scripting`
* `\\LAB-FPS-02\Projects$\Scripting` * `\\LAB-FPS-02\Projects$\Scripting`
* 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. * When prompted *"Create a replication group to synchronize the folder targets?"*, click **Yes** to launch the DFS Replication wizard.
!!! info "**Be patient**" !!! info "**Be patient**"