Why restoring one VM does not prove you have a directory service
In almost every Windows landscape the domain controller is the system the others depend on. That is precisely why restoring it as a single virtual machine says little about whether sign-in and dependent services will work afterwards.
A directory service is not a single server
In a backup, a domain controller looks like any other virtual machine. It can be written back, it boots, the operating system reports for duty. From that observation people often conclude that Active Directory has been restored. The conclusion is understandable and still falls short.
A working directory service is an interplay of several conditions. Name resolution has to be right, because clients and services find the controller through DNS. The time has to be right, because authentication depends on it. Where several controllers are involved, their relationship to each other matters. And the services that want to authenticate — databases, application servers, file services — have to reach the controller at the right moment.
None of those conditions is checked by a restore. You check them by starting the environment and signing in.
What is needed besides the controller
These are the points that decide whether a started machine becomes a usable service.
Name resolution
Without working DNS, clients and services cannot find the directory service — regardless of whether it is running.
Time
Authentication depends on time. If the clock in the restored environment is off, sign-ins fail for no visible reason.
Start order
Services that start before the directory service run into errors. The right order is operational knowledge that goes missing when it matters.
Several controllers
Where several controllers are in use, their relationship to each other is part of the service — not just the individual machine.
Service accounts
Applications authenticate with accounts that may be tied to particular systems. If a binding is missing, the application does not start.
Names and certificates
Hard-coded names, addresses and certificates cause no trouble — until the environment has to be rebuilt.
As part of the landscape, not as a single piece
That is why a domain controller is not restored in isolation in the Recovery Lab but as part of the agreed system landscape: together with the systems that depend on it, in the start order you specify, in a network that has been recreated.
We do the restoring and the starting. Checking whether sign-in, group memberships and dependent services behave as expected is done by your administrators themselves in the isolated environment — they know what the correct state looks like.
Whether your directory structure can be represented sensibly in an isolated environment depends on how it is built and is clarified before the test. We tell you in advance what can meaningfully be tested in your particular setup — and what cannot.
The controller comes back alongside the systems that need it.
Directory service and name resolution first, then the services that depend on them.
Your administrators sign in to the isolated environment and judge the result.
Whatever sticks in the test is exactly the information that would be missing in an emergency.
Frequently asked questions about Active Directory recovery
Is restoring a domain controller from backup enough?
For the statement „the VM is back“, yes. For the statement „sign-in works“, no. A directory service is not a single server but an interplay: name resolution, time synchronisation, replication between several controllers, and the services that rely on all of it. Only when those parts run together is the service really back.
Is Active Directory restored and started in the Recovery Lab?
Domain controllers can be restored and started as part of the agreed system landscape, like any other server. Whether your directory structure can be represented sensibly in the isolated environment is something we clarify before the test, against your actual setup.
Who checks whether user sign-in works?
You do, in the isolated environment. We restore and start the systems; whether sign-in and dependent services behave as expected is for your administrators to judge. They know what it should look like — we only know how it started.
Why does the start order matter so much?
Because many services will not start, or will run into an error state, without a reachable directory service and working name resolution. Start the database and application server before the domain controller and you will see errors that have nothing to do with the backup. In a real emergency that order is exactly the knowledge nobody has — the test makes it explicit.
What do people typically learn from a test like this?
Usually something about dependencies nobody had documented: a service account tied to a particular server, an application with a hard-coded IP address, a certificate bound to a name. Points like these are harmless while the environment stands — and laborious when it has to be rebuilt.
More on this: Proxmox recovery for restoring the machines and disaster recovery test for the test plan and ordering. Overview in the Recovery Lab.