DFSR Event ID 5002: SYSVOL partners cannot hold an RPC session open

Fix it now

DFS Replication hit an error talking to a named partner over RPC. The entry carries the partner name, its address and an error code, and that code is the diagnosis: reach the partner on TCP 135 and the dynamic range, then confirm authenticated RPC works between the two computer accounts.

Test-NetConnection <partner-fqdn> -Port 135
nslookup <partner-fqdn>
dcdiag /test:DFSREvent
dcdiag /test:NetLogons
w32tm /query /status

1. Open the DFS Replication log and read the error code and string inside the 5002 entry. Microsoft’s worked example of the neighbouring 5008 carries Error 1722, the RPC server is unavailable, which is what a blocked path looks like from here.
2. If TCP 135 answers but replication never starts, the RPC dynamic range is the suspect. Microsoft’s port list gives DFS Replication as TCP 135 plus a random high port between 49152 and 65535, with a further entry on TCP 57222.
3. If the error is an access or authentication failure, compare the two clocks and confirm both computer accounts are healthy before touching the network.
4. Once the path is open, make both members re-read their configuration with dfsrdiag PollAD, then watch for Event ID 5004 against that partner.

Restarting the DFS Replication service re-establishes sessions and re-reads configuration. It does not open a firewall, fix DNS or correct a clock, so do it last rather than first.

If 5004 appears and the backlog drains, you are done. If not, the next section separates the four events that look identical in a log and point in different directions.

Why it happens

DFS Replication is a remote procedure call application. Each member contacts the endpoint mapper on TCP 135 on its partner, is handed a dynamically allocated port, and holds a session open over it. Microsoft’s own service and port requirements list DFS Replication as TCP 135 plus a randomly allocated high port in the 49152 to 65535 range, with an additional entry on TCP 57222. Authentication is between the two computer accounts, so a working connection needs name resolution, an open path, clocks close enough for Kerberos, and healthy machine accounts.

Event 5002 is the general failure of that conversation. Microsoft publishes it as EVENT_DFSR_CONNECTION_ERROR, “The DFS Replication service encountered an error communicating with the partner member”, and the entry carries the replication group, the partner’s full and short names, its IP address, and an implementation-specific error code and string. That last pair is the part worth reading. Everything else in the entry tells you where; only the status tells you why.

The neighbours divide the space. 5008 is published as the partner being unreachable or the DFS Replication service not running there, and Microsoft’s own example of it carries Error 1722. 5012 is the partner not recognising the connection or the replication group configuration, which is a directory problem rather than a network one. 6016 is different in kind and is the one most often misread: it is DFS Replication failing to write its own configuration back into Active Directory, not a partner event at all.

Full reference

What each event actually says

Ports, from Microsoft’s own list

Tests worth running before you change anything

SysVolCheck and NetLogons are easy to confuse and they answer different questions. Microsoft states plainly that SysVolCheck reads a registry value and does not test share access, so a passing SysVolCheck on a DC whose SYSVOL share is unreadable is not a contradiction.

When the path is open and it still fails

• Confirm the partner is a member of the replication group you think it is. A connection removed on one side and left on the other produces a steady 5012 that no firewall change will clear.
• Check whether the service on the partner is running at all. Microsoft’s published meaning for 5008 names that case explicitly.
• On a newly promoted domain controller, look for 4612 and 4614 instead. Microsoft documents a promotion in which SYSVOL never finished initial replication because the seeding partner named in the registry could not be reached, and the DC then refuses to advertise.
• Look at what else on the box holds RPC. A security product that intercepts or proxies RPC between servers produces this event with no firewall rule to find.
• If several members fail at once and nobody touched the network, look at the directory rather than the wire.

The seeding partner on a new domain controller

Microsoft documents a specific failure on a freshly promoted DC where SYSVOL replication never starts because the parent computer recorded for the seeding operation is unreachable. The value lives under the DFSR parameters key, in the SysVols branch, under Seeding SysVols for the domain, as a Parent Computer value naming the source DC. The documented fixes are to repair name resolution or connectivity to that machine, or to point the value at an available source domain controller. If your 5002 or 5008 is on a DC that has never once served SYSVOL, check there before anything else.

Reading a backlog rather than guessing

A replication group that is failing and a replication group that is merely slow look the same from the event log. The DFS Replication diagnostic tool reports the number of files waiting to move between a named sending and receiving member, and a backlog that falls after you make a change is the only evidence that matters. Take a reading before you touch anything, so that the second reading means something.

Every code this article covers

Confirm the fix worked

1. Event ID 5004 appears in the DFS Replication log for the partner that was failing.
2. Test-NetConnection <partner> -Port 135 returns true from the failing member’s own subnet.
3. dcdiag /test:DFSREvent reports no DFS Replication errors or warnings in the last 24 hours.
4. dcdiag /test:NetLogons succeeds, which proves the SYSVOL and NETLOGON shares are readable rather than merely flagged ready.
5. A policy change made on one domain controller appears on the other.

Questions people ask about this