Hi Arun,
I've gone ahead, broken your message apart below and given some guidance. I
hope this helps.
I see others posted as well, so between all of us hopefully you'll get the
answers you're looking for. If not, please do post back!
~Eric
--
Eric Fleischman [MSFT]
Directory Services
This posting is provided "AS IS" with no warranties, and confers no rights
Arun said:
Hi guru's,
We are planning our AD environment and have mixed
thoughts about creating a OU or a domian for a remote
site.
[ERIC] - I'm glad you have mixed thoughts. That means you're thinking about
it like you should!
We are concerned about replication,
[ERIC] - The first thing worth mentioning is that all DC's in a given forest
replicate with one another whether they are in the same domain or different
domains. Yes there is more replication on an intradomain basis than
interdomain, but still, replication is going on and taking up some
bandwidth.
That having been said, you have lots and lots of control over this. The main
thing one does to control replication (either in a single domain or between
many domains) is define sites, then use site links to control the frequency
of replication. A few high level points:
1) Each site link has a frequency at which replication happens. If it
happens more frequently, changes travel throughout the forest at the price
of more bandwidth, less frequently and it takes longer for changes to get
out there but will use less bandwidth over time. How many users are we
talking about in this enterprise? How often will user changes be made (IE
new users created, deleted, etc)
2) In Server 2003, replication is more efficient. If you haven't deployed
yet, I *strongly* urge you to use 2003 instead of 2000 for many reasons,
more efficient replication being just one.
3) There is also compression over the site links when replication takes
place to save on bandwidth.
4) Keep in mind, there are 2 times (again, from a high level) that one sees
replication worth thinking about:
a) when a DC is first brought up; this is a fair amt of bandwidth no
matter how you do it.
b) Over time, for changes. This is where site links and such can really
allow you to optimize your topology.
I encourage customers to think about scenario b, and not as much about a. In
2003 we also have a new feature Install From Media (IFM) that basically
makes scenario a no longer a consideration.
The real trick here is efficient site links, replication schedules and such.
Many domains in a single forest vs. one helps, but it isn't *the* answer.
[ERIC] - There are very few things that can not be delegated down. Basically
the only things that can not be controlled on a per OU basis (with a few
exceptions) are things related to password policy where all domain accounts
respect what is defined on the domain level. Outside of a few tasks like
that, nearly everything is a per-OU setting. You should have nearly-infinite
flexibility on the per OU basis for your site-based administrators to have
fun.
It is also worth noting that one can apply policy to a site just like you
can an OU. That is, it applies to all users when they log on to a computer
located in that site.
[ERIC] - Important point: the domain is not a true security boundry. The
true security boundry is the forest. This should not encourage you to deploy
many forests but rather think carefully about your environment. Most
organizations find one forest just fine for their purposes, sometimes you
have more if you are either 1) ultra high security or 2) testing purposes. I
think you should strongly strongly consider a single domain in a single
forest.
The remote site uses a wan link and
does not require a seperate namespace, but would like to
have administrative privelges for it's user base.
[ERIC] - that's perfect! You can create OU's in a single domain and delegate
admin control of any users/computers/groups in that OU to the local admins.
You can delegate out specific tasks (IE maybe you only want local admins to
be able to change passwords, update contact info, whatever!) or give them
full control of the objects in those OU's. Whatever you'd like. Go into the
product documentation and read up on delegation of administrative control.
Are
there any good articles or does anyone have some
recommendations.
[ERIC] this list would be huge. The help file has stuff, books from MS press
and others, and some white papers. I'd check out
http://www.microsoft.com/windows2000 and
http://www.microsoft.com/windowsserver2003/
Thanks in Advance.
