I came across an interesting problem when renaming two of my hosts that were running Hyper-V 2008 a few days ago – I wanted to rename them from having an “SVR” suffix to a more specific “VS” to denote them as Virtual Servers.
These servers were joined to a Windows 2003 domain, where the domain controllers were virtualised on these hosts (one DC was on each of the Hyper-V boxes).
I did the usual GUI rename steps and then restarted, but then got this error when trying to log on…
The security database on the server does not have a computer account for this workstation trust relationship
After some digging around in adsiedit (actually, I was using the Attribute Editor tab available in the advanced view of the 2008 dsa.msc snap-in) looking at the attributes of the computer account, it looked like the rename didn’t quite work correctly because the servicePrincipalName attribute was incorrect. Instead of the new machine name in the entries, it was the old name, yet the computer account was renamed correctly.
I renamed the following entries…
HOST/BNE01SVR
HOST/BNE01SVR.mydomain.internal
Microsoft Virtual Console Service/BNE01SVR
Microsoft Virtual Console Service/BNE01SVR.mydomain.internal
TERMSRV/BNE01SVR
TERMSRV/BNE01SVR.mydomain.internal
…to…
HOST/BNE01VS
HOST/BNE01VS.mydomain.internal
Microsoft Virtual Console Service/BNE01VS
Microsoft Virtual Console Service/BNE01VS.mydomain.internal
TERMSRV/BNE01VS
TERMSRV/BNE01VS.mydomain.internal
…and then I was able to log in fine.
I haven’t really thoroughly investigated this issue, so I don’t know whether this is a specific 2008 thing, or whether you woud see the same thing in a 2003 setup, but my guess is that I caused this problem myself by renaming the Hyper-V boxes when they were hosting the only DC’s in the environment, and therefore the problem was caused by replication timing.
In any case, if you get this error, renaming the entries in the servicePrincipalName attribute should do the trick.