I am now the proud father of my first hotfix to be accepted and make it all the way to release.
http://support.microsoft.com/kb/2659158
We were alerted to the problem as we began our rollout of RODCs. Any new Windows 7 clients deployed at the site were bricks. The staging process would complete successfully but it wouldn’t let you log on. It would display the error “The security database on the server does not have a computer account for this workstation trust relationship.”
We had a tough time starting to triage the problem because the client build ends with a lockdown of BitLocker being applied and a scramble of the local admin account. So we couldn’t get on to the box to look at any logs. We had to throw some hooks into a custom build to keep control of the client. Eventually we were able to track it down to a Kerberos problem where the machine joins with a contiguous name, even though it was locally configured to have a disjoint name. With the RODC covering the site the machine was unable to correct its invalid dNSHostName that it put into AD (the client would issue an LDAP write, the RODC would correctly respond with a referral, but the client would never chase it). If covered by a writeable DC, the client was able to silently change its name at first reboot so the machine logon works (the RWDC accepted the LDAP write to dNSHostName).
The hotfix corrects the issue by having the client join to AD initially with a valid, disjointed, dNSHostName value so that an RODC never receives a copy of a new computer account with an invalid dNSHostName.
Posts
