Moving SYSVOL is a little tricky because the folder you can see isn’t the whole story. There are junctions, paths in AD, and the share path Netlogon publishes. It’s worth getting comfortable with those in a lab before moving the real thing.

The notes below are for a DC already using DFSR. They aren’t an FRS-to-DFSR migration procedure. If replacing or re-promoting the DC is an option, promotion lets you select the destination with -SysvolPath. That avoids relocating an existing replica by hand.

The manual path is a lab procedure to rehearse against your server version, not an end-to-end procedure validated by the Microsoft references below. Microsoft’s older relocation article covers FRS; it doesn’t validate the DFSR steps below. For an in-place production move, involve Microsoft support if that’s an option.

Preparation

Quickly confirm AD replication is ok.

This might seem counterintuitive because SYSVOL uses DFSR which is separate to general AD replication, but a large amount of the configuration information required by SYSVOL is being read from AD by the DFSR service.

repadmin /replsummary /bysrc /bydest > repsum.txt

We should also do a system state backup of the domain controller we are working with as well as the file system of the SYSVOL tree. For example, C:\Windows\SYSVOL on a default install.

Moving

In this example we will move SYSVOL from the default C:\Windows\SYSVOL to a new disk at the location E:\SYSVOL.

Record the current Netlogon registry value, subscription attributes and junction targets first. Some migrated DCs use SYSVOL_DFSR, so don’t substitute these example paths without checking. The destination should be a new, empty directory.

1 - Stop Netlogon and DFSR during the move. Keep policy changes out of this maintenance window too; stopping replication alone doesn’t prevent another process from writing files.

Stop-Service -Name Netlogon
Stop-Service -Name DFSR

2 - Copy the SYSVOL folder from the source to the target and preserve ACLs/ownership/auditing.

robocopy C:\Windows\SYSVOL E:\SYSVOL /E /COPYALL /XJ /R:1 /W:1

/XJ is deliberate: exclude the junctions and recreate them with new targets later. Otherwise the copy can follow the old junctions and produce duplicate real directories where links should be. /E copies the tree without /MIR’s destination-deletion behaviour. Inspect the copy result before changing any paths; Robocopy exit codes of 8 or above indicate at least one failure.

Optional verification:

icacls C:\Windows\SYSVOL /save C:\temp\sysvol_acl_source.txt /t icacls E:\SYSVOL /save C:\temp\sysvol_acl_target.txt /t

3 - Update the SYSVOL value under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. In this layout it becomes E:\SYSVOL\sysvol, not just E:\SYSVOL: it points at the share root containing the domain-name junction.

4 - Update msDFSR-RootPath and msDFSR-StagingPath using ADSI Edit, preserving their existing relative layout under the new root. These identify the replicated content and staging directory; they aren’t the same path as the Netlogon share root.

The values are in the domain partition on the SYSVOL subscription object for the domain controller you are working on. For example, the test domain in this example is contoso.com, and we are working on the domain controller - DC-SYDNEY-2. The object we will modify the attributes on is:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=DC-SYDNEY-2,OU=Domain Controllers,DC=contoso,DC=com

DFSR Paths

5 - Check the two locations where we’ll create junctions: E:\SYSVOL\staging areas\contoso.com and E:\SYSVOL\sysvol\contoso.com. With an empty destination and /XJ, neither should have been copied. If either exists, inspect it before going further. A real directory and a junction need different treatment; don’t recursively delete something just because its name looks like a link.

6 - Recreate the junctions. These commands can be run from PowerShell; mklink itself belongs to cmd.exe:

cmd /c mklink /J "E:\SYSVOL\staging areas\contoso.com" "E:\SYSVOL\staging\domain"
cmd /c mklink /J "E:\SYSVOL\sysvol\contoso.com" "E:\SYSVOL\domain"

Get-ChildItem -LiteralPath 'E:\SYSVOL\staging areas', 'E:\SYSVOL\sysvol' -Attributes ReparsePoint |
    Select-Object FullName, Target

Both targets must resolve to the new disk. Compare them with the source targets recorded before the move, accounting for the new root.

7 - Restart the services:

Start-Service DFSR
Start-Service Netlogon
Get-SmbShare -Name SYSVOL, NETLOGON | Select-Object Name, Path

Verify both shares point into the new tree. The original version of these notes only stopped DFSR, so Start-Service Netlogon could leave an already-running Netlogon instance publishing its old paths.

There are multiple ways you can test that the change has been successful. A quick and simple approach is to create a canary file in the SYSVOL folders and ensure it is replicated to all domain controllers.

Check both directions: a file created on the moved DC reaches a partner, and a different file created on the partner reaches the moved DC. Remove both afterwards. Also check the SYSVOL and NETLOGON shares from a client; replication working doesn’t prove the shares are pointing at the right place.

A better approach, though, is to use the built-in “DFS Management” tools and run a health check.

Should you encounter any errors, be sure to start with the “DFS Replication” Event log under “Applications and Services Logs”.

References