Replication problems, site links/bridges and routed WAN IP

  • Thread starter Thread starter David Halstead
  • Start date Start date
D

David Halstead

Replication problems, site links/bridges and routed WAN IP

The network setup
-----------------
HQ (192.168.1.0/24) is the centre of a star configuration.
Office A (192.168.2.0/24) is connected to HQ via a VPN.
Office B (192.168.3.0/24) is connected to HQ via a VPN.
Office C (192.168.4.0/24) is connected to HQ via a VPN.

There NO IP routing from one office to another - they're completely
blind to one another's existence on a network level.

AD information
--------------
One server per location. The server is a DC and a DNS server. A GC
is on each DC. One site, with one subnet, per location defined within
AD. Each server sits in their respective site.

What works
----------
Replication between HQ and Office A.
Replication between HQ and Office B.
Replication between HQ and Office C.

What doesn't
------------
Apparently, replication from one Office to another. Multiple errors
are listed in the Directory Service Event Log every 15 minutes, on
each Office server, reporting Error ID's 1566, 1311, 1925 and 1865.
The source of these errors is the NTDS KCC. These errors refer to
replication from Office to Office, never from Office to HQ. I say
'apparently' because a modification to the AD made in one Office does,
ultimately, filter through to the other offices. This can, however,
take many hours, sometimes several days.

What's been tried
-----------------
The errors above occurred with the default configuration. Since then:

1. On the Inter-site transports -> IP properties, "Bridge all site
links" has been unticked.
2. A specific HQ to Office site link has been defined, one for each HQ
to Office link. Appropriate costs (specifically 485) have been
entered to reflect the speed of the link. DEFAULTIPSITELINK
(subsequently renamed) is one of the Office to HQ links. No more than
two sites are defined in a link.
3. A site link bridge has been defined from Office A to Office C. We
expected this bridge would reduce the number of errors generated on
servers A and C.

After each of these steps, there was no improvement. Then we:

4. Deleted all NTDS connections, then created a single Office 'x' to
HQ connection. Specifically no Office 'x' to Office 'y' connections
were created, nevertheless, auto generated NTDS connections from
Office to Office re-appeared 2 hours later!

Still no improvement - same number of replication errors every 15
minutes.

Questions
---------
Will error free replication only occur on a fully routed WAN, whereby
all locations HAVE to see each other on a network level?
If you don't need a fully routed WAN for replication to succeed, what
the heck have we missed?

Your help VERY MUCH appreciated. Thank you.
 
If this is a 1 domain environment, please double check your site link
configuration.
You should have exactly 3 site links with IP transports:
site-link-hq-a connecting hq and a
site-link-hq-b connecting hq and b
site-link-hq-c connecting hq and c

Once you've made the change on a DC, the 1311's & 1856's should no longer
appear when the KCC next runs (every 15 minutes). If replication is
currently broken, you may need to temporarily force replication in order to
get this change propagated to the 3 other DC's.
 
We are indeed a one domain environment.

With your comment of "You should have exactly 3 site links with IP
transports:", we subsequently removed the site link bridge between
Office A and Office C. I can confirm that there were, and still are,
only three site links defined, namely HQ to A, HQ to B and HQ to C.

Removing the site link bridge made no improvement.

We even re-checked "Bridge all link sites" in the vain hope this might
help. As you'd expect, it didn't.

Any further ideas about what on Earth is going on? It's incredibly
frustrating for such a simple setup as this to have so many
replication problems.

Thanks again for taking your time to look at this.
 
Please make sure that there are no site links bridges, and that the "bridge
all site links" option is not checked. Both of these will cause the problem,
because the KCC will think that it can create connections directly between
your branch sites (which don't have direct connectivity).

Once this is done, you'll need to wait until KCC creates a new logical
topology, (you can verify this via the output of repadmin /showconn <DC>
/intersite) and replication is attempted. This should fix the problem on the
DC where the changes were made.

--
Ajit Krishnan
AD Replication
This posting is provided "AS IS" with no warranties, and confers no rights.



David Halstead said:
We are indeed a one domain environment.

With your comment of "You should have exactly 3 site links with IP
transports:", we subsequently removed the site link bridge between
Office A and Office C. I can confirm that there were, and still are,
only three site links defined, namely HQ to A, HQ to B and HQ to C.

Removing the site link bridge made no improvement.

We even re-checked "Bridge all link sites" in the vain hope this might
help. As you'd expect, it didn't.

Any further ideas about what on Earth is going on? It's incredibly
frustrating for such a simple setup as this to have so many
replication problems.

Thanks again for taking your time to look at this.

"Ajit Krishnan [MSFT]" <[email protected]> wrote in message
If this is a 1 domain environment, please double check your site link
configuration.
You should have exactly 3 site links with IP transports:
site-link-hq-a connecting hq and a
site-link-hq-b connecting hq and b
site-link-hq-c connecting hq and c

Once you've made the change on a DC, the 1311's & 1856's should no longer
appear when the KCC next runs (every 15 minutes). If replication is
currently broken, you may need to temporarily force replication in order to
get this change propagated to the 3 other DC's.
Click to expand...
Click to expand...
 
Back
Top