Choice of creating a DC in a child domain or another DC in the existing domain

[Guest]

hi there,

i am the domain admin for our domain (widget.com), my first time being so
and i have to set up 2 new remote offices, across our WAN, thru a VPN created
by our netscreens.

I have my machine built, (OS is 2003 server standard edition) and have
started the required services.

I now have a choice of either:
a) creating 2 child domains (blue.widget.com and red.widget.com) and using
these new boxes as domain controllers for these child domains, or
b) just creating 2 more domain controllers in the widget.com domain.

Our WAN link to each remote office is a 2MB (soon to be reduced to a
1MB sync) sync link.
So, bandwidth wise I have enough bandwidth to allow the boxes to stay in
the main domain.

But primarily to keep each remote office operating in its own child domain,
I am thinking about creating child domains.

I realise that a flat domain, with no subdomains will be easier to manage,
but is it so difficult to manage 3/4/5 child domains?

The only reason I would go with the flat domain model, is because these
remote offices connect to our main office for mail/rdp connections/and
some filesharing.

My ultimate goal would be to deliver their mail to the DC in their office
locally, and keep a copy on my mailserver here locally.
Also having their DC auth'ing log-ons and file/print sharing is the long
term goal.

I am still thinking child domains are the way to go, but would appreciate
any advice on pitfalls, etc I may run into.

Sorry, forgot to add the 2 other DCs in the domain are both W2K server.

Could anyone comment?

tia,
bernard

--

 

[Tomasz Onyszko]

bluNOboxSPAMthief wrote:

I now have a choice of either:
a) creating 2 child domains (blue.widget.com and red.widget.com) and using
these new boxes as domain controllers for these child domains, or
b) just creating 2 more domain controllers in the widget.com domain.

Our WAN link to each remote office is a 2MB (soon to be reduced to a
1MB sync) sync link.
So, bandwidth wise I have enough bandwidth to allow the boxes to stay in
the main domain.

But primarily to keep each remote office operating in its own child domain,
I am thinking about creating child domains.

I realise that a flat domain, with no subdomains will be easier to manage,
but is it so difficult to manage 3/4/5 child domains?

I will not say that flat domain is a modle which simplify management -
it always depends on many factors, not only on the design.

The only reason I would go with the flat domain model, is because these
remote offices connect to our main office for mail/rdp connections/and
some filesharing.

This is not a design clue too, becouse when You will create the child
domains the two way trasitivie trusts between these domains and root
domain will be created and You will have access to this resources from
the child domains if proper ACLs and permissions will be deployed in the
network.

My ultimate goal would be to deliver their mail to the DC in their office
locally, and keep a copy on my mailserver here locally.

What is Your mail server? Do You want to put separate e-mail servers and
user mailboxes in the remote locations or just set the users to keep
their local mailboxes with mail on the local stations or server?

Also having their DC auth'ing log-ons and file/print sharing is the long
term goal.

Yes, but You have to look at the authentication process in Windows 2000
domain - DCs in remote offices will authenticate users but if they will
access some servers in the main office you will have some traffic
between the main office and remote offices

I am still thinking child domains are the way to go, but would appreciate
any advice on pitfalls, etc I may run into.

Sorry, forgot to add the 2 other DCs in the domain are both W2K server.

Could anyone comment?

I don't know how much users is in Your remote offices and do how is Your
network management but from what I know rght now I will recommend You to
not create child domains but put the DC's of existing domains in the
remote offices network (perfect situtation will be to have 2 DC's in
each office) - remember to make them GC, create custom replication
schema to avoid unecessery replication traffic during working hours.
This should work for You just fine.

I'm not saying that this advice is perfect and only proper way ,
please give us more information:
- how many users is in each remote locations?
- did You plan to have separate IT stuff to mange remote offices or You
will manage this from the central office ?

 

[Guest]

Hi Tomasz,

Dziekuje for your help

bluNOboxSPAMthief wrote:



