locked
Problem synchronizing changed passwords on WHS and PCs “The password is incorrect. Please retype your password. Letters in passwords must be typed using the correct case.” RRS feed

  • General discussion

  • I offer this as a possible additional bit of data for anyone who has been prompted by the WHS Connector software to update the password on the client computer and then been greeted by the obviously wrong and very annoying “The password is incorrect.  Please retype your password.  Letters in passwords must be typed using the correct case.”

    I think that I have found one variable that no one else has addressed; time.  To be clear, I tried every variation in password changes and change techniques and was greeted by the same error message each time except on the first account I had re-passworded many hours previously and lo-and-behold, the Console password update utility very happily agreed that the password offered on the client and the password held on the WHS were the same.  I knew this, but I'd been going crazy trying to convince the WHS console to agree that the passwords matched.

    Here's a summary of what I tried and proved fruitless:
    Case 1
    1)  Changed user X password on WHS to "A"
    2)  Immediately logged in on a client as user X and allowed the password update utility to run
    3)  Elected to use the password as on the WHS, typed "A" in the correct field
    4)  Received the error message “The password is incorrect.  Please retype your password.  Letters in passwords must be typed using the correct case.”

    Case 2
    1)  Changed user X password on client to "A"
    2)  Immediately logged out and then back in on client as user X and allowed the password update utility to run
    3)  Elected to use the password as on the client, typed "A" in the correct field
    4)  Received the error message “The password is incorrect.  Please retype your password.  Letters in passwords must be typed using the correct case.”

    Case 3
    1)  Tried looking at "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys" and giving full access to Administrators.
    2) Retried case 1 and 2 with one success.
    3)  My one success was on the first account I had tried to update many hours before.  User X's password update worked perfectly.

    That is when the lightbulb came on dimly.  I started to think that the time it takes for a password to propagate must have an impact on what I was trying to do.

    As a test, I changed user Y's password to "B" on the WHS and left everything alone for an hour.  I then logged in to a client, which I had not looked at "C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys" and given full access to Administrators. and the password udpate utility was very happy and agreed that the password I was typing into the field was the same as it expected.

    I changed the other user passwords on WHS, came back the next morning and updated all of the passwords on all of the clients without any further problems.

    I know that this is not scientific at all, but I thought it interesting that simply allowing time for the password change to propagate on WHS seemed like the only common theme in any of the successes I enjoyed.  Whenever I changed a password on the WHS Console and then immediately logged in as the user on the client the password udpate failed.

    I'd be happy to answer any questions and please also let me know if I'm wrong.  I want to learn more about this so that I can help my friends be happy with WHS.

    Regards,
    Michael

    Saturday, February 28, 2009 3:59 PM

All replies

  • It is more than a year since this was posted and not one response. I am having this same issue listed above. I know I am not at fault with entering passwords, so something is wrong with the Update Password program. Anyone know of a solution?

     

    -Tim

    Monday, April 19, 2010 1:24 AM
  • Are the times on your server and client PCs correct?
    --
    Tuesday, April 20, 2010 12:40 PM