Event ID 1311 KCC errors: site links that cannot build a working topology

Fix it now

Event ID 1311 says the consistency checker has decided one of two things: there is not enough physical connectivity published in Sites and Services to build a spanning tree connecting all the sites holding that partition, or replication cannot be performed with one or more critical servers. Work out which before changing any site link.

repadmin /showism
repadmin /showreps
repadmin /failcache
dcdiag /test:intersite /e /q
dcdiag /test:connectivity /e /q

1. Read repadmin /showism first. It prints the site connectivity matrix for the transport as cost : replication interval : options, and an entry of -1:0:0 marks a site the transport cannot reach.
2. A site showing -1:0:0 is either not in a site link, hosts no domain controllers, or does not use that replication protocol. Those are three different fixes.
3. Check whether Bridge all site links is selected on the IP transport, and whether your network really is fully routed. If it is enabled on a network that is not fully routed, either make the network routed or turn bridging off and model the routing with site link bridge objects.
4. Look for preferred bridgeheads that should not be there: in Sites and Services, open the domain controller’s properties and check the General tab for “The server is a preferred bridgehead server for the following transports”. Remove the assignment unless you have a firewall reason for it.
5. After any change, wait two times the longest replication interval in the forest before deciding whether it worked.

That waiting period is the step people skip, and it is why so many of these get declared unfixed and then changed again. The topology does not converge instantly.

If 1311 stops appearing after two cycles, you are done. The next section explains what the KCC is working from and the nine documented reasons it gives up.

Why it happens

The KCC runs on every domain controller and builds the connection objects that drive replication inside a site. One DC per site additionally holds the intersite topology generator role and builds the connections that cross site boundaries. Both work purely from what is written in the Configuration partition: sites, subnets, site links, site link bridges and bridgehead assignments. Neither discovers anything about your network by observation.

Event 1311’s own wording carries the ambiguity you have to resolve. It says the consistency checker has determined that either there is not enough physical connectivity published via Active Directory Sites and Services Manager to create a spanning tree connecting all the sites containing the partition, or replication cannot be performed with one or more critical servers, most often because the servers are unreachable. Those are a design problem and a server problem, and they need completely different work.

Those last four are the ones that catch people, because in all of them the topology on paper is fine. A preferred bridgehead that does not host the partition being replicated is a working server that cannot do the job it has been nominated for, and nothing in Sites and Services flags it.

Full reference

Reading repadmin /showism

This is the single most useful command for a 1311 and it is the one most articles omit. It prints the site connectivity matrix for a transport, with each entry in the form cost : replication interval : options.

A -1:0:0 has three documented readings: the replication protocol is not used, the site hosts no domain controllers and is therefore uncovered, or the site is not included in a site link. Establish which one before changing anything, because adding a site link to a site that has no DCs in it fixes nothing.

The nine documented causes

1. Site link bridging enabled on a network that does not support connectivity between two DCs in different sites.
2. One or more sites not contained in any site link.
3. Site links containing all sites, but not interconnected: disjoint site links.
4. One or more domain controllers offline.
5. Bridgehead DCs online, but hitting errors replicating a required naming context between sites.
6. Administrator-defined preferred bridgeheads online, but not hosting the required naming contexts.
7. Preferred bridgeheads defined correctly but currently offline.
8. A bridgehead server that is overloaded: undersized, serving too many branch sites from the same hub DC, or with site link schedules set too frequent.
9. The KCC in keep-connection mode, having routed around a site-to-site failure and retrying the failing connection every fifteen minutes.

Commands and where they take you

Preferred bridgeheads, and why to have none

A manually nominated bridgehead server takes the choice away from the intersite topology generator and does not fail over. Three of Microsoft’s nine causes involve them: nominated but not hosting the required naming contexts, nominated correctly but offline, and nominated onto a server that is overloaded. Unless there is a firewall reason that requires one specific server to carry intersite traffic, remove the assignment and let the topology generator choose. If you must pin one, pin a server that holds every partition which has to cross that link, and pin a second so there is a fallback.

Waiting properly

Microsoft’s guidance after a topology change is to wait two times the longest replication interval in the forest, or two times the maximum replication interval after removing a bridgehead assignment. That is not padding. A change to the Configuration partition has to replicate to the DCs that will act on it, and those DCs then have to run their own calculation. Judging a change before that has happened produces a second change, and then a third, and the eventual topology is nobody’s design.

Three event IDs this article does not define

Event ID 1308, Event ID 1566 and Event ID 1865 are all quoted in KCC troubleshooting, respectively as repeated replication failures to a named directory service, a site whose DCs are all unavailable for a partition and transport, and an incomplete spanning tree. Microsoft does not publish those meanings in a place this article could point you at, so they are recorded as unpublished below. Read them on your own DCs if they are there. repadmin /showism gives you the spanning tree question directly, and repadmin /failcache gives you the failing-connection question, and both are documented.

Nothing in this article requires a product, a licence or a support contract. Site topology is configuration you already own, and every command above ships with Windows Server or the remote administration tools.

Every code this article covers

Confirm the fix worked

1. repadmin /showism shows no -1:0:0 entries for sites that should be reachable over that transport.
2. No new 1311 entries appear on the intersite topology generator DCs after two times the longest replication interval.
3. dcdiag /test:intersite /e /q and dcdiag /test:connectivity /e /q both pass.
4. repadmin /showreps shows no partner with an “at never” status.
5. Every site appears in at least one site link, and every network prefix in use has a subnet object assigned to the right site.

Questions people ask about this