I will not say that flat domain is a modle which simplify management -
it always depends on many factors, not only on the design.

This is not a design clue too, becouse when You will create the child
domains the two way trasitivie trusts between these domains and root
domain will be created and You will have access to this resources from
the child domains if proper ACLs and permissions will be deployed in the
network.

yes i understand i will have 2 way trusts with AD. thats perfect. again 90%
of the day-to-day operation of the remote offices (except for rdp connections)
can operate on their own.

What is Your mail server? Do You want to put separate e-mail servers and
user mailboxes in the remote locations or just set the users to keep
their local mailboxes with mail on the local stations or server?

our mailserver is exchange 2000. ideally i would like to receive all mail
into our main mailserver, and then send them to the remote office mailserver

eg:
*[email protected] is located in the blue remote office.
*someone sends an e-mail to (e-mail address removed)
*our main mailserver (exchange.widget.com) receiveds the mail from the sending
mailserver.
*exchange.widget.com forwards the mail to blue.widget.com DC (which is also
the mail server)

thats what i would like to work forward to. in the meantime i think i would be
happy with the remote offices connecting to the main mailserver to receive
their mail.

Yes, but You have to look at the authentication process in Windows 2000
domain - DCs in remote offices will authenticate users but if they will
access some servers in the main office you will have some traffic
between the main office and remote offices

having some traffic back to the main office is ok. they have to connect
to the main office for rdp, and other things.
i had thought about citrix, but again thats a long term plan.

I don't know how much users is in Your remote offices and do how is Your
network management but from what I know rght now I will recommend You to
not create child domains but put the DC's of existing domains in the
remote offices network (perfect situtation will be to have 2 DC's in
each office) - remember to make them GC, create custom replication
schema to avoid unecessery replication traffic during working hours.
This should work for You just fine.

yes i understand. the main thing i want to know about is the AD
data replication. can anyone recommend any KBs? Thanks.

I'm not saying that this advice is perfect and only proper way ,
please give us more information:
- how many users is in each remote locations?

in each remote site there are approx. 20 users. this may increase
slightly (30/40), but if it changes more, then its back to the drawing
board

- did You plan to have separate IT stuff to mange remote offices or You
will manage this from the central office ?

this will be managed from the central office.
i intend on using central syslogging. also network monitoring (nagios,
whats up gold).


thanks in advance, and thank you thomas.

rgrds,
bernard
--

 

[Tomasz Onyszko]

Hi Tomasz,

Dziekuje for your help

You're bardzo prosze

yes i understand i will have 2 way trusts with AD. thats perfect. again 90%
of the day-to-day operation of the remote offices (except for rdp connections)
can operate on their own.

Yes - and the RDP connections will be authenticated via this trust If
you will implement this child domain model

our mailserver is exchange 2000. ideally i would like to receive all mail
into our main mailserver, and then send them to the remote office mailserver
(...)


thats what i would like to work forward to. in the meantime i think i would be
happy with the remote offices connecting to the main mailserver to receive
their mail.

Realy - I will recommend You to stay with single domain and additional
DC's in the remote offices - You can also put addtional Exchange servers
in this offices within existing Exchange organization and place remote
offices users mailboxes on this servers. With a little configuration or
simple SMTP sink script You will be able to archvie all -mails on the
central Exchange server which will be also Internet bridgehead server
for Your organization

having some traffic back to the main office is ok. they have to connect
to the main office for rdp, and other things.
i had thought about citrix, but again thats a long term plan.

I don't know how many users will work through RDP concurantlly but If
You plan to cut the network bandwitdth calculate needed bandwidth for
this connections before reducing it.

yes i understand. the main thing i want to know about is the AD
data replication. can anyone recommend any KBs? Thanks.
http://www.microsoft.com/downloads/...F6-A8A8-40BB-9FA7-3A95C9540112&displaylang=en
http://support.microsoft.com/default.aspx?scid=kb;EN-US;244368


