Back to Blog
    Proxmox
    Active Directory
    Migration
    VMware
    Domain Controller
    Networking

    The Proxmox DC Migration Saga: How Proxmox Community Untangled One Company's Active Directory Mess

    November 5, 2025
    9 min read
    I swear, restoring a domain controller is the IT equivalent of defusing a bomb you didn't build - while blindfolded - and everyone around you is yelling "just rebuild it!" like that's somehow helpful when management wants it fixed now. So picture this: you've got a company 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 boom - the network interface card just vanishes. Like it never existed. No NIC, no login, no DNS, no nothing. Just a broken domain controller staring back at you with that cold, judgmental Windows login screen. And 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 using the DSRM account because the NIC wasn't showing up. Classic VirtIO driver situation - except it 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. Because when you're locked out of your DC after a restore, you don't just have a broken VM - you've got a company-wide time bomb. Every authentication, every DNS lookup, every group policy is suddenly hanging by a thread. And 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. They don't even flinch anymore. Their advice? Always the same: "Never restore domain controllers. Just rebuild them." And they're not wrong - but when you're knee-deep in the middle of 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. But tell 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. So now you're stuck 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 nothing. Someone, somewhere, inevitably says: "Just use E1000 - it always works." And yes, technically, it does. The E1000 adapter is that reliable old mule of a network driver - slow, 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 should honestly be printed 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 - those USNs - move forward. If you roll back that VM snapshot or restore a backup after that point, it's like rewriting history. And Active Directory hates time travel. You end up with lingering objects, orphaned replication partners, and in 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. Never. --- ## Why Management Hates the Right Solution Here's the other frustrating bit - 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: printers, scanners, legacy boxes, you name it. And yeah, that's painful. Nobody wants to touch old hardware that's been quietly working since 2012. But here's the thing - that pain is technical debt. 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. So yeah, 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 trying to install a Tesla battery into a Ford truck. Sure, they're both vehicles, but nothing lines up right. Remove the old tools, add the VirtIO drivers before migration, and suddenly your restore doesn't feel like an exorcism. --- ## The Hard Truth: Backups Aren't Always Restorable This is the line that stings: just because you have a backup doesn't mean you can actually restore it safely. Domain controllers are not like file servers or SQL boxes. They're living, breathing, constantly replicating machines that hate being frozen in time. Restoring one means resurrecting a version of your Active Directory that the rest of the forest has already moved on from. It's like cloning your friend, and the clone still thinks it's 2023. Now they're both walking around, insisting they're the "real one." Guess what happens next? Chaos. --- ## 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. It wasn't magic. It was just collective experience. The kind that comes from breaking things and fixing them the hard way. --- ## What This Saga Really Teaches The big takeaway here isn't about Proxmox or Veeam or VirtIO. It's about understanding what a domain controller really is - and what it isn't. It's not just another VM. It's a cornerstone of your identity infrastructure. 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. Update DNS. Yes, it's tedious. But it's also the only way you'll sleep soundly after the migration dust settles. Because here's the thing - when your DC breaks, it's not just one system down. It's everything down. The printers stop printing. The logins stop logging. The office coffee machine suddenly needs a password nobody remembers. So yeah, 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 a lesson the hard way: you can't shortcut domain controllers. Proxmox is great - lightweight, open-source, powerful - but Active Directory doesn't care how cool your hypervisor is. 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."