I85PREP
⌘ K
MSCE study materials
MSCE study resources

File Server Migration and DFS Namespace Cutover

MSCE · Put your knowledge to work in context.

All case studies

File Server Migration and DFS Namespace Cutover

Northwind has a single file server (FS01) hosting 4 TB of departmental shares on a RAID-5 volume that is 92% full. They are adding FS02 with 8 TB of storage. Users access shares by UNC path \FS01\department. The company wants to move to a DFS namespace so paths survive future server changes. There are 400 users across three departments, each with its own share and NTFS permissions inherited from parent folders. Backups run nightly and must not be interrupted. The migration must be completed over a weekend with minimal user impact.

1. Design the DFS namespace and migration approach, including how to avoid breaking existing user shortcuts and mapped drives.

Read the worked answer
  1. Create a domain-based DFS namespace (e.g., \corp\files) so the path is independent of server names. Domain-based namespaces get AD replication and multiple namespace servers for redundancy.
  2. Create a folder per department under the namespace, each with a folder target. Initially point all targets at FS01 so nothing changes for users.
  3. Pre-stage data: use Robocopy with /MIR /COPY:DATSO /R:1 /W:1 (or DFS Replication) to seed FS02 during the week, then run a final incremental sync during the weekend maintenance window to catch changes.
  4. Preserve permissions: Robocopy /COPY:DATSO preserves ACLs; verify with icacls on a sample of folders after the copy.
  5. Cut over: after final sync, change each folder target from FS01 to FS02, then remove the FS01 target. Users' mapped drives and shortcuts should be repointed to \\corp\files\department - do this via GPO drive mapping or a logon script so the change is centralized, and keep FS01 shares read-only for a grace period.
  6. Validate: test access with representative users from each department before declaring success.

2. The RAID-5 volume on FS01 is 92% full. What risks does this create during migration, and how do you mitigate them?

Read the worked answer

Risks:

  • No headroom for the final sync: changes made during the week may not fit if FS01 fills completely; a full volume can also break shadow copies and backups.
  • RAID-5 rebuild risk: a single disk failure during heavy migration I/O could cause a rebuild that stresses remaining disks; RAID-5 has a known vulnerability window during rebuild.
  • Backup interference: a full volume may cause the nightly backup to fail or truncate.

Mitigations:

  • Run an early cleanup/archival pass (move stale data to archive, enable quotas) to free at least 10-15% before migration.
  • Schedule the bulk copy during off-hours and throttle Robocopy (/IPG) to limit I/O contention.
  • Confirm the backup completes successfully before and after each copy phase; take a fresh backup immediately before cutover.
  • Verify RAID health and spare availability before starting; do not begin the migration with a degraded array.

3. How should you verify that NTFS permissions survived the migration and that users retain only their intended access?

Read the worked answer
  • Compare ACLs: run icacls <path> /save on source and target for each department share and diff the outputs; inherited vs explicit flags must match.
  • Check ownership: confirm file/folder ownership is preserved (/COPY:DATSO includes security and ownership); if ownership changed, fix with takeown/icacls /setowner as appropriate.
  • Effective access test: use the Effective Access tab in the file properties (or Get-Acl plus group membership analysis) for a sample user in each department to confirm they have exactly the intended rights.
  • Negative test: confirm a user from Department A cannot access Department B's share.
  • Share vs NTFS: remember the effective permission is the most restrictive of share and NTFS; verify both layers.
  • Document the results and keep the pre-migration ACL export as a rollback reference.