Single or Multiple Domains

[Charliey_2000]

Hi I wanted some feedback and suggestions on whether to
implement a single or muiltple domains in a sigle forest
tree.

Right now we have a root domain xx.com and a child domain
yy.xx.com. This is at the same site and works fine. We
have about 400 users. We are in the process of taking on
more then 30 sites. These 30 sites have anywhere from
100 to 400 users each. The sites are conncected by site
to site VPN connections.

The options I am considering is adding a second child
domain zz.xx.com and having the 30 sites as OUs.

The other option is just child domains for each site.
site1.xx.com, site2.xx.com,etc.

The 30 sites are apart of our company but a different
section.

My concerns for a single domain for the 30 sites are the
amount of traffic over the VPN and the VPN reliability.
All the 30 sites will be configured as different sites
with local domain controllers that will have to replicate
the entire domain back to the 29 other sites. The other
limitations of unique names for the entire domain and the
size of the DNS database. Since DNS names and Domain
names must be the same I can't imagine a dns database of
the 30 sites together. With this model I can maybe get
by with only one domain controller at each site since all
the other sites will provide fault tolerence.



With multiple domains at least only parts of AD will be
replicated. Also AD objects will only have to be unique
within its own domain. Also now DNS domains will be
sepeated out for the other 30 sites. I know with this
model I will need at least two domain controllers per
site for fault tolerance.

Any experences will be greatly appreciated

 

[Joe Richards [MVP]]

I would keep the 30 sites in a single domain, if you want a new domain, but possibly even in one of the domains you have
now. The overhead of all the extra domains will kill you. We were initially going to upgrade all of our domains in
place, once I had the 5 account domains done (it was an NT4 multiple master/resource domain layout) I *knew* that
upgrading all the domains in place would kill us for tracking replication for the GCs, the lists of domains in the logon
dropdowns, and just overall policy management. If I had to have that many domains, I would actually do them in
completely separate forests and use an NT4 model with them.

As a default going in stance, each of the DCs at the sites would be a GC as certain things don't work well without them.
However if you have Win2003 you can enable GC caching or with 2K3 or 2K you can simply disable the GC logon requirement
assuming you don't use UPNs and Universal Groups.

You also don't say whether you are running Exchange, what the configuration is (centralized versus decentralized), what
kind of apps you have that are used by users that may want GCs, etc.

Basically there are tons of things that need to go into the process of deciding which is the best way to go because no
two deployments are the same and what may be perfect for one company may be entirely wrong for you based on one thing
that may be special to you that no one else would think to ask about.

But with the data you give, I would try to stick with the number of domains I have, if there was a GREAT reason to add a
third, I would do so. I wouldn't however make a domain for each site - your DC hardware requirements automatically
double.

 

[Guest]

Thanks for the input.

We do not use exchange although we may in the future.
Really the primary reason for sepeate domains is the
amount of replication to be done. We have a site to site
vpn to all the sites over T1 or more then not partial T1
lines. I am just worried that the replication will be
slow link. These sites already have an it support team
that cannot and should not have any adminstrative
capabilites to other sites.

Also our support team here at the main office is really
not that big. I know we can delegate authority to OU's
but I wonder about some duties as simple as adding
workstation to the domain. By default they would all end
up in the default container for the domain. The remote
sites really shouldn't have any rights here and we really
don't won't to be involved in something as simple as
joining a workstation to the domain.

Seperate Forest is really not what we are looking for
since we do want a common database for the company and
really I dont see any benefits of this other then total
security boundries.

I would be interesting in hereing how many sites you have
in your single domain model and how its working for you.
How much effort is needed to keep unique IDs for each
site and what about dns zones. Just seems like alot of
entries for the domain. Also do you have or heard of
anyone using the multple domain model for windows 2000.
I know it may require more hardware but seems like since
child domains have transitive trusts it would not be that
much more adminsitration with universal groups. Also for
the local adminstrative team they would not lose as much
control as they would in a single domain model

-----Original Message-----
I would keep the 30 sites in a single domain, if you

want a new domain, but possibly even in one of the
domains you have

