AD Forest replication Question

[Guest]

I am building a multi domain forest in a lab to test the Ad design for a
Win2K3 environment.

The proposed design includes a domain at head office and each of the 6
branch offices. The reason for multi domains is that the branch offices are
primarily in third world countries with poor network stability. We wanted
standard functions like password resets to be contained locally and not be
dependent on replication. We also wanted to reduce replication traffic on
the WAN by scheduling replication only during low usage windows. The
organization is small. 300 users at head office and less than 50 at each
branch office. So the AD "churn" should be minimal.

My question.

In the Lab I have set up Head office and a couple of branch offices each
with thier own domain as part of a single forest
with 2 Win2K3 DCs in each domain. Each domian is on a seperate IP subnet
connected via a router. I have created sites for each and assigned the IP
subnet and servers accordingly. I have read that the KCC automatically does
a all sites to all sites replication topology. I want to control the
replication traffic between sites so I can schedule it during low network
useage windows and I also want to reduce the replication connections to
minimize the load on the WAN. Do I have to delete the "automatically
generated" connections and build my own? What if potential problems are there
by doing this?

Comments welcome.

Chandlar

 

[Herb Martin]

I am building a multi domain forest in a lab to test the Ad design for a
Win2K3 environment.

The proposed design includes a domain at head office and each of the 6
branch offices. The reason for multi domains is that the branch offices are
primarily in third world countries with poor network stability.

This may be a reason -- depends on how poor,
and poor in what way ("latency and noise" are
much worse than "slow".)

As for slow, small domains don't argue for this.

We wanted
standard functions like password resets to be contained locally and not be
dependent on replication.

They are not with a single domain if performed properly
-- there may be reasons for multiple domains, that isn't
one of them.

We also wanted to reduce replication traffic on
the WAN by scheduling replication only during low usage windows.

That can be done with either one or several domains,
so depending on how large your user base this may
be a reason.

The
organization is small. 300 users at head office and less than 50 at each
branch office. So the AD "churn" should be minimal.

This argues for a single domain. You will not
have bandwidth problems unless your WANS
are already swamped OR you really have those
latency and noise problems but with this size
forest you will have almost as many problems
with multiple domains.

My question.

In the Lab I have set up Head office and a couple of branch offices each
with thier own domain as part of a single forest
with 2 Win2K3 DCs in each domain. Each domian is on a seperate IP subnet
connected via a router. I have created sites for each and assigned the IP
subnet and servers accordingly. I have read that the KCC automatically does
a all sites to all sites replication topology.

Yes. If your sites are a fully connected net (i.e.,
no island sites without site links.)

I want to control the
replication traffic between sites so I can schedule it during low network
useage windows

That works for either single or multiple domains.

On each site link you have the "Hours of Replication"
aka "Schedule".

Also frequency is there.

and I also want to reduce the replication connections to
minimize the load on the WAN.

That is already done by AD and the KCC -- by default
each Site will get one DC in the domain which does the
replication offsite for that domain.

One DC/GC in each site will also do this for forest wide
purposes -- but generally these will be the same DC/GC
if you only have one domain in a site.

Do I have to delete the "automatically
generated" connections and build my own?
No.

What if potential problems are there
by doing this?

It's more work and if you mess it up the KCC cannot
necessarily override your decisions.

If the KCC gets it right, then leave it alone. Otherwise
you CAN change it if you MUST, and if you know what
you are doing (seldom necessary.)

 

[Guest]

The first thing you need to do is uncheck the option to bridge all site links
on the IP properties in dssite.msc.

With that done, the KCCs won't create a transitive mesh.

You can then either ititiate the KCCs and see what they do, or you can
define preferred bridgehead servers for each site. If you don't define
bridgehead servers, the KCCs will do this for you (the ISTG actually). This
is better, as the KCCs will then fail-over to another box should this one be
available. If you configure your own, the replication topology will be built
around this and the failover (15 mins - each time the KCC runs) won't happen.

If the topology generated isn't optimal, you should delete all connection
objects and start the KCCs off again. If you're still unhappy, you'll have
to define preferred bridgeheads.

You can 'coerce' the KCCs into forming a certain topology based on the site
links that you use and the costs you associate with them.

Try a few of these options in your lab, and see which benefits you...


--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

 

[Guest]

Thanks Paul.

My thinking about this was to use the head office as a central hub for AD
replication. Again the forest wide replication should be small and domain
specific replication headed to GCs should be pretty minimal once the
environment is stable. I thought of creating a site link from each branch
office to the head office as the primary replication path and a backup with a
higher path cost to another branch office selected based on network latency
and bandwidth in case HO drops off the net. From what your saying I disable
"fully meshed" and then create the specific site links I want and let the KCC
do the rest?

I am just making it too complicated ? I almost think from what you say that
I should let the KCC figure it out and than manipulate the path costs on the
various links to manage the traffic. That way I can have what I want but
keep it simple .

Correct ?

Thanks

Chandlar

 

[Guest]

Thanks Herb.


I thought that functions like user add, change or delete generated immediate
replication to all DCs in the domain. This was part of the thinking in the
mutli domain decision. The network links have high latancy(some as high as
2000ms), lots of noise and can come and go frequently for a variety of
durations. Again some of the thinking around mutilple domains.

