Re: Sites or Domains
- From: "Jorge Silva" <jorgesilva_pt@xxxxxxxxxxx>
- Date: Wed, 2 Aug 2006 19:31:11 +0100
Inline
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.
- First, I think that in your description I don't see any reason to create a
multidomain.
- Second, if you're concerned about overloading of the Upgraded NT4 to
Windows 2003 take a look at NT4Emulator and NeutralizeNT4Emulator, this
solves the problem of overloading AD DC, and the upgrade of the BDCs.
-Third, at any time the FSMO roles can be transferred to any DC in the same
domain, even if you loose one or more of them you can always seize the
roles.
2. If bandwidth was you main number one concern would you go single or
multi
domain.
I think that the main question here is how busy your AD will be....
If it's a very busy AD, lots of changes every day, DNS replication, AD
Replication, Wins Replication's Replication, etc. What you need is to
upgrade those lines and not to go to a multi environment scenario, after all
today we have VPNs, and more cheap lines than in NT4 days, so please think
again... does it really make any sense to create a multiple domain scenario,
when with that you probably end up by having to create Universal security
groups (More replication), the other domains will have to query the DNS at
the root (more replication) or maybe they need to have a secondary zone of
the top root domain (more replication),etc... The possible configuration
problems that might result from a complex scenario will end up with the IT
Staff charging extra time to solve those problems (more money), you'll need
extra hardware (at least 2 DCs per domain-> more money), the maintenance of
these DCs (more money), more administration is required (more money).
You see when your company decided to upgrade From NT4 to Windows 2003, you
immediately thought about FULL hardware upgrade right? You didn't think only
about upgrading the memory and the CPU. you also thought about new HDD, etc.
With new needs you need new rules (new lines).
Make the sum of the extra needs in a multidomain environment, and you'll see
that it's more cheap to have a unic domain than a multidomain, then with the
extra money upgrade those lines.
--
I hope that the information above helps you
Good Luck
Jorge Silva
MCSA
Systems Administrator
"skhips" <skhips@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1FCCC68C-8CDE-4129-8856-7DAAD05D08B4@xxxxxxxxxxxxxxxx
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.
.
- References:
- Re: Sites or Domains
- From: Jorge Silva
- Re: Sites or Domains
- From: skhips
- Re: Sites or Domains
- Prev by Date: Re: Taskpad Delegation
- Next by Date: Re: Running adprep /forestprep on 2003 domain controller
- Previous by thread: Re: Sites or Domains
- Next by thread: Re: admt 3 error
- Index(es):
Relevant Pages
|
