Freigeben über

Windows Server 2012 Hyper-V Replica: How Troubleshoot Kerberos Error 0x8009030C 0x00002EFE

  • Artikel

Windows Server 2012 Hyper-V Replica is a great new feature that replicates all changes on a virtual machine to a counterpart virtual machine hosted by a different server.  Basically, any server workload that’s virtualized in Hyper-V can be replicated, and it works with standalone servers, failover clusters, or a mixture of both.  As an added bonus, the servers can be physically co-located or widely separated geographically, and the physical servers do not need to be in the same domain, or even joined to any domain at all.  Great stuff, but if you run into issues what’s the best way to troubleshoot?

Dave Guenthner, one of our Microsoft Premier Field Engineers based in the US, received a call from one of his customers who was trying to evaluate and test this feature for a disaster recovery scenario.  Unfortunately, any time the customer attempted to enable this feature the following “Hyper-V failed to enable replication” exception was raised: 

Enabling replication failed Exception

Luckily for us, Dave created a blog post which walks us through his troubleshooting steps and the thought process he worked through to resolve this case.  Even if you don’t experience the exact same issue, the troubleshooting steps should still be applicable making it a great read regardless.  Check out his post here:  The Case of the Unexplained Windows Server 2012 Replica Kerberos Error : 0x8009030C 0x00002EFE.

Posted by Frank Battiston, MSPFE Editor

Comments

  • Anonymous
    January 01, 2003
    Would suggest calling Premier Support for help with the issue. From the description, I'd guess you might need to use a certificate with Subject Alternative Name (SAN) extensions specifying all possible names the client might use to access the server.

  • Anonymous
    February 11, 2013
    Really helpful - but what happens when you're trying to perform a certificate authention and have the same issue?  A write-up would be great, since we're having the same issue!  Problem is - using the internal FQDN works fine.  Using an external (So we can actually do this over the Internet) does not.  Our internal domain .local, so that obviously doesn't work for routing over the Internet.