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
All checks were successful
GitOps Automatic Deployment / GitOps Automatic Deployment (push) Successful in 8s
This commit is contained in:
@@ -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:
|
||||
|
||||
Reference in New Issue
Block a user