Take the 2-minute tour ×

Our entire Active Directory forest is currently on a single 10/8 private subnet. We're looking to migrate most of our servers to a cloud provider, but I'm not sure how to set up the first domain controller in the new cloud location.

I've read a lot about trusts (external, shortcuts, and realms) as well as sites (site links, inter-site replication, and subnets) but I can't quite tell which applies to our situation. The end goal is to have two separate private subnets with Active Directory user and group data synchronized between them. We can open whatever port(s) are necessary so the domain controllers can talk to each other over public IP addresses.

I've read through much of (what seems to be) the relevant official documentation, but I'm having trouble reconciling the abstract concepts with what needs to be done in my situation. What steps should be taken to accomplish what I'm trying to do?

share|improve this question

1 Answer 1

up vote 4 down vote accepted

I think you're just looking for a replica domain controller hosted on a VM at the "cloud provider". Don't worry about trust relationships, multiple domains, etc-- none of that applies to you.

Sites, site-links, and subnets do apply to you. I wrote an answer about what "Sites" do in Active Directory that's probably worth looking at.

When you mention "opening ports" and public IP addresses you start to worry me. If you're not going to have a VPN between you and the "cloud provider" you really need to be using IPSEC to secure your communication. That's going to make deploying a domain controller (DC) a bit more difficult. Deploying a domain controller over an IPSEC connection can be done using the AuthIP functionality to join the machine to be promoted to the domain so that it can communicate with the existing DC with IPSEC. (AuthIP is very poorly documented by Microsoft, so that makes matters even more difficult.)

You really don't want to be communicating in the clear over the Internet between DCs, nor do you want them to be publicly accessible to Joe Anybody on the Internet. (You don't want your member computers communicating with your DCs in cleartext over the Internet, either.)

The basic steps are as follows:

  • Create a site and subnet object in your Active Directory corresponding to the site and IP subnet where the new DC will reside

  • Configure the machine to be promoted to a DC to receive DNS service from an existing DC's DNS server

  • Join the machine to be promoted to the domain, using AuthIP, if necessary, to establish IPSEC communication with the domain during the join process

  • Promote the new DC using dcpromo (either by invoking from the GUI or just by running it)

Assuming the machine to be promoted can resolve names in your Active Directory domain and has connectivity to the existing DC on all the ports that it needs (which will be assured if you just let them communicate via IPSEC) you'll get a replica domain controller when the dcpromo process completes.

What you're talking about doing isn't run-of-the-mill by any means. You're going to have a difficult time finding people who regularly support this kind of infrastructure. (Perhaps it will become more common as time goes on, but it's certainly not common today.)

share|improve this answer
We do plan on opening a VPN connection to the cloud provider, but that includes cost and complexity that we don't want to be on the hook for maintaining indefinitely. At the end of this transition, the vast majority of our servers will be cloud-side and we'll have only a small handful on-site. By doing it this way, that VPN connection would be effectively mandatory indefinitely, right? If doing it without the VPN connection is a strange configuration, though, it's probably better that we just do things normally. –  Moduspwnens Feb 4 '12 at 18:58
Most Windows Server machines, and especially most Domain Controller computers, are deployed in private (non-Internet facing) networks, usually with stateful NAT filtering firewalls between them and the Internet. Putting your machines directly onto the public Internet is an atypical configuration and definitely would call for tightened-up host-based firewalls, IDS, etc. –  Evan Anderson Feb 4 '12 at 20:44

Your Answer