in each remote site there are approx. 20 users. this may increase
slightly (30/40), but if it changes more, then its back to the drawing
board

No, draw it now ) think with some future in Your mind.
For so few users don't create separate domains - just create OU's and
place them in this OU's in Your current domain

 

[Guest]

You're bardzo prosze


Realy - I will recommend You to stay with single domain and additional
DC's in the remote offices - You can also put addtional Exchange servers
in this offices within existing Exchange organization and place remote
offices users mailboxes on this servers. With a little configuration or
simple SMTP sink script You will be able to archvie all -mails on the
central Exchange server which will be also Internet bridgehead server
for Your organization

aha, this sounds interesting. any more information available?
i would like to try this if possible. all the backups are done in this office,
and therefore would like to backup mail in this office also.

I don't know how many users will work through RDP concurantlly but If
You plan to cut the network bandwitdth calculate needed bandwidth for
this connections before reducing it.

chances are they all, or most, will be connecting by RDP concurrently. They all
use accounts packages/CRM etc which are terminal services based.
I plan to cut the bandwidth, but will calculate it first.

9FA7-3A95C9540112&displaylang=en
http://support.microsoft.com/default.aspx?scid=kb;EN-US;244368

perfect. thanks.

No, draw it now ) think with some future in Your mind.
For so few users don't create separate domains - just create OU's and
place them in this OU's in Your current domain

i don't think that the offices will be growing past 100 users. the offices
can't take it!

thanks again for your help.
rgrds,
bernard
--

 

[Cary Shultz [A.D. MVP]]

I will jump in here for the moment. Tomasz is probably just now getting up!

Anyway, I would generally not suggest that you have a red.widgets.com and a
blue.widgets.com without any really explicit reasons. Does not sound like
you have any.

As Tomasz has suggested, I would keep the flat domain, create an OU for each
remote location and make use of Active Directory Sites and Services ( Tomasz
might not agree with that ). You would have one Site ( the default
Default-First-Site-Name ) for the HQ and a Site for each of the remote
offices ( so, Red and Blue in this case ). Now, do you really need the
Sites? I would say yes. Others might say otherwise. What does using Sites
give you? The ability to assist/speed up user logons and better control
over Active Directory Replication.
I just do not think that 2MB is fast enough - especially if it is probably
going to be reduced to 1MB in the future. Sounds like you have the VPN going
( or will have it ). This reduces the available bandwidth as well.

You asked about Active Directory Replication. I will try to give you a
succinct overview here.

There are two types of ADR ( Active Directory Replication ): intrasite
replication and intersite replication. Intrasite Replication is the
replication between Domain Controllers that are located in the same Site.
Intersite Replication is the replication between Domain Controllers located
in different Sites. You need multiple Domain Controllers in the same Site
to have Intrasite Replication ( and Tomasz suggested that a best practice
would be to have two DCs in each Site - but with 20 users you might have a
hard time getting the funds for the second DC....I would strongly suggest
that you try and that you make them aware of the consequences ). As long as
you have multiple Sites you will have Intersite replication. There will be,
in each Site, a Domain Controller that acts as the Bridgehead Server (
BHS ). What does this do? The replication between Domain Controllers in
different sites is accomplished through the BHS in each Site. So, in HQ one
of the DCs would be acting as a BHS and the DC in Red would be acting as BHS
for this replication round. These two specific DCs will be replication
partners. Well, this sounds obvious since there is only one DC in Red. But
what if you have three or four Domain Controllers in each Site? What DC is
used for the Intersite Replication? Well, the answer everytime is the DC
that is the BHS.

Do you want to specify a DC to be a BHS? Probably not. What I mean by that
is our friend the KCC ( Knowledge Consistency Checker ) with its friend the
ISTG will do all of this for you. It sets up everything based on your Sites
and Services setup. If you do manually specify a BHS then I would suggest
that you specify multiple DCs - where they exist - to be the BHS. You see,
if the DC that you specify to be the BHS is not available the KCC is kinda
stuck. You will notice that your Intersite Replication will fail.

