Connecting to Active Directory and DNS in a vCloud Air Virtual Private Cloud

Many applications rely on Active Directory or Domain Controllers to be truly operational. However, when a primary data center experiences a disaster, these “pilot light" machines will also fail. One way to ensure that your protected workloads will be operational after failover is to run these “pilot light" virtual machines in vCloud Air infrastructure.This tutorial outlines virtual machines in vCloud Air Disaster Recovery that leverage Active Directory services running in a Virtual Private Cloud (VPC). Topics are as follows:

 

Watch Now

1. Use a Separate VPC

Customers commonly are concerned about where to run Active Directory and DNS components, as they are required for virtual machines to be active on failover. One option for addressing this concern is to run both in a separate VPC within vCloud Air. As shown below, the disaster recovery cloud on the right is provided for virtual machines to fail over. The cloud on the left is another VPC instance that only runs the infrastructure virtual machines. The clouds are interconnected using VPN between the Edge Gateways.

 

2. Review Settings

The option for using a separate VPC is enacted in both vCloud Air and the vSphere Web Client. The goal is to ensure that a domain member virtual machine, when failed over, can still maintain its domain membership but also communicate with Active Directory domain controllers in the cloud.

 

Review Settings in vCloud Air

 

Let's begin by reviewing domain controller settings in vCloud Air:

 

1. If you haven't already, go to https://vchs.vmware.com/login and log in to vCloud Air

2. Create a VPN tunnel between the VPC in vCloud Hybrid Service and the disaster recovery service.

  • Example: The highlighted organizations—vmtm_dot_org and 66660013-131 (designated for disaster recovery)—are connected by VPN.

 

3. Install and configure the domain controllers in the VPC.

  • Note that in this example, there are two domain controllers already running, with a domain set up in those controllers.

 

Review Settings in the vSphere Web Client

 

In this environment, a virtual machine starts as part of the on-premises domain. When it fails over to the cloud in vCloud Air, it retains its domain membership and attaches to the domain controllers in the VPC. To review related settings in the vSphere Web Client:

 

4. Log in to the vSphere Web Client.

5. On the Home tab, click the Hosts and Clusters icon.

 

6. Click the virtual machine to be failed over, and then select Open Console.

  • In this example, the desired virtual machine is vmtm-DR2C-Demo3.

 

7. From the console's Start menu, open the command prompt.

8. At the command prompt, enter echo %logonserver% to identify the logon server.

  • In this example, the logon server is Active Directory server AD01.

9. Again at the command prompt, ping the logon server (ping ad01) to display its settings. At this point, you know the following:

  • When the virtual machine is on-premises, it connects to the local Active Directory server.
  • The virtual machine is running, has an active app, and is connecting to an on-premises Active Directory server.

 



Remember that the domain controllers in the VPC are different Active Directory servers ( AD03 and AD04 in this example). They are accessible through a VPN tunnel that connects the on-premises environment to the VPC that runs the infrastructure virtual machines.

 

10. Ping the domain controllers in the VPC to verify that the on-premises virtual machine can connect to components in the cloud.

 



3. Perform the Failover

By reviewing the settings above, you have verified that there is one stream of connectivity among all of these components. Domain controllers are replicating, and virtual machines are available for all-around communication. At this point, you can fail over a virtual machine to the cloud. To perform a full failover of the demo virtual machine:

 

1. In the vSphere Web Client, navigate to the Monitor tab of the desired vCenter Server.

  • In this example, the vCenter Server is vchstm-vca01.

2. On the Monitor tab, click vSphere Replication and review the available virtual machines.

3. Click the desired virtual machine for failover, and then click the Run Planned Migration icon.

  • In this example, the failover virtual machine is vmtm-DR2C-Demo3.

 

This initiates the Planned Migration Wizard. Complete the wizard as follows:

 

4. In the Planned Migration – Source VM shutdown window, select a shutdown method, and then click Next.

  • Here you can choose the guest shutdown option with a timeout period. Five minutes is used in this example. 

 

5. In the Planned Migration – Ready to complete window, review the shutdown settings, and then click Finish.

6. Wait for failover and recovery to complete.

 

4. Examine DNS Details

Once the virtual machine has failed over and been fully recovered in vCloud Air, you can examine its DNS details within Active Directory. These details will show that the virtual machine is connected to a new domain controller and that the IP address and other settings have been updated. To examine the DNS details:

 

1. Return to the Dashboard of vCloud Air and click the virtual data center reserved for disaster recovery. 

 

 

2. On the virtual data center's Dashboard, click the Virtual Machines tab, and then click the recovered virtual machine. 

 

 

3. In the Virtual Machine Details view, click the Networks tab and verify the connection.

  • The virtual machine is connected to the recovery network, which is to be expected in any failover scenario. 

 

 

4. Power on the virtual machine: Go to the Settings tab, click the STATUS row, and then click Power On

 

 

Note: At this point, you can go to the DNS Manager and verify that the original DNS entry for this virtual machine was the on-premises subnet. You want to make sure that this gets updated to the information in the cloud, which is a different network subnet. To make sure that Active Directory gets properly updated, you can examine the local domain controller, which receives the update first.

 

It is important to note here that Sites and Services are predefined to account for different IP ranges and the sites that own those ranges.

 

 

5. Still in the Virtual Machine Details view, click Launch Console to access the virtual machine's console. 

 

 

6. Log in to the virtual machine's console.

7. From the console's Start menu, open the command prompt.

8. At the command prompt, enter ipconfig to review IP settings.

  • Here the virtual machine is attached to 192.168.185.220, which is a network on the disaster recovery cloud. 

 

9. Again at the command prompt, enter echo %logonserver% to identify the logon server.

  • This should be now connected to one of the domain controllers in the VPC. In this example, AD03 is returned as the logon server.
  • This means that Sites and Services know that the failover network is part of the remote site that resides in the VPC.
  • This machine automatically defaulted to connect to its most local domain controller.

 

10. In the DNS Manager, click the Refresh icon to see the domain controller.

11. Review the domain records for the new domain controller.

  • In this example, the virtual machine updated its IP setting to 192.168.185.220, which is part of the Windows dynamic DNS update that would happen when it registered.
  • Note that it may take time for the record to update back to the other domain controllers in Active Directory.
  • However, you now know that the update has been pushed into DNS and that the machine is running in the disaster recovery service with the correct domain controller.

 

12. Verify that the virtual machine and domain controller can communicate: Returning to the command prompt, ping the new domain controller.

  • You can tell by the rapid response time that it is a locally adjacent domain controller. 

 

13. Again at the command prompt, ping the original domain controller to verify that it cannot be reached.

 

This restriction is by design. The assumption is that the data center is no longer available because of failover due to a disaster situation.