The only domain controller died. What still works, what doesn't, and the order to bring it back

• PCs already signed in keep running on cached credentials, and so do PCs whose users have signed in before; a user who has never signed in to that PC cannot
• Microsoft 365, if password hash sync was in place, keeps signing everyone in; if the tenant was federated to the domain, it does not
• Wi-Fi on a pre-shared key keeps working; Wi-Fi or VPN that authenticated users through a policy server on the domain does not
• File shares on other servers keep working until the sign-in tickets expire, which is about ten hours, and then they start failing one PC at a time

• DNS, if the domain controller was the only DNS server the PCs and the firewall knew, which is why the whole office reports that the internet is down
• DHCP, if it lived there: nothing new gets an address, and existing addresses expire over the next day
• Group Policy, the mapped drives and printers that Group Policy delivered, and anything on the domain controller itself: the print queues, the file share, the licence service somebody put on it
• Anything that binds to the directory to check a user: the copier's address book, the VPN, the line-of-business application with Windows authentication, the door controller

If the firewall can hand out addresses and forward DNS, let it do that temporarily so people can reach the internet and Microsoft 365 while the directory is down, and write down that it is temporary, because a network left that way never rejoins the domain cleanly. Do not seize anything, do not build a new domain, and do not let anyone reinstall Windows on the dead server yet: the disks may hold the only copy of the directory.

If there is a backup, of the virtual machine or of the server's system state, restore it. For a single domain controller a straightforward restore is the right kind; nothing else holds a newer copy to conflict with. Check the backup's age first: a backup older than the domain's tombstone lifetime, 180 days by default, will not be accepted, and one older than a week means a week of password changes and new accounts to redo.

If the hardware failed but the disks are readable, a recovery of the virtual machine files or the directory database from them is worth a day of somebody's time before anything more drastic. If there is no backup and nothing readable, the honest answer is a new domain: every PC rejoined, every account recreated, every share re-permissioned, a week for a forty-person office. A company already using Microsoft 365 should ask at that point whether it wants a new domain at all, or would rather go Entra ID only and never have this week again.

1. Network first: the restored server's address, DNS and DHCP as they were, and the temporary firewall settings reversed
2. The domain controller itself, then its health checked: directory service running, DNS answering, the shared policy folder present, the clock right, because a clock off by five minutes breaks every sign-in
3. File and print, then the applications that authenticate against the domain, each tested by a real sign-in
4. Only then the PCs: a restart clears the ones that cached bad answers during the outage

• A second domain controller, a small virtual machine on a different host, with every PC and the firewall pointed at both for DNS
• DHCP moved off the domain controller, or split across both, with the scope documented
• Backups that include the system state, restored from on a schedule, with the last restore date written down
• Password hash sync to Entra ID, so that Microsoft 365 sign-in does not depend on the closet
• The break-glass domain administrator in a password manager the company owns, and a diagram of which system depends on which server

That second controller is the cheapest item on the list and the one most often skipped. It, the backup, and the diagram are the first three things the Active Directory work and the server and backup work on our Enterprise IT services page put in place.