Can you disable the KCC and do everything yourself? Absolutely. Do you
want to? Probably not in your environment.

And, I have saved the best for the last. Active Directory is based on
incoming connection objects. This is very important to remember. I would
suggest that you take any two systems ( be it at home or at work ) and
install WIN2000 Server, make them DCs and the install the Support Tools (
located on the WIN2000 Server CD as well as the WIN2000 Service Pack CD in
the Support | Tools folder ) and take a look at repadmin /showreps and
repadmin /showconn. This will make things a bit more clear for you in this
regard.

HTH,

Cary

 

[Cary Shultz [A.D. MVP]]

Completely forgot to include what exactly was being replicated!

In Active Directory there are three partitions, or Naming Contexts: the
Schema NC, the Configuration NC and the Domain NC. Each one of these is a
separate partition. Think of it as a pie that is cut into three pieces.

The first two NCs are replicated to each and every Domain Controller that is
in the forest. This is an important thing to know. The Domain NC is
replicated to all of the Domain Controllers in that particular domain.

So, let's take a look at what would be replicated in the two scenarios that
we see with your question.

Let's look first at the suggestion that Tomasz gave you ( a flat domain -
and let's assume that you are able to get the funding for two DCs in each
Site ). Well, the Schema NC and the Configuration NC are replicated to all
Domain Controllers in the forest. So, any changes made here are going to be
replicated to all six of the Domain Controllers. Since you have only one
domain ( widgets.com ) all six of the Domain Controllers will receive any
changes made to the Domain NC.

Now, let's take a look at what you initially thought about doing ( having
child domains - and let's assume that you have two Domain Controllers in
each domain ). Again, the Schema NC and the Configuration NC are replicated
to all Domain Controllers in the forest - so any change made here will be
replicated to all six of the Domain Controllers ( the two from widgets.com,
the two from blue.widgets.com and the two from red.widgets.com ). The
interesting part is when we look at the Domain NC in this situation. We
have three domains. So, there will be three different Domain NCs. The
Domain Controllers in the widgets.com domain will be replication partners
for this NC while only the Domain Controllers in the blue.widgets.com domain
will be replication partners for this NC and finally only the Domain
Controllers in the red.widgets.com domain will be replication partners for
this NC.

HTH,

Cary

I will jump in here for the moment. Tomasz is probably just now getting up!

Anyway, I would generally not suggest that you have a red.widgets.com and a
blue.widgets.com without any really explicit reasons. Does not sound like
you have any.

As Tomasz has suggested, I would keep the flat domain, create an OU for each
remote location and make use of Active Directory Sites and Services ( Tomasz
might not agree with that ). You would have one Site ( the default
Default-First-Site-Name ) for the HQ and a Site for each of the remote
offices ( so, Red and Blue in this case ). Now, do you really need the
Sites? I would say yes. Others might say otherwise. What does using Sites
give you? The ability to assist/speed up user logons and better control
over Active Directory Replication.
I just do not think that 2MB is fast enough - especially if it is probably
going to be reduced to 1MB in the future. Sounds like you have the VPN going
( or will have it ). This reduces the available bandwidth as well.

You asked about Active Directory Replication. I will try to give you a
succinct overview here.

