When should I put a DC at a site?

We are planning an AD rollout. All AD servers will be Server 2008 R2.
We have a main office that will house 2 DCs, 8 offices all over the US
that are directly connected to our main office via point to point T1's
and several branch offices that are connected via VPN over the internet.
The 8 offices have between 15 and 65 users at them and the branch
offices all have 10 or fewer users. Assume that all sites' point to
points are very reliable and rarely go down. Also assume that when any
of the sites' point to points go down, they all fall back to vpn over
their internet connection. We use Citrix heavily so all file serving is
done locally at the main office between the citrix servers and the local
file servers.

We are trying to establish a rule for which sites (if any) get DC's. We
would like to be able to assign some group policies based on location
(i.e. by IP address). So I'm expecting to have some "Sites" in AD that
don't have servers at them. Does anyone have any advice / experience
that could help us decide what a good rule would be (e.g. > 25 users or
their is typically at least 500 kb/s of bandwidth to the site available
etc.)?

Thanks in advance for any advice / ideas.

Howdie!

Am 19.03.2010 17:26, schrieb Irwin Fletcher:
> We are trying to establish a rule for which sites (if any) get DC's. We
> would like to be able to assign some group policies based on location
> (i.e. by IP address). So I'm expecting to have some "Sites" in AD that
> don't have servers at them. Does anyone have any advice / experience
> that could help us decide what a good rule would be (e.g. > 25 users or
> their is typically at least 500 kb/s of bandwidth to the site available
> etc.)?

I think it's kind of hard to define a hard rule when a DC should be
located in a remote site and when not. It is my opinion that you simply
cannot make that up on blank numbers and statistics as to how reliable
the line is or their saturation. Sure, those numbers are important
factors for your decision but it you really should ask yourself how
important a locale DC for that site is for you. That's a case-to-case
decision you need to make.

If the link to the hub site is down, what services will be affected on
the remote site? Are users still able to work? What services are running
on the branches? Do they need to query DCs/GCs to work properly? What
about security at those branches? Would DCs be safe there? Any chance
they get stolen/compromised on-site? Are you willing to spend money on
the hard- and software required? What "user profile" lives there
remotely? Heavy users with lots of traffic and reliance on the hub site?

You see, you can ask yourself more question that just the metrics on the
line and the "hard numbers". Basically, I'd look into deploying RODCs in
those sites first and - if you can't use RODCs for some reason - think
about full-DCs. If there's a business need to always be able to
authenticate users in the remote site (just to be able to have them
authenticate on the remote DC and work with "remote" resources), throw a
(RO)DC at the site.

Cheers,
Florian

Understand what you're saying. So what can I expect to be slower if
there is no local DC at a site? It seems like it'll just be the first
login that's slow but I'm not sure.

Also, if there is no DC at a site but I define a site and a subnet for
that site, can I still apply group policies to the site? Or do I need a
local DC for that?

On 3/19/2010 3:35 PM, Florian Frommherz wrote:
> Howdie!
>
> Am 19.03.2010 17:26, schrieb Irwin Fletcher:
>> We are trying to establish a rule for which sites (if any) get DC's. We
>> would like to be able to assign some group policies based on location
>> (i.e. by IP address). So I'm expecting to have some "Sites" in AD that
>> don't have servers at them. Does anyone have any advice / experience
>> that could help us decide what a good rule would be (e.g. > 25 users or
>> their is typically at least 500 kb/s of bandwidth to the site available
>> etc.)?
>
> I think it's kind of hard to define a hard rule when a DC should be
> located in a remote site and when not. It is my opinion that you simply
> cannot make that up on blank numbers and statistics as to how reliable
> the line is or their saturation. Sure, those numbers are important
> factors for your decision but it you really should ask yourself how
> important a locale DC for that site is for you. That's a case-to-case
> decision you need to make.
>
> If the link to the hub site is down, what services will be affected on
> the remote site? Are users still able to work? What services are running
> on the branches? Do they need to query DCs/GCs to work properly? What
> about security at those branches? Would DCs be safe there? Any chance
> they get stolen/compromised on-site? Are you willing to spend money on
> the hard- and software required? What "user profile" lives there
> remotely? Heavy users with lots of traffic and reliance on the hub site?
>
> You see, you can ask yourself more question that just the metrics on the
> line and the "hard numbers". Basically, I'd look into deploying RODCs in
> those sites first and - if you can't use RODCs for some reason - think
> about full-DCs. If there's a business need to always be able to
> authenticate users in the remote site (just to be able to have them
> authenticate on the remote DC and work with "remote" resources), throw a
> (RO)DC at the site.
>
> Cheers,
> Florian

Hello Irwin,

I fully agree with Florian about reasons for site DCs or not and which kind
of. A DC has not really something to do with the speed during logon. The
authentication isn't that bandwith/speed consuming. You have to think about
the logon itself as already described from Florian, with no connection this
wan't occur except with cached credentials.

GPOs can be applied also over the WAN link, there is no need only for GPOs
to have a DC in the site. But depending on the configuration made in the
GPO this can take time if a login/startup script for example copies files
for what ever reason from the netlogon share to the local machine.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm


> Understand what you're saying. So what can I expect to be slower if
> there is no local DC at a site? It seems like it'll just be the first
> login that's slow but I'm not sure.
>
> Also, if there is no DC at a site but I define a site and a subnet for
> that site, can I still apply group policies to the site? Or do I need
> a local DC for that?
>
> On 3/19/2010 3:35 PM, Florian Frommherz wrote:
>
>> Howdie!
>>
>> Am 19.03.2010 17:26, schrieb Irwin Fletcher:
>>
>>> We are trying to establish a rule for which sites (if any) get DC's.
>>> We would like to be able to assign some group policies based on
>>> location (i.e. by IP address). So I'm expecting to have some "Sites"
>>> in AD that don't have servers at them. Does anyone have any advice /
>>> experience that could help us decide what a good rule would be (e.g.
>>> > 25 users or their is typically at least 500 kb/s of bandwidth to
>>> the site available etc.)?
>>>
>> I think it's kind of hard to define a hard rule when a DC should be
>> located in a remote site and when not. It is my opinion that you
>> simply cannot make that up on blank numbers and statistics as to how
>> reliable the line is or their saturation. Sure, those numbers are
>> important factors for your decision but it you really should ask
>> yourself how important a locale DC for that site is for you. That's a
>> case-to-case decision you need to make.
>>
>> If the link to the hub site is down, what services will be affected
>> on the remote site? Are users still able to work? What services are
>> running on the branches? Do they need to query DCs/GCs to work
>> properly? What about security at those branches? Would DCs be safe
>> there? Any chance they get stolen/compromised on-site? Are you
>> willing to spend money on the hard- and software required? What "user
>> profile" lives there remotely? Heavy users with lots of traffic and
>> reliance on the hub site?
>>
>> You see, you can ask yourself more question that just the metrics on
>> the line and the "hard numbers". Basically, I'd look into deploying
>> RODCs in those sites first and - if you can't use RODCs for some
>> reason - think about full-DCs. If there's a business need to always
>> be able to authenticate users in the remote site (just to be able to
>> have them authenticate on the remote DC and work with "remote"
>> resources), throw a (RO)DC at the site.
>>
>> Cheers,
>> Florian