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" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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]" <(E-Mail Removed)> wrote in message
news:<(E-Mail Removed)>...
> > 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.
> >
> > --
> > Ajit Krishnan
> > AD Replication
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> >
> >
> >
> > "David Halstead" <(E-Mail Removed)> wrote in message
> > news:(E-Mail Removed)...
> > > 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.
|