There are two types of ADR ( Active Directory Replication ): intrasite
replication and intersite replication. Intrasite Replication is the
replication between Domain Controllers that are located in the same Site.
Intersite Replication is the replication between Domain Controllers located
in different Sites. You need multiple Domain Controllers in the same Site
to have Intrasite Replication ( and Tomasz suggested that a best practice
would be to have two DCs in each Site - but with 20 users you might have a
hard time getting the funds for the second DC....I would strongly suggest
that you try and that you make them aware of the consequences ). As long as
you have multiple Sites you will have Intersite replication. There will be,
in each Site, a Domain Controller that acts as the Bridgehead Server (
BHS ). What does this do? The replication between Domain Controllers in
different sites is accomplished through the BHS in each Site. So, in HQ one
of the DCs would be acting as a BHS and the DC in Red would be acting as BHS
for this replication round. These two specific DCs will be replication
partners. Well, this sounds obvious since there is only one DC in Red. But
what if you have three or four Domain Controllers in each Site? What DC is
used for the Intersite Replication? Well, the answer everytime is the DC
that is the BHS.

Do you want to specify a DC to be a BHS? Probably not. What I mean by that
is our friend the KCC ( Knowledge Consistency Checker ) with its friend the
ISTG will do all of this for you. It sets up everything based on your Sites
and Services setup. If you do manually specify a BHS then I would suggest
that you specify multiple DCs - where they exist - to be the BHS. You see,
if the DC that you specify to be the BHS is not available the KCC is kinda
stuck. You will notice that your Intersite Replication will fail.

Can you disable the KCC and do everything yourself? Absolutely. Do you
want to? Probably not in your environment.

And, I have saved the best for the last. Active Directory is based on
incoming connection objects. This is very important to remember. I would
suggest that you take any two systems ( be it at home or at work ) and
install WIN2000 Server, make them DCs and the install the Support Tools (
located on the WIN2000 Server CD as well as the WIN2000 Service Pack CD in
the Support | Tools folder ) and take a look at repadmin /showreps and
repadmin /showconn. This will make things a bit more clear for you in this

 

[Tomasz Onyszko]

I will jump in here for the moment. Tomasz is probably just now getting up!

The good advices are always welcome ina thread

