none
The infamous "The security database on the server does not have a computer account for this workstation trust relationship" issue

    Question

  • OK, so I've got myself into a pickle with this one and everything I've read and tried seems only to make things worse.

    My scenario is I'm running a couple of hosts (Windows 7 Pro) which are running a guest Windows 7 Ultimate as part of my newly created domain with two Server 2008R2s running in a Hyper-V server core setup.

    All was working very well until I, in a rush to bring the system online, was forced to copy one VM from one machine to another without a sysprep. I know, I know I should have known better but when you've got a plant to run and a group of people standing waiting for the system to run you do what you've got to do. This scenario was OK until I deleted the copy from the second box and attempted to fire it up back on its original host.

    I've dug around on the usual sources and have reached a point where I'd really like to find the correct Microsoft documentation that will give me enough information to solve this issue in its entirety rather than just solve this one problem. The age of virtualization is here and I have no doubt that similar or related issues will crop up.

    So does anyone have a suggestion where would be the best source of information that I can use to solve this problem and know just what the heck I'm doing?

    Sunday, October 06, 2013 11:00 PM

Answers

All replies

  • >> I'd really like to find the correct Microsoft documentation that will give me enough information to solve this issue in its entirety rather than just solve this one problem. 

    Here's a MS KB reference : http://technet.microsoft.com/en-us/library/ee849847(v=ws.10).aspx

    >> So does anyone have a suggestion where would be the best source of information that I can use to solve this problem

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/9d02015b-6c41-4615-9d0c-77c8b8bb8a10/the-security-database-on-the-server-does-not-have-a-computer-account-for-this-workstation-trust?forum=winserverDS

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/a1c0bc9f-46d4-42e2-bea6-d75ccab4060e/error-the-security-database-on-the-server-does-not-have-a-computer-account-for-this-workstation?forum=winserverGP

    http://community.spiceworks.com/topic/303761-the-security-database-on-the-server-does-not-have-a-computer-account-for-this-w

    Simple fix would be, disjoin the affected computer from domain and rejoin the computer on to the domain again.


    Regards, Santosh

    I do not represent the organisation I work for, all the opinions expressed here, are my own and posted AS IS.

    Monday, October 07, 2013 3:08 AM
    Moderator
  • >> I'd really like to find the correct Microsoft documentation that will give me enough information to solve this issue in its entirety rather than just solve this one problem. 

    Here's a MS KB reference : http://technet.microsoft.com/en-us/library/ee849847(v=ws.10).aspx

    >> So does anyone have a suggestion where would be the best source of information that I can use to solve this problem

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/9d02015b-6c41-4615-9d0c-77c8b8bb8a10/the-security-database-on-the-server-does-not-have-a-computer-account-for-this-workstation-trust?forum=winserverDS

    http://social.technet.microsoft.com/Forums/windowsserver/en-US/a1c0bc9f-46d4-42e2-bea6-d75ccab4060e/error-the-security-database-on-the-server-does-not-have-a-computer-account-for-this-workstation?forum=winserverGP

    http://community.spiceworks.com/topic/303761-the-security-database-on-the-server-does-not-have-a-computer-account-for-this-w

    Simple fix would be, disjoin the affected computer from domain and rejoin the computer on to the domain again.


    Regards, Santosh
    Thanks Santosh but unfortunately I've tried all of the above fixes to no avail - still get this infamous message.

    Any other ideas???

    This is extremely frustrating!!!


    Tuesday, October 15, 2013 12:47 AM
  • Hi,

    the single most common cause of this issue, is performing the exact steps in the exact sequence you did :)

    and the single most common resolution, is what Santosh advises.

    this all assumes, that you aren't intending to re-clone, operate the clone, and then try to re-use the original source machine. because, almost every time, this will simply fail, again, for the same reason.

    a domain member computer, when you domjoin it, will negotiate and establish a secure-channel-password (often referred to as the "computer account/password").
    This password is not visible. changes to this are auto-negotiated by the domain member computer, on a periodic cycle, by default.
    when you clone a domain member, and then have that clone running for a time, you are rolling the dice, as that computer will, within 60days or so, initiate a password change, and the domain-controller will agree to that change. the clone operates for a time, using that password.
    then, you turn off that clone, and fire up the original machine, which only knows the previous password, which it supplies to the domain controller at computer startup. the domain controller objects, refusing the computer logon (not the user logon), and throws up the error you are seeing.

    the exact same symptoms frequently occur, due to the use of System Restore, since System Restore rolls-back the registry, including the computer-password.

    when you disjoin and then rejoin the domain member, you are forcing a synchronised password negotiation (reset) at the domain member and the domain controller at the same time, so the passwords are in agreement once more..

    So, when you say that you tried all those fixes, and it's still not working, could you walk us through the sequence of steps you are executing?

    (the only other time I've seen this issue become difficult to resolve, is where there are multiple domain controllers, and there are domain replication issues/delays occurring)


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Tuesday, October 15, 2013 10:22 AM
  • Firstly, thanks very much Don for taking the time to write up the reply.

    After trying the steps mentioned earlier, and what has me very confused, is that I went ahead and completely wiped (format of the hard disk, etc) the new box back to the original OEM install of Windows 7 Pro.

    While the system is very happy to allow me to join the machine to the domain with apparent ease, the moment I try and use a valid user (or even my sys admin ID) as a login it pops up the extremely frustrating error message.

    So, to recap, no cloning or VM involved, just a new PC with existing user IDs.

    Any ideas?


    • Edited by mlwest Tuesday, October 15, 2013 1:27 PM
    Tuesday, October 15, 2013 1:27 PM
  • Ok, I may have misunderstood your scenario.
    It's not a virtual machine, it's a physical machine, that has the problem?

    Do you have a single instance of this computername, or do you have more than a single computer (either physical or virtual) which is using this particular computername?

    (each computer, either physical or virtual, must exist only once. cloning and running two computers with the same name is bad. reverting to a backup/snapshot or otherwise aged copy of a machine, is fine if you are prepared to deal with stale sceure-channel-passwords)


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Tuesday, October 15, 2013 8:22 PM
  • Ok, I may have misunderstood your scenario.
    It's not a virtual machine, it's a physical machine, that has the problem?

    Do you have a single instance of this computername, or do you have more than a single computer (either physical or virtual) which is using this particular computername?

    (each computer, either physical or virtual, must exist only once. cloning and running two computers with the same name is bad. reverting to a backup/snapshot or otherwise aged copy of a machine, is fine if you are prepared to deal with stale sceure-channel-passwords)


    Don
    (Please take a moment to "Vote as Helpful" and/or "Mark as Answer", where applicable.
    This helps the community, keeps the forums tidy, and recognises useful contributions. Thanks!)

    Well, I finally solved my issue.

    I found the utility setspn in a technote that I initially didn't interpret its output properly.

    In my case it reported the two duplicate entries which included the first line that represented the machine I actually wanted to use and the second machine I brought online in my haste to get the system up. In my initial attempts I went through the motions of deleting the duplicate entries and all looked good until I retried and found the exact same problem. Sure enough I would rerun the diagnostic and it again reported the same problem.

    What I didn't at first realize is I needed to delete the second line of data from the information reported as a duplicate so as to remove the PC that temporarily hosted my virtual PC and not the first. My apologies if my explanation is a bit confusing but it makes more sense if you look at the setspn utility examples.

    Thanks Don and Santosh for your replies - I actually know how to solve this one if I see it again.


    Wednesday, October 16, 2013 5:30 AM
  • Well, I finally solved my issue.

    I found the utility setspn in a technote that I initially didn't interpret its output properly.

    In my case it reported the two duplicate entries which included the first line that represented the machine I actually wanted to use and the second machine I brought online in my haste to get the system up. In my initial attempts I went through the motions of deleting the duplicate entries and all looked good until I retried and found the exact same problem. Sure enough I would rerun the diagnostic and it again reported the same problem.

    What I didn't at first realize is I needed to delete the second line of data from the information reported as a duplicate so as to remove the PC that temporarily hosted my virtual PC and not the first. My apologies if my explanation is a bit confusing but it makes more sense if you look at the setspn utility examples.

    Thanks Don and Santosh for your replies - I actually know how to solve this one if I see it again.


    Thanks for the info :-)

    Regards, Santosh

    I do not represent the organisation I work for, all the opinions expressed here, are my own and posted AS IS.

    Wednesday, October 16, 2013 6:03 AM
    Moderator
  • Log in as system Administrator account - my computer- properties - Change settings - change - join workgroup ( remove system from domain) - restart - Log in as system Administrator account - my computer- properties - Change settings - change - join Domain again.
    Wednesday, February 12, 2014 9:38 AM