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 03:58:44 -06:00
parent 336f9a9817
commit 0518c592cd
1 changed files with 5 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -20,7 +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. 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" !!! 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).
@@ -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 | `Share_Admins` | Full Control | Optional admin group for data management. |
| NTFS | *Business groups needing access* | Modify | Grant least privilege to required users/groups. | | NTFS | *Business groups needing access* | Modify | Grant least privilege to required users/groups. |
!!! info "On Inheritance" !!! 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. Disabling permission inheritance is simply *my* personal preference. 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 ### 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: 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: