Multi-site AD setup

[ESM]

Hello all, I'm looking for some input on if the way I've structured by
multi-site AD setup is appropriate, or should be tweaked.

My physical network topology is a star with the Corporate office being in
the middle. Corporate office has 2 DC's on the same subnet that replicate
via RPC. The 5 FSMO roles are splut between these 2 DC's.

I have 61 other remote sites currently across the country. 2 of them are
connected via 3 meg and 10 meg metro-ethernet directly. 1 of them is
connected via a T1 point-to-point. These are private connections. All the
other sites are connected via IPSec VPN's over the internet. My Corporate
site has 10mbit internet with only 25% utilization, so plenty of bandwidth.
The remote sites have Cable or DSL connections, with 3 of them having T1's.
All of them have plenty of available upload/download bandwidth for
replication.

In each of those 61 remote sites, I have deployed a DC and made each of them
a GC as well. Primary function of these machines is printer/file sharing.
I've made them DC's because in the event of a VPN Failure, the local DC can
authenticate all requests as necessary and keep the remote site running.
Inter-site replication transports are set from 15 minutes to 90 minutes
depending on the size of the site.

As I add a new office, I add a new DC, and the number grows. This makes
replication across all DC's a very timely process, which is why I'm
wondering if I should revise my thinking. What say you?

 

[henkanilsson]

Hi,

