In part one of this series, we used Azure Backup to enable a daily backup schedule on two Domain Controllers, one from each domain in the Active Directory forest. A few days have passed since Azure Backup was configured. Multiple backups (restore points) should be available for each of the Domain Controllers.
In this post, one of these recovery points will be used to restore the forest root Domain Controller in an Azure isolated virtual network (VNET), while having no impact on the production environment. We should be able to successfully logon to this Domain Controller after the restore, to perform the remaining Active Directory recovery steps.
Articles in this series:
Part 1 | Part 2
Selecting the restore point
The backup status for the Virtual Machine (VM) can be accessed from the Backup option on the VM menu in the Azure portal. The list of restore points for the last 30 days will be listed here.
Consider the timeline of the failure when deciding on which restore point to use. The goal is to recover Active Directory with the least amount of data loss. Any changes to AD after the restore point will be lost. You might find that deleted objects are no longer deleted, created objects are no longer present.
Use an Application Consistent backup whenever possible. An application consistent backup was performed when the VM is online and will ensure that the VM boots up with no data loss or corruption, and the applications (such as Active Directory) will start in a consistent state. Crash Consistent are backups performed while the VM is offline (shut down). More details on backup consistency can be found here.
Requirements
Two options are available when restoring a VM:
- Replace existing which will overwrite the current VM
- Create new which will create a new VM which doesn’t affect the state of the current VM.
For the Active Directory forest recovery, we would need to create a new VM.
There are a few requirements when using Replace existing. These requirements cannot be created during the restore process, thus we need to create them before attempting the restore. The basic requirements are as follows:
- Resource group
- Virtual network
- Subnet
- Staging location
Resource group
You can use an existing resource group or create one specifically for the DR operation. I prefer to use a new resource group as this allows me to easily clean up all resources after a DR test was completed. Deleting the resource group will delete all the resources within the resource group, no need to find and delete individual resources.
Virtual network and subnets
The virtual network address space should not overlap with your production network. Active Directory forest recovery is performed in an isolated network, but in a real disaster, the end goal would be to reconnect the recovered Domain Controllers to your production network. This allows the redeployment of Domain Controllers in all your production sites. This may not be as important when only performing a DR test, but it’s best to keep the steps for a test recovery as similar as possible to the real-world recovery steps.
It would be best to plan this with the network team as you should consider any additional requirements such as gateway subnets, bastion subnets and any network security groups. Inbound and outbound connectivity to the internet should be prevented during recovery. Also plan for Remote Desktop connectivity to the recovered server without exposure to the public internet.
Below is an example of what I’ve used for this recovery. It’s a large address space and subnet which may be a waste of many IP addresses in a normal corporate network. It serves the purpose in my lab environment and should at least get you started with your first Active Directory recovery test.
I’m also creating a Azure Bastion subnet to provide Remote Desktop connectivity to the virtual machines within this VNET.
Staging location
The staging location is just a storage account in Azure that will be used as a temporary location during the restore. The storage account should be created in the same region and subscription as the Azure Recovery Services vault. Blob storage and Zone-redundant Storage (ZRS) is not supported. Create a StorageV2 storage account with Locally-redundant storage (LRS).
Restore VM
With all the requirements in place, we can start with VM recovery.
Select Restore VM from the Backup menu of the Virtual Machine to be restored:
Select the Restore point for the backup. Select the appropriate Application consistent backup for the recovery. I am using a backup from two days back. We should eventually be able to recovery up to 60 days based on the backup policy configured in part 1 of this series.
Select all the required resources as created earlier. You cannot create any resources directory from this blade. Notice I have given my VM a different name. This is to distinguish the recovered VM from the production VM in the Azure portal. The actual server name configured in Windows will not be changed. Select Restore at the bottom of the blade to continue.
The restore has been triggered successfully. Click on the highlighted item to monitor progress of the restore.
You can also view all jobs from the VM backup blade:
We need to wait for the restore to complete. The last two backup jobs took 3 – 3.5 hours to complete. We will find out how long the restore job takes.
Document this in your DR documentation as this influences the time required to complete a full forest recovery. This helps set business expectations for recovery time.
Select the restore job for detailed information on the progress
Restore completed in about 44 minutes
Review recovered VM
Go to the Virtual Machines blade in Azure. I now have the original Domain Controller (DCS002-001) running and also the newly recovered version of the Domain Controller (DC-ForestRoot) in the list. We have now successfully recovered the production Domain Controller in an isolated VNET without affecting the production environment. They are in different resource groups, with different IP and subnet configurations.
I can now attempt logging onto the recovered Domain Controller using the built-in domain administrator account.
I’ve successfully logged onto the Domain Controller. I can confirm that I am logged on with the administrator account, the Domain Controller name is still DCS002-001 but the IP address is from the DR subnet that I created. I can also see the last successfully replication was two days ago, just before the daily backup was completed.
No replication will occur as this is now the only available Domain Controller due to the virtual network configuration. Replication is currently failing due to a DNS lookup failure. That is because I have not configured any custom DNS settings on the DR VNET or on the Virtual Machine network interface.
Additional tasks
Assign a static IP address to the VM and configure DNS on the network interface to point to itself, the loopback address 127.0.0.1 should be sufficient to complete the Active Directory recovery procedures. Refer to the Active Directory Forest Recovery Guide for information on how to complete the Active Directory forest recovery.
Continue with the restore and recovery of any child domains after the root domain is complete. Always start with the parent domain and work your way down the forest structure.
Clean up of Azure resources
When you have completed the Active Directory DR test, the resources used during the test can be easily deleted. In a real DR situation, the recovery site should be connected to the production site instead of being deleted.
To delete the Azure resources, open the resource group in the Azure portal and select Delete resource group. All the resources within this resource group will also be deleted. Remember to create all DR test resources within the same resource group to simplify the clean up steps.
You will be prompted to enter the name of the resource group as confirmation before the Delete option will be made available.
Enter the name and select Delete
It will take a few minutes for the resource group and contained resources to be deleted.
Summary
This post showed the high level steps of restoring a Domain Controller to an isolated VNET in Azure. This will allow you to perform Active Directory forest recovery without affecting your production environment. With Azure Backup you don’t require any on-premise infrastructure to complete the DR test, and resources can be easily deleted when complete.
Restoring the Domain Controller is only the initial steps in a full forest recovery plan. Refer to the Active Directory Forest Recovery Guide for the Active Directory tasks that should be performed during a forest recovery.
This method of using Azure can initially be used for DR testing, and further adapted for a full Active Directory disaster recovery plan, which can be used in a real world disaster situation.
References
Active Directory Forest Recovery Guide | Microsoft Docs
AD Forest Recovery – Perform initial recovery | Microsoft Docs
Restore VMs by using the Azure portal – Azure Backup | Microsoft Docs
Manage resource groups – Azure portal – Azure Resource Manager | Microsoft Docs
Series
Use Azure Backup for Active Directory forest recovery requirements | Part 1
Use Azure Backup for Active Directory forest recovery requirements | Part 2
Active Directory Recovery Execution Service (ADRES)
Do you require guidance or support with your Active Directory Disaster Recovery plan? Contact your Microsoft Account Representative for further details on our Active Directory Recovery Execution Service.
Overview
Review common disaster recovery scenarios, determine the risks posed to your business, and execute the steps needed to recover from disaster. A Microsoft Engineer will work with you to create and test Active Directory recovery plans for forest recovery. This will significantly reduce the time it takes to recover from disaster scenarios impacting your Active Directory environment.
You must log in to post a comment.