I understand that the Site/ Replication topology is domain design
independant but I did not want replication happening from each branch office
to every other branch office plus head office. My thinking was to set up a
sute link from each regional office to the head office as a primary path for
replication and then buils a second path to the most logical nieghbor(based
on net latency and BW) branch office and assign path costs so the replication
would happen from HO to Branch1 then HO to Branch2 etc. A hub replication
model. Perhaps Ishould let the KCC build it all and just manipulate the path
costs and replication schedules ?

Thansk.

Chandlar

 

[Herb Martin]

Thanks Herb.


I thought that functions like user add, change or delete generated immediate
replication to all DCs in the domain.

But such cannot cross site boundaries until the
Schedule opens up.

The trick is to get the local admins to add the
users or update passwords on a local DC, so
that the results are almost immediately effective,
and the full replication takes place when allowed.

This was part of the thinking in the
mutli domain decision. The network links have high latancy(some as high as
2000ms), lots of noise and can come and go frequently for a variety of
durations. Again some of the thinking around mutilple domains.

This is going to be true for GC replication (which is
forest wide) too, and recognize with only 300 users
it's probably isn't that big a difference, Domain or
just GC replication.

I understand that the Site/ Replication topology is domain design
independant but I did not want replication happening from each branch office
to every other branch office plus head office.

Then you don't build the links that way but use a
hub-spoke type design (or whatever your WAN
looks like is probably best.)

You can (as pt detailed) also set it so that if the
central (intermediate) DCs are all down that the
links will NOT be used transitively, but that is
choice seldom needed.

My thinking was to set up a
sute link from each regional office to the head office as a primary path for
replication and then buils a second path to the most logical nieghbor(based
on net latency and BW)

branch office and assign path costs so the replication
would happen from HO to Branch1 then HO to Branch2 etc. A hub replication
model.

And if you set the SiteLink costs correctly that
will work (just) fine with or without the full
(default) SiteLinkBridge-GROUPING.

Perhaps Ishould let the KCC build it all and just manipulate the path
costs and replication schedules ?

Yes, and you can tune it if necessary with manual
connections or by messing with SiteLinkBridge-GROUPING

Biggest issue is the Latency-Noise but that is going to
affect a forest also so testing should start early.

 

[ptwilliams]

Answers inline.

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

Thanks Paul.

My thinking about this was to use the head office as a central hub for AD
replication. Again the forest wide replication should be small and domain
specific replication headed to GCs should be pretty minimal once the
environment is stable. I thought of creating a site link from each branch
office to the head office as the primary replication path and a backup with
a
higher path cost to another branch office selected based on network latency
and bandwidth in case HO drops off the net. From what your saying I disable
"fully meshed" and then create the specific site links I want and let the
KCC
do the rest?

Paul > Yep. That's how I've always done it with low-speed links. Let the
KCCs do what they're best at, and you joast coerce their way of thinking
;-)

I am just making it too complicated ? I almost think from what you say that
I should let the KCC figure it out and than manipulate the path costs on the
various links to manage the traffic. That way I can have what I want but
keep it simple .

Paul > Yep, exactly. You're not making to complicated either.

Please also take heed of Herb's advice -that guy really knows what he's
talking about...


Correct ?

Thanks

Chandlar

 

[Guest]

Thanks Herb. Good stuff.

Chandlar

But such cannot cross site boundaries until the
Schedule opens up.

The trick is to get the local admins to add the
users or update passwords on a local DC, so
that the results are almost immediately effective,
and the full replication takes place when allowed.


This is going to be true for GC replication (which is
forest wide) too, and recognize with only 300 users
it's probably isn't that big a difference, Domain or
just GC replication.


Then you don't build the links that way but use a
hub-spoke type design (or whatever your WAN
looks like is probably best.)

You can (as pt detailed) also set it so that if the
central (intermediate) DCs are all down that the
links will NOT be used transitively, but that is
choice seldom needed.



And if you set the SiteLink costs correctly that
will work (just) fine with or without the full
(default) SiteLinkBridge-GROUPING.



Yes, and you can tune it if necessary with manual
connections or by messing with SiteLinkBridge-GROUPING

Biggest issue is the Latency-Noise but that is going to
affect a forest also so testing should start early.

 

[Guest]

Thanks Paul.

Chandlar

Answers inline.

--

Paul Williams

http://www.msresource.net/
http://forums.msresource.net/

Thanks Paul.

My thinking about this was to use the head office as a central hub for AD
replication. Again the forest wide replication should be small and domain
specific replication headed to GCs should be pretty minimal once the
environment is stable. I thought of creating a site link from each branch
office to the head office as the primary replication path and a backup with
a
higher path cost to another branch office selected based on network latency
and bandwidth in case HO drops off the net. From what your saying I disable
"fully meshed" and then create the specific site links I want and let the
KCC
do the rest?



I am just making it too complicated ? I almost think from what you say that
I should let the KCC figure it out and than manipulate the path costs on the
various links to manage the traffic. That way I can have what I want but
keep it simple .


Please also take heed of Herb's advice -that guy really knows what he's
talking about...


Correct ?

Thanks

Chandlar

 

[ptwilliams]

No problem!!!


--

Paul Williams

http://www.msresource.net
http://forums.msresource.net


Thanks Paul.

Chandlar