none
Change a password problem "The security database on the server does not have a computer account for this workstation trust relationship" KB2883201

    Question

  • I was advised I might get a better response for my issue on this forum instead of the windows 8.1 IT Pro

    The original post was :-

    Hi

    I'm having a strange problem with all of my companies Windows 8 Enterprise , Windows 8.1 Enterprise ,Windows Server 2012 R2 Datacenter and Windows Server 2012 Datacenter machines but not with Windows 7 SP1 Enterprise.

    We are getting the error below when a user goes to do a "change a password". Let me make it clear that this error only occurs when trying to change a password they can quite happily logon (Or Sign in as its now called) and browse the domain open outlook etc so the trust relationship is intact.

    Error

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

    We have a small domain that has two DC's DC1 & DC2 it is at the "Windows Server 2008 R2" functional level with the schema level at 56 (We ran the adprep for Windows server 2012 but we do not have any windows server 2012 domain controllers).

    All the DC's and workstations have the same time and running DCDIAG  on each DC doesn't reveal any failures.

    Can anyone help

    Thanks

    Update I've just built a Windows 8 virtual machine activated it and joined it to the domain and it will allow a password change without the above error. At the moment it hasn't been updated with windows updates so I am going to add the SCCM 2012 SP1 agent to bring it under management and test it again, I'll keep you posted

    I'm still installing windows 8 updates 20 at a time then testing the change a password on a virtual machine and a physical laptop so far no error. As you can see below when testing the problem machines the secure channel checks out ???  Anyone or is this posted on the wrong forum?

    Update - I managed to reproduce the error it was caused by the Windows RT, Windows 8, and Windows Server 2012 update rollup: October 2013 KB2883201

    I uninstalled it on a couple of windows 8 machines and hey presto! "Change a Password" works without the workstation trust relationship error

    Can someone from Microsoft comment on this!!

    Update 4/11
    Just notice in the KB2883201 article that a prerequisite of installing the update rollup is that you need to have KB2771431 installed which according to my SCCM 2012 SP1 is superseded but not expired!!!! ?? 


    • Edited by Boris67 Tuesday, November 05, 2013 11:14 AM
    Sunday, November 03, 2013 4:21 PM

Answers

All replies

  • Thank You for reporting this issue.

    As part of the rollup update, I see the KB2845626 which is related to a password change issue with cached credential: http://support.microsoft.com/kb/2845626

    By uninstalling the KB, you need to be aware about the potential password change issue with the cached credentials that was reported.

    Usually, it is recommended to do testing of new updates to identify potential issues and decide if you need to go with them in the production environment or not.

    What is good is that you highlighted the problem with the identified KB. I hope that this will be escalated soon to MS developers.


    This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

    Get Active Directory User Last Logon

    Create an Active Directory test domain similar to the production one

    Management of test accounts in an Active Directory production domain - Part I

    Management of test accounts in an Active Directory production domain - Part II

    Management of test accounts in an Active Directory production domain - Part III

    Reset Active Directory user password

    Sunday, November 03, 2013 7:32 PM
  • I'm having the exact same issue with my Windows 8 fleet. Users are unable to change their password if KB2883201 is installed.

    I'm also having this issue on my 8.1 clients, but to make matters worse there doesn't seem to be an update I can uninstall to fix the issue so this is blocking my 8.1 deployment.

    Sunday, November 10, 2013 11:36 PM
  • Hi,

    we have had that issue and I did a Rollback (win8 x64 Enterprise) with a TaskSequence in SCCM2012.

    Just try the commandline: C:\Windows\System32\wusa.exe /uninstall /kb:2883201 /quiet /norestart

    Reboot required to be functional.

    Juergen

    Friday, November 22, 2013 7:46 AM
  • HI,

    Has anyone found a fix for this yet, has MS perhaps release a new KB to Resolve?

    I am also experiencing this with 8 and 8.1 clients.

    Regards.

    Thursday, November 28, 2013 7:54 AM
  • No fix yet as far as I know, but I have logged a support issue with Microsoft. I'll post the results once they finish investigating.

    It doesn't seem to be affecting everyone, there must be something about our domains that is playing a part.

    Thursday, November 28, 2013 10:08 PM
  • I have a customer that are experiencing this as well, so we will follow closely :)
    Monday, December 02, 2013 3:19 PM
  • I received confirmation from Microsoft that it is a known bug. They are working on a hotfix which should be released in January. I'll post again once it's released.

    For now, the only workarounds are:

    For 8.0 clients, uninstall the problematic update

    For 8.1 clients, use Outlook Web Access to change your password.

    • Proposed as answer by OfflineCustomer Wednesday, December 11, 2013 3:25 AM
    Wednesday, December 11, 2013 2:01 AM
  • David,

    Thanks for the update.  We're also waiting on this getting fixed up to deploy our Windows 8.1 SOE.


    Wednesday, December 11, 2013 3:17 AM
  • Hi

    Is this hotfix released for win 8.1 i have been facing issue in win 8.1 system?

    Monday, December 16, 2013 10:35 AM
  • Is there any update on this?

    Tuesday, January 07, 2014 3:13 AM
  • Has this update been released?
    Friday, January 10, 2014 10:40 AM
  • Do we know if this patch has been released yet, or if not do we know when it will be released?
    Tuesday, January 21, 2014 12:05 PM
  • February patches have been released and this bug doesn't seem to have been resolved yet?  Does anyone have any updates?  I was hoping for a January release and now we're looking at March at the earliest.

    Wednesday, February 12, 2014 1:06 PM
  • Any news?
    Monday, February 17, 2014 1:56 PM
  • There was an hotfix released the 14th of Feb.
    It should be applied to the DC's.

    Domain users cannot change or reset their passwords using Windows 8.1 clients
    http://support.microsoft.com/kb/2910686

    I haven't had time to test this hotfix yet, so I cannot validate it works.

    • Proposed as answer by Scott - IP1 Tuesday, April 01, 2014 12:06 AM
    Wednesday, February 19, 2014 2:39 PM
  • Restart required :( Did anybody test this hotfix?

    Without DC restart I still cant change my password

    Changing password from Outlook Web Access was successful


    • Edited by devril_admin Thursday, February 20, 2014 8:54 AM
    Thursday, February 20, 2014 8:40 AM
  • Yes, DC needs reboot after applying the hotfix.

    I have now verified that password change works on Windows Server 2012, Windows Server 2012 R2 as well as Windows 8.1 after the hotfix KB2910686 is installed on the domain controllers.

    I haven't experienced any problems with the DC's in my environment after applying the hotfix (sofar - touch wood :-) ).

    Friday, February 21, 2014 2:46 PM
  • Yes, DC needs reboot after applying the hotfix.

    I have now verified that password change works on Windows Server 2012, Windows Server 2012 R2 as well as Windows 8.1 after the hotfix KB2910686 is installed on the domain controllers.

    I haven't experienced any problems with the DC's in my environment after applying the hotfix (sofar - touch wood :-) ).

    At this time there is still no fix for those still running a 2003 R2 functional level domain with only 2003 domain controllers.
    Monday, March 10, 2014 3:26 AM
  • KB2910686 has now resolved this issue for me.

    I hadn't removed any of the the other hotfixes as it was only impacting a few machines and I had just been "rejoining" them to the domain to resolve. After applting the hotfix though the issue has stopped happening.

    Tuesday, April 01, 2014 12:08 AM