Setting up remote domain controllers...

[aschrades]

Hello - I'm looking for a little advice on setting up remote domain controllers. Most of my business clients either have one location or use a terminal server for remote users. I have one business that is opening two additional locations (20+ users at each location) and I want to make sure my plan is sound since I've never done this before.

I'm going to have a site to site VPN between all three locations. Each branch location will have a small 2008R2 server. The main location will have the their app\database server and a terminal server. I'll join everything to the main domain and setup a common shared drive, login scripts, Active Directory replication, etc.

My main questions relate to DHCP, DNS, authentication, etc. Each network will be on a different subnet. I assume computers on the local subnet will point to the local server for DNS and DHCP, correct? Do I add forwarders on the local DNS servers to the DNS server at the main location or just leave the forwarders pointed to the ISP DNS server?

If I make each server a global catalog server will the local computers automatically seek the local server for authentication? How do they know that is the correct one?

Anything else I need to be aware of or plan for in your experience?

Thanks for your time!

-Adam

 

[Tony_Scarpelli]

it seems a bit wonkey to me. Why not have everyone logon to the TS? No need for vps or 2nd 3rd off site servers.

 

[NETWizz]

Hi Adam, glad to hear you are planning because I often get called in as a consultant to fix stuff like this when someone else tries to do it and screws up. No worries though; it is easy.

Hello - I'm looking for a little advice on setting up remote domain controllers. Most of my business clients either have one location or use a terminal server for remote users. I have one business that is opening two additional locations (20+ users at each location) and I want to make sure my plan is sound since I've never done this before.

The number of users doesn't really matter; also, the computers can authenticate across the VPN just fine. There is very little Domain Services traffic in reality, but I totally agree that it is a good idea to put another couple Domain Controllers into the network.

I'm going to have a site to site VPN between all three locations. Each branch location will have a small 2008R2 server. The main location will have the their app\database server and a terminal server. I'll join everything to the main domain and setup a common shared drive, login scripts, Active Directory replication, etc.

The Apps/Database will take up much more network bandwidth than authenticating against a Domain Controller on the other side of the WAN. Just saying.

Replication should set itself up... you can check in replmon, the Active Directory Replication Monitor.

You can configure replication peers via Active Directory Sites and Services.

My main questions relate to DHCP, DNS, authentication, etc. Each network will be on a different subnet. I assume computers on the local subnet will point to the local server for DNS and DHCP, correct? Do I add forwarders on the local DNS servers to the DNS server at the main location or just leave the forwarders pointed to the ISP DNS server?

You probably should setup a lab at home to understand how all this works before taking the job.

It is good that each network will be on a different sub-net; since, that will make layer-3 routing possible.

Are they going to be on separate VLANs, too? <== This doesn't matter either way; it is just something you probably want to know.

The computers don't point to any DHCP server at all. Instead, the DHCP servers have to point at the computers. Here is the deal... You setup different DHCP scopes for different subnets. In each DHCP scope you can specify different DNS settings if you wish push out for that DHCP scope (obviously you push the appropriate Default Gateways, too) ... or you can use the same DNS servers, too (as long as routing can allow computers to reach them). DNS is very low bandwidth much like your computer(s) at home that probably point to your ISP. In other words, it does work to point to DNS servers on the other side of a WAN/VPN.... Yeah, obviously anything is a bit faster on the local subnet.

DHCP uses broadcasts, so you will have to configure your routers or VPN equipment to forward that to your other subnet unless each subnet hosts its own DHCP server.

Here is how:
http://www.ciscopress.com/articles/article.asp?p=330807&seqNum=9

http://allaboutmylife.wordpress.com/2007/10/17/ip-helper-addresses-for-dhcp/


Authentication is different:

In Active Directory Sites and Services, you define each of your Active Directory Sites (sounds like you will have three of them). In each site, configure your Subnets the site supports and in each site install the Domain Controllers that service those AD Sites. Remember you can put multiple subnets per site if you want and multiple Domain Controllers per Site, too.

On my network, I have 20 or so Active Directory Sites each have probably a dozen subnets they service... That is over 200 locations.

If I make each server a global catalog server will the local computers automatically seek the local server for authentication? How do they know that is the correct one?

A Global Catelog has absolutely nothing to do with authentication. A Global Catalog server simply means it hosts a replica of all the Directory Objects.

Anything else I need to be aware of or plan for in your experience?

Thanks for your time!

-Adam

There is a LOT more you should know like how the metrics work for replication... about Operations Masters, VB/PowerShell scripting, how to use Group Policy and Group Policy Preferences effectively... How to setup DFS roots and/or clustering for the shared resources...


If you like this one, Add to NETWizz's reputation. ;-)

 

[NETWizz]

it seems a bit wonkey to me. Why not have everyone logon to the TS? No need for vps or 2nd 3rd off site servers.

It is not Wonkey... Hardly anyone uses Terminal Services. Why not? ==> Maybe because TS licencing is pricey and you need high performance hardware to get 40+ sessions going on a single server. I don't see it used much in healthcare, K12 education, Government, or Higher Education (Colleges/Universities).

Most everybody creates one or more subnets and one or more VLANs per site and connnects them together via some type of Wide-Area-Network topology... then the setup Active Directory to service the entire network & all the computers.

