FRS Event ID 13508: SYSVOL still on File Replication Service and unsupported

Fix it now

Event 13508 is the File Replication Service reporting that it is having trouble enabling replication with a partner and will keep retrying. Clear the immediate fault, then deal with the real problem: Microsoft states that Windows Server 2016 is the last release that supports FRS, and that domains must use DFS Replication for SYSVOL.

dfsrmig /getglobalstate
dcdiag /test:FrsEvent
nslookup <partner-fqdn>
Test-NetConnection <partner-fqdn> -Port 135

1. If dfsrmig /getglobalstate reports the start state, SYSVOL is still on FRS whatever release the domain controllers run.
2. Clear the immediate fault first: the partner must resolve by its fully qualified name, answer on TCP 135, and be running the File Replication Service. A following Event 13509 confirms replication finally started.
3. Confirm every domain controller can run DFS Replication, then start the migration from the PDC emulator with dfsrmig /setglobalstate 1 and wait for dfsrmig /getmigrationstate to report every DC prepared.
4. Repeat with /setglobalstate 2, confirm again, then finish with /setglobalstate 3.

Microsoft states that after you migrate to DFS Replication you cannot revert to FRS. The prepared and redirected states are reversible; the eliminated state is not.

If 13509 follows the 13508 and the migration completes, you are done. If not, the next section covers why FRS faults so rarely clear themselves.

Why it happens

Microsoft publishes 13508 as a warning: the File Replication Service is having trouble enabling replication from one machine to another for a replica set, using a named DNS name, and will keep retrying. The retrying is the trap. FRS does not escalate and does not give up, so the same warning can sit in a log for years while the domain quietly diverges. The companion is 13509, which Microsoft publishes as the service having enabled replication after repeated retries. A 13508 with no matching 13509 means replication never started.

The immediate causes are ordinary: the partner does not resolve, the service is not running there, RPC is blocked, or the directory has not replicated the FRS connection objects yet. Any of those clears with the same checks you would run on any other RPC application. What does not clear so easily is the position the domain is in.

Microsoft’s functional level documentation states that domains must use DFS Replication as the engine to replicate SYSVOL, and that Windows Server 2016 is the last Windows Server release that supports the File Replication Service. That is not a recommendation about features. It is the reason an estate still on FRS stays frozen: the supported replication engine for SYSVOL on current Windows Server is DFS Replication, and getting there is a staged migration you run once.

The other reason to move is how FRS fails. A change journal wrap stops the replica set outright, and the documented repair is a registry value that tells the service to rebuild either from a partner or from its own copy. Setting that value the wrong way round publishes the wrong copy of SYSVOL to the whole domain. DFS Replication replaces that with a per-file version vector database and a recovery path that does not hinge on one hexadecimal digit.

Full reference

The FRS events, as Microsoft publishes them

The migration, state by state

Microsoft states that after you migrate to DFS Replication you cannot revert to FRS. Reach the prepared state, confirm every domain controller has got there, and only then move on. The eliminated state is the one-way door.

The BurFlags decision, spelled out

This is the step that turns a single failed domain controller into a domain-wide incident, so it is worth being slow about. The value lives under the NtFrs parameters key, in the Backup/Restore branch, under Process at Startup, and is named BurFlags. Microsoft documents two values: D2 for a nonauthoritative restore, and D4 for an authoritative one. Nonauthoritative means this machine discards what it has and takes a copy from a partner. Authoritative means the opposite, and it is the correct choice only when this machine holds the copy of SYSVOL you want everybody else to have.

1. Export the NtFrs key and take a copy of the Policies and Scripts folders from a domain controller you trust.
2. Decide, out loud, which direction you are rebuilding in.
3. net stop ntfrs, set BurFlags, net start ntfrs.
4. Confirm SYSVOL and NETLOGON are shared, and that a policy edit reaches a client.
5. Leave the Pre-existing folder alone until you are certain. Microsoft describes it as a safeguard designed to prevent accidental data loss, and says to delete its contents once outbound replication has occurred.

Where the supported line falls

Read that table alongside the SYSVOL rule and the shape of the work becomes clear. The engine has to be DFS Replication, the last release that supports FRS is Windows Server 2016, and the newest domain controllers will not sit at the oldest functional level. Anything on the estate that cannot reach the DFS Replication side of that line is a replacement rather than a repair.

Checking your own work

• dcdiag /test:FrsEvent checks for errors in the File Replication Service event log from the past 24 hours; run it before and after.
• dcdiag /test:SysVolCheck reads the Netlogon SysVolReady value. Microsoft notes that it does not check whether the shares are accessible, so pair it with dcdiag /test:NetLogons.
• dcdiag /test:Advertising confirms the DC is advertising the roles it should. Microsoft notes it fails if Netlogon has stopped, and that it can still pass when TCP and UDP 88 are blocked.
• After the migration, run dcdiag /test:DFSREvent instead of FrsEvent. Different engine, different log.

Every code this article covers

Confirm the fix worked

1. dfsrmig /getmigrationstate reports every domain controller at the eliminated state.
2. net share on every DC lists SYSVOL and NETLOGON.
3. dcdiag /test:NetLogons succeeds, which proves the shares are readable rather than merely marked ready.
4. dcdiag /test:DFSREvent reports no errors in the last 24 hours on any domain controller.
5. A policy change made on one DC reaches a client in another site.

Questions people ask about this