As Tomasz has suggested, I would keep the flat domain, create an OU for each
remote location and make use of Active Directory Sites and Services ( Tomasz
might not agree with that ). You would have one Site ( the default

Why not, I will strongly agree with You - I didn;t wrote iti but I will
do this in the same way.

in different Sites. You need multiple Domain Controllers in the same Site
to have Intrasite Replication ( and Tomasz suggested that a best practice
would be to have two DCs in each Site - but with 20 users you might have a
hard time getting the funds for the second DC....I would strongly suggest
that you try and that you make them aware of the consequences ). As long as

Yes, this will be good to have 2 DC's - when I sugested it in my firs
reply i was not aware about the number of users in this offices, however
If You will have a secodn server for a Exchange server I think You can
get a small funds for buing not very fast machine to be secodn DC
(joining DC and Exchange function on one server is not recommended)

(...)
Very good, short explanation of AD replication Cary

 

[Cary Shultz [A.D. MVP]]

Howdy, Tomasz...

Not sure how to say good morning in Polish, but maybe you understand
German...so, Guten Morgen!

in-line...

up!

The good advices are always welcome ina thread



Why not, I will strongly agree with You - I didn;t wrote iti but I will
do this in the same way.

Okay. I want to say that I remember you ( well, maybe it was not you! ) not
recommending to use Sites and Services when you have 2MB links. Maybe it
was Paul...I know that it was someone in Europe! Anyway, sorry for trying
to put words in your mouth!

long as

Yes, this will be good to have 2 DC's - when I sugested it in my firs
reply i was not aware about the number of users in this offices, however
If You will have a secodn server for a Exchange server I think You can
get a small funds for buing not very fast machine to be secodn DC
(joining DC and Exchange function on one server is not recommended)

Agreed. I saw that he did not give us the number of users in each Site
until after your comment. And your suggestion to plan with the future in
mind is a great one. Too many people only worry about the here and
now....without consideration for tomorrow. Then they have to redesign
everything due to a problem that could have been avoided in the first place.

(...)
Very good, short explanation of AD replication Cary

Thank you. I am working on being a bit less verbose. In other words...not
using so many words! This is a problem for me. Three pages later I am
still on the incoming connection object part of AD Replication....

 

[Tomasz Onyszko]

Howdy, Tomasz...

Not sure how to say good morning in Polish, but maybe you understand
German...so, Guten Morgen!

Yes, I will understand - I grow up 3 kilometers from the polish - german
border

In Polish - Dzieñ Dobry (with direct translation - Gutten Morgen in
German)

 

[Guest]

Hi Cary,

Firstly many thanks for jumping in! Both your and Tomasz's
replies have been very informative!

Ok, I'll try and keep up

Anyway, I would generally not suggest that you have a red.widgets.com and a
blue.widgets.com without any really explicit reasons. Does not sound like
you have any.

nope. thats why i asked

I just do not think that 2MB is fast enough - especially if it is probably
going to be reduced to 1MB in the future. Sounds like you have the VPN going
( or will have it ). This reduces the available bandwidth as well.

there is a VPN in place currently. they connect to our network via a netscreen
firewall and all the routing rules are set there. again a citrix solution maybe
necessary here.

My reason for reducing the bandwidth at the remote sites, was because I did
not see the necessity of a 2MB line in there.
My reasons were the following:
a. they do not browse internet sites (well, should I say, internet
browsing is not a priority in this office. It can be left to last.
b. there is a small number of users located here.
c. if necessary this can be increased very quickly (we have a good
ISP)
d. I did not think that AD would replicate too much information across
the sites. I had hoped it was possible to replicate at a fixed time
(ideally late PM/early AM)

replication and intersite replication. Intrasite Replication is the
replication between Domain Controllers that are located in the same Site.
Intersite Replication is the replication between Domain Controllers located
in different Sites. You need multiple Domain Controllers in the same Site
to have Intrasite Replication ( and Tomasz suggested that a best practice
would be to have two DCs in each Site -

in our headoffice we do have 2 DCs, so we have intrasite replication taking
place.
(i am fimilar with this, but as i said, have taken this role on..so I am
trying to understand it as i go along)

but with 20 users you might have a

hard time getting the funds for the second DC....I would strongly suggest
that you try and that you make them aware of the consequences ).

currently there is a small workgroup with a NT server in place. I will look at
the possibility of upgrading this to 2K server and using it as a second DC.
It may not be such a large problem to get another box..i can word it in a
persuasive way

As long as

you have multiple Sites you will have Intersite replication.

is it possible to set the time for this? i don't see it being possible, if all
the DCs have to have the same information as the others.

There will be,

in each Site, a Domain Controller that acts as the Bridgehead Server (
BHS ). What does this do? The replication between Domain Controllers in
different sites is accomplished through the BHS in each Site. So, in HQ one
of the DCs would be acting as a BHS and the DC in Red would be acting as BHS
for this replication round. These two specific DCs will be replication
partners. Well, this sounds obvious since there is only one DC in Red. But
what if you have three or four Domain Controllers in each Site? What DC is
used for the Intersite Replication? Well, the answer everytime is the DC
that is the BHS.

Do you want to specify a DC to be a BHS? Probably not. What I mean by that
is our friend the KCC ( Knowledge Consistency Checker ) with its friend the
ISTG will do all of this for you. It sets up everything based on your Sites
and Services setup. If you do manually specify a BHS then I would suggest
that you specify multiple DCs - where they exist - to be the BHS. You see,
if the DC that you specify to be the BHS is not available the KCC is kinda
stuck. You will notice that your Intersite Replication will fail.

so its a sort of round robin system? it trys the last designated BHS and if
that not there, it goes to another?

And, I have saved the best for the last. Active Directory is based on
incoming connection objects. This is very important to remember. I would
suggest that you take any two systems ( be it at home or at work ) and
install WIN2000 Server, make them DCs and the install the Support Tools (
located on the WIN2000 Server CD as well as the WIN2000 Service Pack CD in
the Support | Tools folder ) and take a look at repadmin /showreps and
repadmin /showconn. This will make things a bit more clear for you in this
regard.

maybe a wrong way to look at it cary, but if AD is based on incoming
connections, then should i have an async connection to the remote office?
i.e. 1MB out, 500K in? maybe i am looking at it wrongly.

thanks in advance for your assistance. you have made things clearer

rgrds,
bernard
--

 

[Cary Shultz [A.D. MVP]]

Bernard,

in-line...

Hi Cary,

Firstly many thanks for jumping in! Both your and Tomasz's
replies have been very informative!

Ok, I'll try and keep up


nope. thats why i asked

there is a VPN in place currently. they connect to our network via a netscreen
firewall and all the routing rules are set there. again a citrix solution maybe
necessary here.

My reason for reducing the bandwidth at the remote sites, was because I did
not see the necessity of a 2MB line in there.
My reasons were the following:
a. they do not browse internet sites (well, should I say, internet
browsing is not a priority in this office. It can be left to last.
b. there is a small number of users located here.
c. if necessary this can be increased very quickly (we have a good
ISP)
d. I did not think that AD would replicate too much information across
the sites. I had hoped it was possible to replicate at a fixed time
(ideally late PM/early AM)

in our headoffice we do have 2 DCs, so we have intrasite replication taking
place.
(i am fimilar with this, but as i said, have taken this role on..so I am
trying to understand it as i go along)

but with 20 users you might have a

currently there is a small workgroup with a NT server in place. I will look at
the possibility of upgrading this to 2K server and using it as a second DC.
It may not be such a large problem to get another box..i can word it in a
persuasive way

You could consider upgrading that NT Server to WIN2000 and then making it a
Domain Controller for that Site. That might not be a bad idea. Better
would be to get a new box and do a clean install of WIN2000 and make that
the Domain Controller for that Site. I am not a big fan of upgrades. Well,
for a short period of time it would be okay, but I have seen too many
upgraded servers ( never had a problem with the actual in-place upgrade.
That has always worked just swell! It is after the upgrade that is
problematic ) give me far too many headaches. Generally because 1) the
hardware is a bit older and 2) there is usually a lot of extra cra**
leftover.

As long as

is it possible to set the time for this? i don't see it being possible, if all
the DCs have to have the same information as the others.

Oh, it is very possible and works quite well. You can schedule the
replication to whatever fits your schedule requires ( and WAN links can
handle ). However, there are a few things that can be a bit frustrating.
For example, if you create a user account object in HQ you need to wait
until the Intersite replication takes place before that user account object
actually shows up in the other Sites. So, if HR tells you about a new hire
Monday at 10:15 AM ( and you have already received two phone calls from the
new hire asking about his computer ) and that new hire is in one of the
other Sites you have a nice situation on your hands ( one that can be easily
remedied, but you have to know to do this! ). Or, if you orget to create
that user account object until the phone calls start coming in.....

There will be,

so its a sort of round robin system? it trys the last designated BHS and if
that not there, it goes to another?


maybe a wrong way to look at it cary, but if AD is based on incoming
connections, then should i have an async connection to the remote office?
i.e. 1MB out, 500K in? maybe i am looking at it wrongly.

Not sure that it is a wrong way to look at it but not necessarily the right
way ;-) Remember, there are two ends to each replication partner. So, for
one end it is going from left to right while for the other end it is going
from right to left! Does that make any sense to you or do you need another
analogy? Also, know that this AD Replication is compressed. Also know that
changes made in WIN2000 to not replicate like they did in WINNT 4.0. In
WINNT 4.0 if you changed the city attribute on one user account then the
entire user account had to be replicated. In WIN2000 AD if you change the
value to any given attribute ( with CITY being the attribute and KOELN being
the value ) of an object ( in this case a user account object ) then only
that attribute is replicatied - and not the entire object!

thanks in advance for your assistance. you have made things clearer

rgrds,
bernard

More than glad to help!

Cary