The generally setup Group Policy to configure the computers.

They generally use something like ZENWorks, KBOX, SCCM, Alteris, or some other Agent to deploy software, deploy computers, manage patches, manage helpdesk tickets, manage inventory, etc.

 

[Tony_Scarpelli]

Reading his original post, it looked like he said they were using TS already so I didn't compare that metric as additional cost.

It looked to me like having a high performance SQL server and another HP TS centralized would be the easiest and simplest to implement, and manage.

I am surprised by your limit of 40 nodes for TS as I have set up 75 users from no less than 5 locations, on both Win2000-2003 TS and Citrix nearly a dozen years ago and the hardware back then was plenty sufficient to do the job in most cases. I realize there has been OS and Software bloat but wow!

Depending on size I seldom ran 100% of applications from the TS for example MS Office would run locally while the proprietary SQL/Ticketing apps ran centralized.

The only snags or no no's that come to mind is graphic intensive programs are not for TS.

 

[NETWizz]

I missed that they are already running Terminal Services.

... If they have the bandwidth, that would be easy.


If not, simply setting up another DHCP scope, Default Gateway, and IP Helper... should get the other computers at the remote location seeing Active Directory.

They really don't need a Domain Controller at every site; heck, I don't have one at all my sites. For redundancy purposes, they should have more than one Domain Controller and at least one should be at a remote site though.


The 40 I gave was just the numbers we used years ago when I setup TS for a couple Schools with computers labs. Essentially, we set it up to only do 40 sessions per server, but there was more than one server. <== I am in no way saying 75+ users wouldn't work though.


That said, if you have a systems failure, BSOD, Windows Update reboot, etc. You will have 75 people with their eyes bulging out of their head like this

If they already have the Terminal Services Licencing, they should probably use that, but it would be best to have the Terminal Server(s) on the LAN that services the client computers. Something tells me 70+ TS sessions over a VPN WAN link is going to cause issues.


If they are going to use Terminal Services, they could get away with these:
http://www.hp.com/sbso/busproducts-thin-clients.html

 

[Tony_Scarpelli]

When using TS I wouldn't use VPN as it is redundant, unnecessary overhead. Just have a decent internet connection at each site. It is so simple I can manage it.

I think the reason that TS clients are so expensive now is that the Internet pipes are fat and juicy (reasonably reliable) so it makes for a good solution.

Most of my installs were much smaller than 75 nodes. But I was told that a 300 node is reasonably possible. The limiting factor back then was cost of Ram. You needed 20-56k bandwidth, 2 Mbtes per client. Hardly an issue today.

 

[NETWizz]

When using TS I wouldn't use VPN as it is redundant, unnecessary overhead. Just have a decent internet connection at each site. It is so simple I can manage it.

I think the reason that TS clients are so expensive now is that the Internet pipes are fat and juicy (reasonably reliable) so it makes for a good solution.

Most of my installs were much smaller than 75 nodes. But I was told that a 300 node is reasonably possible. The limiting factor back then was cost of Ram. You needed 20-56k bandwidth, 2 Mbtes per client. Hardly an issue today.

It is best to have the Terminal Services server on the same LAN as the clients; therefore, the VPN becomes necessary, so the Terminal Services server can see Active Directory from the remote location.

You need more than 56k bandwidth per client unless you want it to repaint really slow, be laggy, you won't get the Desktop background, Font smoothing, Desktop Composition, wont' see Window Contents while draging, or have visual styles...

>2 Mbps is where you get Visual Styles and Desktop Composition


You also need a LOT more than 2 Megabytes of RAM per Terminal Services Session. You need enough to run ALL their User-Mode programs, applications, an processes. A Web Browser with 12 tabs open (in my example) takes 300 Megabytes of RAM. A word document can take more than 50 Megs.

******************************************************

If you are going to operate this across the Internet then it is best to setup a Terminal Services Gateway:
http://technet.microsoft.com/en-us/library/cc731264(WS.10).aspx

 

[Tony_Scarpelli]

I'd have to be an idiot to setup a remote office to logon into a terminal server only to use a internet browser or office applications with the exception of Exchange Outlook..

I setup TS to only run proprietary software which needs to be centralized. Databases and such. TS already uses RDP and doesn't require a tunnel so its a waste of resources.

I run all workstation apps locally so the most that might be tunneled would be if the office/docs type files were centralized to the server.

 

[NETWizz]

I'd have to be an idiot to setup a remote office to logon into a terminal server only to use a internet browser or office applications with the exception of Exchange Outlook..

I setup TS to only run proprietary software which needs to be centralized. Databases and such. TS already uses RDP and doesn't require a tunnel so its a waste of resources.

I run all workstation apps locally so the most that might be tunneled would be if the office/docs type files were centralized to the server.

My understanding:

1. The VPN isn't really setup to be a tunnel (though it is one). The VPN is to serve as a WAN connection connecting two, distant sub-nets together.

2. Obviously, you don't need a tunnel for RDP, but you need a great deal of bandwidth (i.e. a Standard 3 meg Internet connection isn't going to get 75 people on TS)

3. The TS server would therefore need to be local (for greatest performance) when you have 20+ users... or they are going to need a super high-speed connection or the connection will be laggy.

4. The VPN (or WAN) will be needed to authenticate a local TS server with remote AD.