now. The overhead of all the extra domains will kill

you. We were initially going to upgrade all of our
domains in

place, once I had the 5 account domains done (it was an

NT4 multiple master/resource domain layout) I *knew* that

upgrading all the domains in place would kill us for

tracking replication for the GCs, the lists of domains in
the logon

dropdowns, and just overall policy management. If I had

to have that many domains, I would actually do them in

completely separate forests and use an NT4 model with them.

As a default going in stance, each of the DCs at the

sites would be a GC as certain things don't work well
without them.

However if you have Win2003 you can enable GC caching or

with 2K3 or 2K you can simply disable the GC logon
requirement

assuming you don't use UPNs and Universal Groups.

You also don't say whether you are running Exchange,

what the configuration is (centralized versus
decentralized), what

kind of apps you have that are used by users that may want GCs, etc.

Basically there are tons of things that need to go into

the process of deciding which is the best way to go
because no

two deployments are the same and what may be perfect for

one company may be entirely wrong for you based on one
thing

that may be special to you that no one else would think to ask about.

But with the data you give, I would try to stick with

the number of domains I have, if there was a GREAT reason
to add a

third, I would do so. I wouldn't however make a domain

for each site - your DC hardware requirements
automatically

double.

wrote in message [email protected]...

 

[Joe Richards [MVP]]

My environment is ~250,000 users (~180,000 are mail enabled through Exchange), 150,000 contacts, probably about 80,000
groups almost all Domain Local Groups, several hundred thousand machines. All of this is in 5 main account domains
(Geographic regions around the world), an empty forest root, and an application domain for data center application
servers such as corporate web servers and SQL/Oracle Servers, etc. Oh we have about 450 sites. We started with
probably around 600-700 NT4 Domains. We initially had 4 W2K Application Domains for the Data Center but realized that it
was too much overhead and there was no benefit. We have sites that have connections as slow as 56k dedicated. We also
have sites with T1s and T3s but with 60-90% of the bandwidth limited to a specific application and of course we have
sites with wide open T1s, T3s, and Gig+ Fiber (our main campuses are all Fiber with complete mesh). Our main 5 domains
are broken down roughly into the following sizes for users - 45000, 75000, 110000, 10000, 8000. The 8000 user one is our
South American Domain and you want to talk about bad connectivity to sites of which there are probably 10 sites. The
other domains all have >50 sites with some having much greater than 50 such as Europe (110,000 users). We only have GCs
in corporate data centers (maybe 37 GCs total mostly for Exchange 2000) and do NOT use Universal groups and have the GC
requirement for logon disabled on domain controllers. We are in full W2K Native mode across the entire forest. We do not
have site link bridging enabled and have NOT disabled the KCC. It is running just fine. We have a hub and spoke
architecture with 3 main regional corporate data center hubs all fully interconnected and the WAN sites all spoking out
from the hubs.

There are exactly 4 domain admins across all of the domains. The SAME 4 people all based in the USA. 3 analysts
(including myself) and a manager who we don't allow to log on. This is for security and stability. Note well that if the
idea is to give your local admins Admin rights on the domain controllers if they are all separate domains this is a BAD
idea. If they are in the forest, they have the ability to take control of the forest. Domains ARE NOT security
boundaries, they are security policy and "sort of" replication boundaries. DO NOT give anyone you do not FULLY trust
interactive access rights nor critical file system rights to a domain controller.

We do not allow machines to be placed in the computers container, they are all placed into delegated OU's. The
workstation machine accounts are precreated or people use NETDOM to script the join process. Server machine accounts are
precreated by MY team in special locked down OU's that local site can only do the join to the pre-created accounts we
create. If we find (through scanning scripts) servers that have been added to the workstation OU's, we disable those
machine accounts and make them invisible to all normal users effectively killing the use of the name.

If you are planning on putting GC's in the remote sites, the more domains you have, the more replication you will have
as each GC will have to maintain the extra crap that each domain will have. However Exchange has a lot of PAS (partial
attribute set) data so Exchange any domain would put considerable extra data in the GCs of all domains.