Moving server farm into an AD domain

I'm researching the feasibility of moving our small (but not tiny) hosting infrastructure from stand alone servers each with unique local usernames and passwords, to a more intergrated active directory setup with the aim to utilising the following features:

• Ease of managing staff specific server access and auditing, removing the need to maintain a password list
• DFS with replication to move to an IIS NLB webfarm
• Ease of deploying windows updates and general security updates, making global changes to servers

I'm running half on Vmware server 2 (migrating to Esxi currently) running mostly win2k3 machines and half physical machines also running mostly win2k3.

The servers are: 2x DNS servers
5x IIS6 webservers
5x MSSQL2000 / 2008 servers
10x IIS6 & MSSQL 2000 dedicated servers
2x NAS backup servers
2x IIS7 & MSSQL 2008 servers
5x Win2k3x64 Servers running VMware server (will be converted soon)
Misc test servers

I now have (thanks to the power of VMware) 2x Domain controllers

I've hit problems trying to work with an existing AD DNS name (companyname.com) which exists on the existing DNS servers. Should I be configuring these to accept updates from the new DCs or should I be delegating authority some other way?

My major concerns are about the best method for the approx 10 users to log on to domain at the remote datacentre from my office, would I be advised to setup 1-2 domain controllers at my office for logon? If configured correctly could I then tie users to more easily logon to my remote servers? Or do I not need domain controllers at the office? In the event of an internet outage I don't want users to be unable to log on to their machines.

My second concern is that if I move from a shared user logging on to remove servers, currently these users share the terminal service session and grab inactive sessions etc. If I have people accessing via unique accounts, separate sessions will get spawned per user. How are these controlled in an AD environment, or are they subject to the win2k3 limit of 2 sessions + console by default? If I were to purchase additional terminal server licensing, would it be per user or per machine? I worry about introducing these problems which were do not currently have.

I plan a piloted connection of a couple of each server type to the new domain, followed by a mass roll out which seems the correct way to go about things.

Can anyone answer my questions or point out anything glaring I've missed?

From serverfault Chris

• Ideally you should have at least one domain controller local to your users but if you have a fast enough connection to wherever they are physically located that doesn't matter too much. Even so I would prefer to see at least one DC that wont get isolated from your users if there is a WAN outage, it doesn't have to be a particularly powerful box any entry level server will probably be more than enough for you.

  If you lose access to a domain temporarily then local logons to machines will continue to work for accounts that have already logged on previously - this uses locally cached credentials in the same way that a disconnected laptop works when it is off the network.

  As you move to a proper account->user mapping then you will need to sort out Terminal Server licensing for the systems that your users connect to because the 2 session+console limit will apply. There are a number of options - per device CALs may be suitable if you have a lot of users who share the same systems used to access the terminal sessions (e.g. you have a pool of a (relatively) small no of shared PC's for a much larger number of users) but per user licensing is probably a better match if most of your users have a dedicated PC. The 2008 Terminal Services Licensing FAQ has some more detail on this.

  Chris : Thanks, thanks for clearing up the implications of loss of connectivity with the DC. I've made some progress with TS licensing now so that's in hand. My only remaining question is how to intergrate with DNS then I can proceed with my pilot :)

  Helvick : This post on the TS Team Blog about licensing may throw some more light on your licensing options\requirements http://blogs.msdn.com/b/rds/archive/2009/09/04/what-s-the-difference-between-a-rds-cal-and-a-ts-cal.aspx
  From Helvick

• As for integrating with DNS, the most common solution is to use a subdomain. You would then set your current DNS servers delegate authority for that subdomain to the AD servers.

  If your site is example.com, for example, you would make the FQDN of the domain into something like ad.example.com. Your DNS servers for example.com would have a stub pointing to ad.example.com. Make sure DHCP has both of the suffixes, or at least the AD one.

  Make sense?

  From Jeff McJunkin