Re: Sites or Domains
- From: skhips <skhips@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 2 Aug 2006 10:36:02 -0700
Many thanks for the detailed reply, in summarry:
1. In ref to the FSMO roles if survaivabilty within a location was the main
number 1 concern would you go single or multi domain.
2. If bandwidth was you main number one concern would you go single or multi
domain.
"Jorge Silva" wrote:
Hi.
Inline
I am hoping to get some help with some design choices on moving from a 15
Domain, single Enterpise Win Nt4 strcutures to a W2K3 Single forest /
Single
domain / Multi Domain or multi forest.
Reasons to Create Multiple Domains: Meet security requirements,Meet
administrative requirements,Optimize replication traffic,Retain Microsoft
Windows NT domains.
Do not create multiple domains to accommodate polarized groups or for
isolated resources that are not easily assimilated into other domains. Both
the groups and the resources are usually better candidates for
organizational units (OUs).
When determining whether to create multiple Domains, keep the following
items in mind:
- DNS structure becomes more complex.
- Hardware costs increases.
- Domain administrators Each time a domain is added, a Domain Admins
pre-defined global group is added as well. More administration is required
to monitor the members of this group.
- Security principals As domains are added, the likelihood that security
principals will need to be moved between domains becomes greater. Although
moving a security principal between OUs within a domain is a simple
operation, moving a security principal between domains is more complex and
can negatively affect users.
- Group policy and access control Because group policy and access control
are applied at the domain level, if your organization uses group policies or
delegated administration across the enterprise or many domains, the measures
must be applied separately to each domain.
- Domain controller hardware and security facilities Each Windows Server
2003 domain requires at least two domain controllers to support
fault-tolerance and multimaster requirements. In addition, it is recommended
that domain con-trollers be located in a secure facility with limited access
to prevent physical access by intruders.
- Trust links If a user from one domain must log on in another domain, the
domain controller from the second domain must be able to contact the domain
controller in the user's original domain. In the event of a link failure,
the domain controller might not be able to maintain service. More trust
links, which require setup and maintenance, might be necessary to alleviate
the problem.
The other main issue is FSMO roles, at the moment if our WAN link goes
down
all the users can still work locally, even if the PDC or BDC crash they
can
be rebuilt, I am concerend with the FSMO roles, especially in a single
domain
where they all sit in the "root" that some functionalty or resiliance may
be
lost.
- General recommendations for FSMO placement
Place the RID and PDC emulator roles on the same domain controller.
If the load on the primary FSMO load justifies a move, place the RID and
primary domain controller emulator roles on separate domain controllers in
the same domain and active directory site that are direct replication
partners of each other.
-As a general rule, the infrastructure master should be located on a
non-global catalog server that has a direct connection object to some global
catalog in the forest, preferably in the same Active Directory site. Because
the global catalog server holds a partial replica of every object in the
forest, the infrastructure master, if placed on a global catalog server,
will never update anything, because it does not contain any references to
objects that it does not hold. Two exceptions to the "do not place the
infrastructure master on a global catalog server" rule are:
*Single domain forest:
In a forest that contains a single Active Directory domain, there are no
phantoms, and so the infrastructure master has no work to do. The
infrastructure master may be placed on any domain controller in the domain,
regardless of whether that domain controller hosts the global catalog or
not.
*Multidomain forest where every domain controller in a domain holds the
global catalog:
If every domain controller in a domain that is part of a multidomain forest
also hosts the global catalog, there are no phantoms or work for the
infrastructure master to do. The infrastructure master may be put on any
domain controller in that domain.
-At the forest level, the schema master and domain naming master roles
should be placed on the same domain controller as they are rarely used and
should be tightly controlled. Additionally, the domain naming master FSMO
should also be a global catalog server. Certain operations that use the
domain naming master, such as creating grand-child domains, will fail if
this is not the case.
All our domains / location are not permant and can be moved geogrpahically
and then brought back up using sat links, the bandwidth varies from small
locations at 64k to larger at 256k, with a total of 15 locations bringing
all
WAN links into one location (where we are looking at putting a 16th domain
/
site as root).We have the manpower to plan centralised or decentaralsied
managment but at the moment we are looking at bascially MCSE at root and
small MCSA teams at other locations.It is looking like we will go single
forest but its choosing between single or multi domain, I know sites mean
replication will be compressed but I get the impression it replicates more
data and more often, and then the impact of the FSMO roles, e.g am I right
in
saying that the PDC emulator records all bad password attempts and
controls
account lockout and does that mean if the WAN is down and a site cant see
the
PDC emulator will a user be allowed as many logon attempts as he wishes.
Sites are important to define were users have priority to logon (which site
DC/Gc,etc)...
Sites have to main roles:
- To facilitate authentication, by determining the nearest domain controller
when a user logs on from a workstation
- To facilitate the replication of data between sites Because site names are
used in the records registered in the Domain Name System (DNS) by the domain
locator, they must be valid DNS names.
Active Directory uses sites to:
- Optimize replication for speed and bandwidth consumption between domain
controllers.
- Locate the closest domain controller for client logon, services, and
directory searches.
- Direct a Distributed File System (DFS) client to the server that is
hosting the requested data within the site.
- Replicate the system volume (SYSVOL), a collection of folders in the file
system that exists on each domain controller in a domain and is required for
implementation of Group Policy.
As for the GCs UGMC:
First: The GC enables finding directory information regardless of which
domain in the forest contains the data, and provides Universal Group
Membership Information. Applications also use the first (any object in the
forest) Exchange is the prototypical example of this. (Windows 2003 has the
UGMC (Universal Group Membership caching which isn't the same thing as the
GC, there are some people that doesn't recomend the use of the UGMC, you
should know that is only recomended for sites with less than 100 users, it
can caches 500 Universal Group membership, and refresh its cache every 8
hours, the users need to logon at least one time to their group membership
to cached ).
Second: The GC is only needed when you have DFL (Domain Functional Mode) in
Native Mode or later where Universal security groups are allowed, more than
one domain or if you use any app that needs to contact the GC (Exchange is
an example), if you need to logon with a UPN.
Third: There's a registry setting "IgnoreGCFailures" that you can use in
particular scenarios to force a particular DC NOT TO CONTACT a GC for
authentication process. If you don't use Universal groups for securing
things then you can enable IgnoreGCFailures which will allow you to log on
even if a GC isn't abailable in a Native mode domain. However, if you have a
single domain there is no reason not to make every DC a GC. Note that even
with IgnoreGCFailures enabled, you could run into cases where a GC is needed
say when trying to logon with a UPN, etc.
Fourth: Good practices are to have at least one GC per site, even in a
single domain forest, every DC ALREADY holds ALL of the info so making a DC
a GC costs practically nothing.
The above is also true in a SMALL forest with multiple domains.
As forest size increases the penalty for creating a GC (increase
replication, increased storage) increases.
--
I hope that the information above helps you
Good Luck
Jorge Silva
MCSA
Systems Administrator
"skhips" <skhips@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7A2DF10C-C7D1-494A-B58D-99F5DCD4840C@xxxxxxxxxxxxxxxx
I am hoping to get some help with some design choices on moving from a 15
Domain, single Enterpise Win Nt4 strcutures to a W2K3 Single forest /
Single
domain / Multi Domain or multi forest.
I have asked some questions on courses and the answers have always been
quite vague e.g slow links and fast links, not "well if you have only 64k
you
must do this model".
The other main issue is FSMO roles, at the moment if our WAN link goes
down
all the users can still work locally, even if the PDC or BDC crash they
can
be rebuilt, I am concerend with the FSMO roles, especially in a single
domain
where they all sit in the "root" that some functionalty or resiliance may
be
lost.
All our domains / location are not permant and can be moved geogrpahically
and then brought back up using sat links, the bandwidth varies from small
locations at 64k to larger at 256k, with a total of 15 locations bringing
all
WAN links into one location (where we are looking at putting a 16th domain
/
site as root).We have the manpower to plan centralised or decentaralsied
managment but at the moment we are looking at bascially MCSE at root and
small MCSA teams at other locations.It is looking like we will go single
forest but its choosing between single or multi domain, I know sites mean
replication will be compressed but I get the impression it replicates more
data and more often, and then the impact of the FSMO roles, e.g am I right
in
saying that the PDC emulator records all bad password attempts and
controls
account lockout and does that mean if the WAN is down and a site cant see
the
PDC emulator will a user be allowed as many logon attempts as he wishes.
Many thanks for any asssitance.
- Follow-Ups:
- Re: Sites or Domains
- From: Jorge Silva
- Re: Sites or Domains
- References:
- Re: Sites or Domains
- From: Jorge Silva
- Re: Sites or Domains
- Prev by Date: Re: LDAP HELL !!
- Next by Date: Re: admt 3 error
- Previous by thread: Re: Sites or Domains
- Next by thread: Re: Sites or Domains
- Index(es):
Relevant Pages
|