IMHO i would recommend that you try to decrease the number of domain
controllers. Are you running w2k AD or w2k3 AD? Modifying some
attributes of a user object
(http://support.microsoft.com/kb/230663/EN-US/ to find out ) trigger a
full GC sync if your domain is running w2k. This will cause unecessary
replication.

Try to determine witch of the remote offices that really require a
dedicated DC/GC by demoting a couple of "test sites" and evaluate the
effect.

Also, if you have any universal groups look in to the "Universal group
caching" feature in w2k3
(http://www.windowsnetworking.com/kb...rectory/EnablingCachingofUniversalGroups.html)

because if the user is member of a universal group they might not be
able to log on without a GC on site.

rgds
Henrik

 

[Tyler Durden]

ESM wrote:
[...]

My physical network topology is a star with the Corporate office
being in the middle. Corporate office has 2 DC's on the same subnet
that replicate via RPC. The 5 FSMO roles are splut between these 2
DC's.

Hi, which OS are you using for your DC? Windows 2000 or 2003? How many
domain there are in your AD infrastructure?

I have 61 other remote sites currently across the country. 2 of them
are connected via 3 meg and 10 meg metro-ethernet directly. 1 of
them is connected via a T1 point-to-point. These are private
connections. All the other sites are connected via IPSec VPN's over
the internet. My Corporate site has 10mbit internet with only 25%
utilization, so plenty of bandwidth. The remote sites have Cable or
DSL connections, with 3 of them having T1's. All of them have plenty
of available upload/download bandwidth for replication.

You can use a DC only on sites with a slower bandwidth. For other sites you
may not use any DC and you can delete the related site and associate the
related subnet with the Corporate office site.

In each of those 61 remote sites, I have deployed a DC and made each
of them a GC as well. Primary function of these machines is
printer/file sharing. I've made them DC's because in the event of a
VPN Failure, the local DC can authenticate all requests as necessary
and keep the remote site running. Inter-site replication transports
are set from 15 minutes to 90 minutes depending on the size of the
site. As I add a new office, I add a new DC, and the number grows. This
makes replication across all DC's a very timely process, which is why

I think is correct; you must only consider the GC behavior; and here is
important the number of domains and the DC's OS: if you have only one domain
(2K or 2K3 does'nt matter), you can configure all DC as GC (no additional
replcation traffic will be made, because there are not other domain
information to store on the GC); if you have multiple domains, you need more
planning.

If the DC in a AD site cannot find a GC, by default users logon (all users,
not only user members of Universal Groups, as Henrik told) is denied
(however users can logon with cached credential). But having a GC in each
site can encrease network traffic.

If you have Windows Server 2003 DCs, you can configure Universal Group
Membership Caching if you want avoid to have a GC on every site (eg. sites
with few users).
If you don't use Universal Groups, you can deploy a registry key (W2k and
W2k3) to ignore the GC failure in user logon (so again you can avoid the
need of a GC for every site).
You must also know if there are applications in a site that make a lot of
query against the GC (then enable the GC at this site) and if users in your
organization need to often query information on other doamins in the forest
(enable GC). Also consider that if there are many domains with many users
and computers, and you remove the GC, but after you must re-enable it, you
cause a lot of networ traffic.

Last thing: in a such environment you must also consider the DNS and DHCP
Server placement, because if the link is down, clients on remote site can
have problems in Tcp/IP configuration and in name resolution.

 

[ESM]

ESM wrote:
[...]

My physical network topology is a star with the Corporate office
being in the middle. Corporate office has 2 DC's on the same subnet
that replicate via RPC. The 5 FSMO roles are splut between these 2
DC's.

Hi, which OS are you using for your DC? Windows 2000 or 2003? How many
domain there are in your AD infrastructure?

All DC's are 2003 SP1. I have a SINGLE domain, single forest. I am running
mixed mode right now, but will be in 2003 Native mode within 4 weeks. So
lets assume native mode only.

You can use a DC only on sites with a slower bandwidth. For other sites
you may not use any DC and you can delete the related site and associate
the related subnet with the Corporate office site.

Most of my sights are "slower" bandwidth, if you equate slower to DSL/Cable,
and faster to T1. However, that's really not true either. My Cable/DSL
sites are reliably faster then my T1 sites on their download side, but not
their upload side. The T1's are more "stable", although my Cable/DSL sites
rarely go down.

I think the appropriate question may be, "How much traffic is really
replicating"?...knowing all the remote sites are GC's, of course. In any
given day, there is probably less then a dozen changes made in ADU&C, of any
kind.

I think is correct; you must only consider the GC behavior; and here is
important the number of domains and the DC's OS: if you have only one
domain (2K or 2K3 does'nt matter), you can configure all DC as GC (no
additional replcation traffic will be made, because there are not other
domain information to store on the GC); if you have multiple domains, you
need more planning.

So, since I'm single domain, the GC's don't replicate anything over the
regular DC?

If the DC in a AD site cannot find a GC, by default users logon (all
users, not only user members of Universal Groups, as Henrik told) is
denied (however users can logon with cached credential). But having a GC
in each site can encrease network traffic.

Can you clarify for me? If I have a DC in RemoteSiteA and it's not a GC.
If that site cannot contact any GC in some other site, then the user will
log on with cached credentials? So essentially, the GC is required to
authenticate logins? However, since I'm single domain, I don't increase
traffic by making all these Remote Site DC's, also be GC's?

If you have Windows Server 2003 DCs, you can configure Universal Group
Membership Caching if you want avoid to have a GC on every site (eg. sites
with few users).

So I could create 1 unviersal group, and put EVERY user in it, and using the
"Universal Group Membership Caching" feature would do what exactly? How does
it differ if I do not use this feature?

If you don't use Universal Groups, you can deploy a registry key (W2k and
W2k3) to ignore the GC failure in user logon (so again you can avoid the
need of a GC for every site).

What does this do exactly? Does it mean that if a user can never find a GC
to login, they will always be allowed to login with cached credentials?
Even after the number of allowed logins with cached credentials is met?

You must also know if there are applications in a site that make a lot of
query against the GC (then enable the GC at this site) and if users in
your organization need to often query information on other doamins in the
forest (enable GC). Also consider that if there are many domains with many
users and computers, and you remove the GC, but after you must re-enable
it, you cause a lot of networ traffic.

Again, single domain, single forest. Can you give me a few ideas on what
makes a lot of queries against a GC? These remotes sites have the single DC
only I don't run other applications at remote sites. It's just the 1 DC
that does file/print sharing, and XP SP2 clients, with HP and Dell printers.

Last thing: in a such environment you must also consider the DNS and DHCP
Server placement, because if the link is down, clients on remote site can
have problems in Tcp/IP configuration and in name resolution.

If I run DNS on a 2003 member server at a site, is there a way to zone
transfer the domain's FQDN zone? If so, then I could use the member server
at each site to host DHCP and DNS, and if there was a link down, they'd
still have all the resources they need to work ont he network, correct?