Configuring Manual Replication (prevent auto-generated site links)

In our AD we have multiple sites. Most of them are remote offices and our
WAN is mainly a "hub and spoke" style.

In AD sites and services:
Each "spoke" has manually configured site links with each of the hub sites.
Replication flow is hub --> spoke

Each "hub" has manually configured site links with each of the other hubs
Replication flow is hub --> hub

We are not using (that is to say we've deleted) the defaultIPsitelink, and
we have disabled site link bridging on the IP transport (we are not using
SMTP).

If we delete the automatically generated site-links KCC just adds them back
to one of the hubs @ the next replication (the same hub). My guess is that
given the manual configuration, the spokes have no way to replicate changes
inbound to the hubs. Can anyone confirm this for me?

---------------------
On a separate note but related to the above issue - our logs are showing
replication failures for one of the spokes on the hub with the automatically
generated site links because it is apparently tombstoned - however repadmin
on the spoke DC shows successful inbound replication. When the auto site
links are deleted the errors go away and the directory service logs look
clean.

We'll probably try simply demoting that DC cleaning metadata with it's name
from AD and then re-promoting it to see if we can clear the errors. Any
ideas here?

Thank you all so much for your help - you all rock!

Jon,

you seem to be confusing bi-directional AD links between sites - which (with
exception of DEFAULTIPSITELINK) are created manually - and connections
between domain controllers (which can be created either manually or
automatically by ISTG/KCC) that represent inbound replication traffic. Site
links design should reflect underlying network topology (which, based on
your post, appears to be the case) - which serves as the basis for
establishing DC-to-DC communication.

ISTG recreates the connections in order to facilitate two-way replication
between hub and its spokes. Unless you have RODCs in your forest, this is
the expected behavior. Without having more info about the replication error
you are getting (what exactly is "tombstoned"?) it is rather difficult to
determine what is the problem, but deleting connections is not the way to
resolve it...

hth
Marcin

"Jon Bakersfield" <JB@blingo.chartruse.com> wrote in message
news:eUKsldhjJHA.4276@TK2MSFTNGP04.phx.gbl...
> In our AD we have multiple sites. Most of them are remote offices and our
> WAN is mainly a "hub and spoke" style.
>
> In AD sites and services:
> Each "spoke" has manually configured site links with each of the hub
> sites.
> Replication flow is hub --> spoke
>
> Each "hub" has manually configured site links with each of the other hubs
> Replication flow is hub --> hub
>
> We are not using (that is to say we've deleted) the defaultIPsitelink, and
> we have disabled site link bridging on the IP transport (we are not using
> SMTP).
>
> If we delete the automatically generated site-links KCC just adds them
> back
> to one of the hubs @ the next replication (the same hub). My guess is
> that
> given the manual configuration, the spokes have no way to replicate
> changes
> inbound to the hubs. Can anyone confirm this for me?
>
> ---------------------
> On a separate note but related to the above issue - our logs are showing
> replication failures for one of the spokes on the hub with the
> automatically
> generated site links because it is apparently tombstoned - however
> repadmin
> on the spoke DC shows successful inbound replication. When the auto site
> links are deleted the errors go away and the directory service logs look
> clean.
>
> We'll probably try simply demoting that DC cleaning metadata with it's
> name
> from AD and then re-promoting it to see if we can clear the errors. Any
> ideas here?
>
> Thank you all so much for your help - you all rock!
>
>

Marcin,

Thank you so much for your reply.

After reading my own post I can understand the confusion I may have created
between site-links and replication links.

All of our site-links are manually defined. For spokes the site-link
contains the local site and the sites of all of the hubs. For the hubs the
link contains every site.

As for the replication links they are also manually defined, but because of
the way these were defined the spoke sites were not able to replicate
changes inbound. Every manually defined link here was FROM a hub TO a
spoke, but never the opposite. In an effort to prevent automatically
generated replication links, we followed a whitepaper describing the removal
of the defaultIPSitelink and disabling site-link bridging. This only
worsened the island effect created by the missing inbound replication links
for the spokes.

We have corrected the inbound link issue and hope not to have any more
auto-generated replication links. I'll be able to tell you next week.

As for the 'suspected' tombstoned DC - we moved it's inbound replication to
a specific server and saw tombstone errors on that server (they previously
only showed up on the DC where the automatically-generated replication links
appeared). This told us that the DC is in fact tombstoned and that we will
need to proceed with the demotion, cleaning of metadata, and re-promotion.

Hope that clears things up a bit.

Thanks again!!




"Marcin" <marcin@community.nospam> wrote in message
news:%23hmYN1ijJHA.5812@TK2MSFTNGP06.phx.gbl...
> Jon,
>
> you seem to be confusing bi-directional AD links between sites - which
(with
> exception of DEFAULTIPSITELINK) are created manually - and connections
> between domain controllers (which can be created either manually or
> automatically by ISTG/KCC) that represent inbound replication traffic.
Site
> links design should reflect underlying network topology (which, based on
> your post, appears to be the case) - which serves as the basis for
> establishing DC-to-DC communication.
>
> ISTG recreates the connections in order to facilitate two-way replication
> between hub and its spokes. Unless you have RODCs in your forest, this is
> the expected behavior. Without having more info about the replication
error
> you are getting (what exactly is "tombstoned"?) it is rather difficult to
> determine what is the problem, but deleting connections is not the way to
> resolve it...
>
> hth
> Marcin
>
> "Jon Bakersfield" <JB@blingo.chartruse.com> wrote in message
> news:eUKsldhjJHA.4276@TK2MSFTNGP04.phx.gbl...
> > In our AD we have multiple sites. Most of them are remote offices and
our
> > WAN is mainly a "hub and spoke" style.
> >
> > In AD sites and services:
> > Each "spoke" has manually configured site links with each of the hub
> > sites.
> > Replication flow is hub --> spoke
> >
> > Each "hub" has manually configured site links with each of the other
hubs
> > Replication flow is hub --> hub
> >
> > We are not using (that is to say we've deleted) the defaultIPsitelink,
and
> > we have disabled site link bridging on the IP transport (we are not
using
> > SMTP).
> >
> > If we delete the automatically generated site-links KCC just adds them
> > back
> > to one of the hubs @ the next replication (the same hub). My guess is
> > that
> > given the manual configuration, the spokes have no way to replicate
> > changes
> > inbound to the hubs. Can anyone confirm this for me?
> >
> > ---------------------
> > On a separate note but related to the above issue - our logs are showing
> > replication failures for one of the spokes on the hub with the
> > automatically
> > generated site links because it is apparently tombstoned - however
> > repadmin
> > on the spoke DC shows successful inbound replication. When the auto
site
> > links are deleted the errors go away and the directory service logs look
> > clean.
> >
> > We'll probably try simply demoting that DC cleaning metadata with it's
> > name
> > from AD and then re-promoting it to see if we can clear the errors. Any
> > ideas here?
> >
> > Thank you all so much for your help - you all rock!
> >
> >
>
>

the only thing you need to configure manually are sites, site links and
subnets and the relation between all those. The COs are and should be
maintained automatically by the KCC/ISTG. If you delete the COs, the next
time the KCC runs (5 mins after boot and then each 15 mins) on each DC it
will evaluate the replication topology and act upon it. If it thinks it
needs to create COs, it will

investigate the replication failures. If you do not act upon it and resolve
in the end you will have more issues like lingering objects!

go to my blog (http://blogs.dirteam.com/blogs/jorge/default.aspx) and search
for "lingering"

--

Cheers,
(HOPEFULLY THIS INFORMATION HELPS YOU!)

# Jorge de Almeida Pinto # MVP Identity & Access - Directory Services #

BLOG (WEB-BASED)--> http://blogs.dirteam.com/blogs/jorge/default.aspx
BLOG (RSS-FEEDS)--> http://blogs.dirteam.com/blogs/jorge/rss.aspx
------------------------------------------------------------------------------------------
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always test ANY suggestion in a test environment before implementing!
------------------------------------------------------------------------------------------
#################################################
#################################################
------------------------------------------------------------------------------------------

"Jon Bakersfield" <JB@blingo.chartruse.com> wrote in message
news:eUKsldhjJHA.4276@TK2MSFTNGP04.phx.gbl...
> In our AD we have multiple sites. Most of them are remote offices and our
> WAN is mainly a "hub and spoke" style.
>
> In AD sites and services:
> Each "spoke" has manually configured site links with each of the hub
> sites.
> Replication flow is hub --> spoke
>
> Each "hub" has manually configured site links with each of the other hubs
> Replication flow is hub --> hub
>
> We are not using (that is to say we've deleted) the defaultIPsitelink, and
> we have disabled site link bridging on the IP transport (we are not using
> SMTP).
>
> If we delete the automatically generated site-links KCC just adds them
> back
> to one of the hubs @ the next replication (the same hub). My guess is
> that
> given the manual configuration, the spokes have no way to replicate
> changes
> inbound to the hubs. Can anyone confirm this for me?
>
> ---------------------
> On a separate note but related to the above issue - our logs are showing
> replication failures for one of the spokes on the hub with the
> automatically
> generated site links because it is apparently tombstoned - however
> repadmin
> on the spoke DC shows successful inbound replication. When the auto site
> links are deleted the errors go away and the directory service logs look
> clean.
>
> We'll probably try simply demoting that DC cleaning metadata with it's
> name
> from AD and then re-promoting it to see if we can clear the errors. Any
> ideas here?
>
> Thank you all so much for your help - you all rock!
>
>

Manually created KCC links are bad practices for active directory, if your
replication is crapping out you need to find out and fix the replication
problems, one by one and leave KCC to handle replication connections
automatically.
Replication may not work for several reasons and needs investigation, most
problems I have seen in hub & Spoke large AD environment. The major problem
with many large organization they don’t monitory AD and its health also
functions (replication, database maintenance etc)

1. Being late on hardware and OS refresh
2. Mis-configured DNS
3. Novice network administrators
4. Not monitoring lingered objects
5. .Dit database is much bigger on the site DC’s ( monitoring AD is not in
place)
6. Due to not having enough resources on the local DC (CPU,Mem,I/O) Lsas.exe

It takes time and afford to clean all out, but I have seen horrible
replication turning into flawless in a very large hub& Spoke environment. If
your company can effort, you may look into bringing Microsoft to perform
ADRap for you ( MS finds out all the problems and gives you report,
explaining how to fix it). It might well worth for the business, but remember
good things comes with a good coast as always $$$$ (-:

Good Luck,

--oz

--
Oz Ozugurlu
MVP (Exchange)
MCITP (EMA), MCITP (EA),MCITP (SA)
MCSE 2003, M+, S+, MCDST
Security+, Project +, Server +

oz@SMTp25.org
http://smtp25.blogspot.com
http://telnet25.wordpress.com


"Jon Bakersfield" wrote:

> In our AD we have multiple sites. Most of them are remote offices and our
> WAN is mainly a "hub and spoke" style.
>
> In AD sites and services:
> Each "spoke" has manually configured site links with each of the hub sites.
> Replication flow is hub --> spoke
>
> Each "hub" has manually configured site links with each of the other hubs
> Replication flow is hub --> hub
>
> We are not using (that is to say we've deleted) the defaultIPsitelink, and
> we have disabled site link bridging on the IP transport (we are not using
> SMTP).
>
> If we delete the automatically generated site-links KCC just adds them back
> to one of the hubs @ the next replication (the same hub). My guess is that
> given the manual configuration, the spokes have no way to replicate changes
> inbound to the hubs. Can anyone confirm this for me?
>
> ---------------------
> On a separate note but related to the above issue - our logs are showing
> replication failures for one of the spokes on the hub with the automatically
> generated site links because it is apparently tombstoned - however repadmin
> on the spoke DC shows successful inbound replication. When the auto site
> links are deleted the errors go away and the directory service logs look
> clean.
>
> We'll probably try simply demoting that DC cleaning metadata with it's name
> from AD and then re-promoting it to see if we can clear the errors. Any
> ideas here?
>
> Thank you all so much for your help - you all rock!
>
>
>