DFS Namespace and Replication

You are diagnosing a DFS problem. DFS-N (namespaces) decides which target a user is referred
to; DFS-R (replication) gets content between targets — separate them first. Nothing here
executes: these are steps for a tech with the right access.

Climb the Troubleshooting Ladder base skill first: this client's past tickets for DFS and file
shares (a server added or renamed, a bulk migration, a disk-full event, or a dirty shutdown),
then their documentation for the design — namespaces and folder targets, replication groups
and topology, staging-quota sizes, and Windows Server version.

Then get the evidence. DFS-N: the referral list for the path — targets, their order,
enabled/online state, reachability. DFS-R: the backlog count between the specific sending and
receiving members, the health report, and DFSR event-log state (recovery, error,
staging-full).

Branch:

1. DFS-N referral — users hit the wrong, slow, or no target. Check target priority and ordering
   (site cost sends users to their local target), whether a target is disabled or
   offline, and the client's AD site — a client in the wrong site gets wrong referrals. "No
   target" means every target is offline or the folder target was removed.

2. DFS-R backlog — content is stale because changes are queued. Decide draining vs stuck: a
   large migration needs patience and maybe a staging-quota bump; an error state, unreachable
   member, or expired content freshness is stuck. A member offline longer than
   MaxOfflineTimeInDays is stale and needs deliberate recovery — escalate rather than
   re-enabling it, because reconnecting it wrong resurrects deleted files or loses changes.

3. Conflicts — simultaneous edits on two members keep the last writer and move the loser to
   ConflictAndDeleted, recoverable for a time, not forever. Never treat DFSR as two-way sync for actively co-edited files: if the real problem is
   concurrent editing, fix the design (single writable target, per-site folders,
   SharePoint/OneDrive) rather than blaming replication.

4. Staging bottleneck — replication crawls or errors under heavy change because staging is too
   small for the largest files and churn, or its disk is full. Raising the quota is the lever;
   confirm disk space and the churn source first.

Never reinitialize replication or delete the DFSR database as a first move: an authoritative
sync resets one side to the other and loses recent changes on the losing member. Establish
which member is authoritative and get the client's sign-off first. Don't invent command syntax,
event IDs, or offline-limit defaults; check Microsoft's docs and cite.

Verify with a real test: a file created on one member appears on the other, backlog near zero,
a test client referred to its local target. Then note it (apply the PSA Note Discipline base
skill): DFS-N vs DFS-R, evidence, branch, action or handoff, and verification.