I came across an interesting problem recently. A customer is trialling child DNS domains for their server in their lab set-up, and we came across an interesting problem when changing the FQDN of the server.
In this instance, we were playing with using dcpromo to promote and demote the domain controller (DC) into a single domain. At one point, we got out of step with the reboots and got the following message when logging-in to the domain:
The Security database on the server does not have a computer account for this workstation trust relationship.
Interesting. Somehow, we managed to get the domain out of sync with the FQDN of the server. We found 3 ways to resolve this issue, 2 simple (which felt a little like a hack) and 1 that permanently fixed the issue:
- Login to the DC with local admin credentials, and in Computer / Properties: change the FQDN.local name to just the machine name, then reboot the server.
- Update the DC FQDN in the domain DNS system, so the current DC FQDN and that in the DNS server match.
- Update the computer account in the domain to reflect the FQDN of the DC. To do this:
- Open your domain Users & Computers console.
- Under View, select Advanced Features.
- Find the computer account of your DC. (Depending on what your policy is, this might be under <AD Host> / <Domain> / Domain Controllers, or elsewhere in another OU. If in doubt, use the domain search for the machine name, or ask the domain admin!
- Open Properties of the computer account, then select “Attributes Editor”. (If you can’t see it, re-check step 2 above).
- Look for attributes “dNSHostName” and “servicePrincipleName” (and anywhere else the FQDN of the DC is found).
- If incorrect (they should be – to produce the error on the DC), update them to the correct values.
- Reboot the DC and try connecting again. If the error persists, re-check the attributes in step 5 again for any missed values that need resetting. Also bear in mind that the DCs may need some time to replicate if your domain has more than one DC.
Also worth pointing out that these errors don’t always require a reboot, so if you are doing this under a change window or are limited for time then it’s possible the fix will be applied fine without a reboot. But then hey – your DCs are all virtual, so will reboot in about 10 secs anyway. Right?
Jeremy loves all things technology! Has been in IT for years, loves Macs (but doesn't preach to others about their virtues), loves virtualization (and does shout about it's virtues), and sometimes skis, bikes and directs amateur plays!