- Server: SBS 2011 + Exchange 2010 v14.03.0382.000
- Workstation: Windows 8.1 Pro
When my boss went on vacation, he wanted to access our SBS 2011 server remotely in order to check his Exchange eMail and access certain files. Because he was going to be in a foreign country with poor Internet access, he did not bring along any electronic devices, and was going to be checking everything from Internet kiosks.
In order to reduce the chance of a successful exploit of his password (kiosk keylogger, etc.), we agreed to implement rotating passwords. We changed his account to the first one just as he was leaving, and every time he checked his stuff he would fire off an eMail to me for me to switch his password to the next one in the sequence. This actually worked wonderfully, as I was typically able to switch the password within 10-30 minutes of him finishing what he had to do.
The problem arose when he came back. Suddenly, he is no longer able to log onto his workstation, despite having his original password back on his account. The workstation throws up the following error message:
The security database on the server does not have a computer account for this workstation trust relationship
To be specific, we have only changed the password. We have done so through the SBS 2011 Standard Console, which provides a way to change passwords through a simple GUI. This changed it for both his Remote Web Access as well as the Exchange Web Access.
We have checked out this solution, but both attributes listed show the correct domain entries for the physical computer in the domain.
We have also checked out this solution, but while it shows what needs to be done, it provides no instruction on how to do it. It’s obviously a high-level doc that only provides a 10,000ft overview, and not a nuts-and-bolts instruction set. Plus, the three causes make no sense from our perspective - all we did was change a password on the server-side, leave the workstation shut down for a week, and bam -- user could not log in anymore.
My boss has shut down his system many times in the last six months, including as recently as a week prior to his vacation (he took his workstation out to a client), and this never happened.
Several interesting issues:
- This error is supposed to happen with Windows Vista or Windows 7 workstations, I have yet to stumble across an example of a Win8,1 workstation experiencing the same problem.
- There is only the primary domain account on the workstation, we cannot make use of a non-domain account (to switch Windows over to workgroup and back to domain) because none exists for the workstation. And because we cannot log in, we cannot create a local user.
- This system has a UEFI BIOS, and so none of my usual open-source bootable utilities that could resurrect a disabled Administrator account would be able to boot on this system because they all require a traditional BIOS to boot (I have run into this problem before on UEFI systems).
- During his vacation, his workstation was completely shut down (or so I was told). It did not boot up, as he came back home to it still shut down. So from the time he logged out prior to going on his holidays, to the moment he came back and fired it back up, there were no instances of the same machine name on the domain.
Any help would be greatly appreciated.
We are taking a stab in the dark, in assuming that the computer was set up with the same local username as what exists on the domain, but when we try to log onto localhost using that username (localhost\username), we get the exact same message as above. When we disconnect the network, we get the following error message:
There are currently no logon servers available to service the logon request
My boss just told me that when he got back and turned his machine back on, he was able to successfully log on initially, but that there was no networking and that there was a demand to restart the computer. When he restarted, he ran into this issue upon next login.