Proxmox DC Migration Saga: Untangling an Active Directory Mess

I swear, restoring a domain controller is the IT equivalent of defusing a bomb you didn't build, blindfolded, while everyone around you yells "just rebuild it!" as if that helps when management wants it fixed now.

So picture this. A company is testing out Proxmox, feeling good about ditching VMware and saving that sweet licensing money. Everything's backed up in Veeam, all the boxes are ticked, the restore goes fine, and then the network interface card just vanishes like it never existed. No NIC means no login, no DNS, no nothing, just a broken domain controller staring back with that cold, judgmental Windows login screen. That's where this particular Proxmox saga begins.

The classic "NIC went missing" nightmare

After restoring the domain controllers into Proxmox, the team couldn't log in with the DSRM account because the NIC wasn't showing up. This classic VirtIO driver situation should have been easy. They even tried the good old DISM trick to inject the drivers manually, but Proxmox just laughed and said, "Not today, buddy."

That's when the panic sets in. When you're locked out of your DC after a restore, you have a company-wide time bomb on your hands along with the broken VM. Every authentication, every DNS lookup, and every group policy is suddenly hanging by a thread. The boss doesn't care that it's a "driver issue." All they hear is "Nobody can log in."

The "don't restore DCs" crowd shows up

You know who shows up next: the gray-bearded sysadmins who have seen too much and don't even flinch anymore. Their advice is always the same. "Never restore domain controllers. Just rebuild them."

They're not wrong, but when you're knee-deep in an outage, rebuilding is the last thing you want to hear. The logic makes sense. If you've got at least one healthy DC, restoring another from backup is asking for corruption: USNs get out of sync, SYSVOL replication breaks, and suddenly your AD forest looks like a crime scene. The right play is to spin up a clean VM, promote it as a new DC, and move the FSMO roles over cleanly. Try telling that to someone staring at a broken DC on a new hypervisor with a boss breathing down their neck about why the badge system doesn't work.

The driver issues nobody warns you about

Now, the NIC issue. It's always the NIC issue. The virtualization layer changed from VMware to Proxmox, and the new hypervisor doesn't know what to do with the old virtual NIC driver. You end up in that weird purgatory where Windows sees no network adapters at all. You mount the VirtIO ISO, try to inject drivers manually, curse a little, try again, and still get nothing.

Someone, somewhere, inevitably says: "Just use E1000, it always works." Technically, it does. The E1000 adapter is the reliable old mule of network drivers, slow and basic but guaranteed to boot. It's like using a flip phone in 2025: it won't sync your contacts, but at least you can call for help.

The real trick is to set the MAC address of the new NIC to match the old one, because Active Directory and DNS can get picky about that. Then, when you finally get in, you install the VirtIO drivers properly, switch back, and pretend it was all part of the plan.

The unspoken rule: never roll back a DC

One of the more battle-hardened admins in the conversation dropped a piece of wisdom that honestly belongs on a poster:

"The key here is NOT to roll back once the DC hits the network."

It sounds simple, but it's the number one thing people screw up. The moment a domain controller touches the network, its internal replication numbers (the USNs) move forward. If you roll back that VM snapshot or restore a backup after that point, you're rewriting history, and Active Directory hates time travel. You end up with lingering objects, orphaned replication partners, and in the worst cases a full-blown USN rollback that leaves your forest limping.

The safe play is always to do the migration "just in time": bring up one DC, let it replicate fully, run a dcdiag, and only then move on to the next. Never more than one at a time, ever.

Why management hates the right solution

The other frustrating bit is that the right solution often sounds harder. When someone suggested just building a new DC, the team hesitated because it would mean updating DNS settings on a pile of static devices like printers, scanners, and legacy boxes.

That's painful, sure. Nobody wants to touch old hardware that's been working untouched since 2012. But that pain is technical debt, and it's the stuff that breaks first when you modernize your infrastructure. Ignoring it just kicks the problem down the road until the next migration, the next restore, or the next "Why can't we log in?" emergency at 3 AM. Rebuilding DCs might sound like extra work, but it's also the cleanest way to reset that debt.

The hidden villain: VMware Tools and Hyper-V ghosts

Another admin pointed out something most people forget: before migrating, remove VMware Tools and Hyper-V integration services. Those things cling to the OS like barnacles and cause all sorts of weirdness when the VM lands in Proxmox. It's the virtual equivalent of putting a Tesla battery into a Ford truck. They're both vehicles, but nothing lines up right.

Remove the old tools, add the VirtIO drivers before migration, and your restore stops feeling like an exorcism.

Backups aren't always restorable

This is the line that stings: having a backup doesn't mean you can restore it safely.

Domain controllers are different from file servers or SQL boxes. They're living, breathing, constantly replicating machines that hate being frozen in time, and restoring one resurrects a version of your Active Directory that the rest of the forest has already moved on from. It's like cloning your friend while the clone still thinks it's 2023. Now they're both walking around insisting they're the "real one," and you can guess what happens next.

The light at the end: community wisdom wins

After the chaos and back-and-forth, the path forward became clear:

• Mount the VirtIO driver ISO.
• Manually install the drivers.
• Add a temporary NIC (E1000 or RTL8139) to regain connectivity.
• Rebuild the original NIC with proper settings.
• Test replication before bringing the next DC online.
• For the love of all that's holy, don't restore a DC again.

None of it was magic, just collective experience of the kind that comes from breaking things and fixing them the hard way.

What this saga really teaches

The big takeaway has less to do with Proxmox, Veeam, or VirtIO than with understanding what a domain controller is. A DC is a cornerstone of your identity infrastructure, and treating it like a regular backup-and-restore workload is asking for pain.

When you move hypervisors or change environments, rebuild your DCs cleanly, migrate roles properly, validate replication, and update DNS. Yes, it's tedious, but it's the only way you'll sleep soundly after the migration dust settles.

When your DC breaks, everything goes down with it. The printers stop printing, the logins stop logging, and the office coffee machine suddenly needs a password nobody remembers. Rebuilding is annoying, but it's the kind of annoying that saves you from a career-ending outage.

The final word

In the end, the Proxmox migration worked. The DCs were back online, the VirtIO drivers finally behaved, and the company learned the hard way that you can't shortcut domain controllers.

Proxmox is great: lightweight, open-source, and powerful. Active Directory doesn't care how cool your hypervisor is, though. It just wants clean replication and stable networking, and if you try to outsmart it with a quick restore and a Hail Mary DISM command, it'll happily remind you who's boss by locking you out of your own network.

So the next time someone says, "We'll just restore the DC, it'll be fine," do yourself a favor. Slam your coffee down, look them dead in the eye, and say:

"We rebuild. Or we die trying."