As Active Directory, its Domain Controllers and their inner workings were originally designed in the late 90s, some of the technologies and processes can be somewhat incompatible with technologies and ways of work that were introduced since.
I haven’t stumbled upon physical Domain Controllers in a while, so I guess I can conclude that Virtual Domain Controllers are common place, these days. Server Virtualization solutions like Hyper-V and vSphere were introduced after the inception of Active Directory. Although Microsoft provides features like Virtualization Safeguards since Windows Server 2012, some actions and configurations can still bite you in the behind. Creating backups of virtual Domain Controllers using software that runs on the virtualization host, or through the virtualization host is typically a tricky aspect of the Active Directory continuity process.
I work with the latest Altaro VM Backup and I have some tips for you.
About Altaro VM Backup
You may have already heard of Altaro, part of Hornetsecurity Group. Most Microsoft-oriented IT Pros know them for their free Hyper-V Dojo and publications like the Backup Bible, but it all started with backup and restore solutions. Altaro VM Backup was originally introduced in 2011 as their third product and as its second product specifically tailored to small and medium-sized businesses (SMB). Version 8 of Altaro VM Backup is the current version.
Tips for Backing up virtual Domain Controllers
Active Directory continuity starts with creating backups of Domain Controllers.
For Domain Controllers, specifically, it means the volume shadow copy writer that are relevant to Active Directory are used to create ‘cleanly shutdown’ backups of the Active Directory database and logs, when the requirements are met.
Tip! Check the VSS Settings in Altaro VM Backup
Only when Application consistent backups are created, Altaro VM Backup creates backups of Windows-based virtualization guests (OSs) automatically using the guest’s relevant Volume Snapshot Service (VSS) in addition to the host-level checkpoint.
Admins can configure settings in Altaro VM Backup to use VSS writers to create Application Consistent backups. This is a configuration you absolutely want when creating backups of virtual Domain Controllers. Luckily, in Altaro VM Backup, the only thing you need to do is put a check in the Application Consistent column for each virtual Domain Controller. You find these settings under VSS Settings in Altaro VM Backup.
Tip! Check the VMware Tools
To offer the best integration between the virtualization host and guests, VMware offers VMware Tools. Similarly, Hyper-V offers Integration Components (ICs). Hyper-V’s ICs come with the Windows Server Operating System (OS) and are automatically kept up to date through Windows Update. VMware Tools, however, need to be installed inside the virtual guest and require somewhat more effort to keep up to date.
It is easy to forget to install the VMware Tools on virtual Domain Controllers. It is easy to not have the latest VMware Tools on virtual Domain Controllers. Don’t make these mistakes, as application consistent backups rely on them.
Tip! Check the VSS writers
When you create a backup of Domain Controllers using the relevant VSS writers, an event is logged in the Event log. This event has event ID 1917 with source ActiveDirectory_DomainService and is recorded in the Directory Services event log (underneath Application and Services logs).
When Active Directory-aware backups do not occur, you can check the relevant VSS writers for errors:
- The NTDS VSS writer should report no errors
- The DFS Replication VSS writer should report no errors
Both writers can be checked with the following line of code in an elevated Command Prompt (cmd.exe) window on a (virtual) Domain Controller:
vssadmin list writers
The output of the command lists all the VSS writers on the system. The relevant VSS writers are among them.
Tip! Backup to a location outside of the reach of Active Directory
One of the other mistakes I see admins make is to write all domain controller backups to a (networking) location that is governed by access control lists (ACLs), filled with Active Directory principals.
When Active Directory is unavailable, that location is unavailable, because you gained access to it through one or more Active Directory group memberships. Make sure you create backups of Domain Controllers in locations, whose access is not governed by Active Directory or IPSec. Then, make use of the Offsite Copies functionality in Altaro VM Backup to create secondary copies of your backups.
Tips for Restoring virtual Domain Controllers
When restoring Domain Controllers from previously created backups, the proof is in the proverbial pudding.
Tip! Do not use the granular restore functionality
Altaro VM Backup offers granular restore functionality. It sounds great to just restore the registry, just the system volume (SYSVOL) or just the ntds.dit from backup to restore a Domain Controller to a previous state.
However, this is not supported from an Active Directory point of view. Altaro VM Backup supports granular restores for file servers and Exchange Servers, but not Active Directory users, computers, groups, gMSAs, Organizational Units (OUs) and/or Group Policy objects.
When restoring a virtual Domain Controller using Altaro VM Backup, restore the entire Domain Controller. Then, in Directory Services Restore Mode (DSRM), configure how to restore Active Directory to a previous point in time.
Tip! Do not use the Replication functionality
Altaro VM Backup offers replication. While this may seem like a good idea, for virtual Domain Controllers this feature usually isn’t a great idea to use. Just like with VMware’s Site Recovery Manager, replicating virtual Domain Controllers only serves a couple of very specific scenarios. In most of these scenarios, to avoid FSMO role ownership changes, DNS time-outs and keeping DCCloneConfig.xml files up to date, having a fully functioning always-on Domain Controller in a fail-over site provides more benefits and ease of mind. Even though, it is supported to replicate Domain Controllers.
Tip! Perform test restores of Active Directory
When Active Directory is unavailable, a networking environment is severely crippled. In a past survey, Exchange admins estimated they’d lose their jobs when mail is unavailable for three days. You can bet Identity admins lose theirs even faster.
Therefore, it is important to perform test restores of Domain Controllers. Don’t just check whether you can restore one Domain Controller, but also test restoring all Domain Controllers for an Active Directory domain and also test restoring the entire Active Directory forest. When push comes to shove, you’ll be glad you did; You’ll know you can actually restore the backups you diligently made and you’ll know what to do as you’ve seen it all before.
Tip! Test restores of Domain Controllers are specific
Test restores of virtual Domain Controllers have specific demands. You will need to make absolutely sure that the restored Domain Controllers is in a completely separate networking environment.
Additionally, you will want to make sure any Azure AD Connect installations, Azure AD Connect Health agents, Azure AD Password Protection agents and Microsoft Defender for Identity sensors do not have access to the Internet to avoid causing unnecessary alerts, resulting a minor nuisance, and to avoid synchronizing changes you intend to make only for test scenarios, which may become a huge pain in the behind.
Altaro VM Backup is a neat solution to backup and restore Active Directory Domain Controllers.
By default, the product doesn’t create Application Consistent backups. Make sure to enable the feature in the management interface for your virtual Domain Controllers.
Also, the product doesn’t offer granular restores of objects in Active Directory. However, in most organizations, the Active Directory Recycle Bin offers sufficient functionality to provide continuity to user objects, computer objects, groups and/or OUs.