Solved – Intune OOBE Password Reset issue ‘Your password was successfully updated, but our servers take a little time to catch up’

Initial Issue

I ran into this issue as part of an autopilot device deployment for a user who had the “User must change password at next logon” box checked.

When running through the initial device setup, the above ‘error’ message is shown once the password is reset. As stated the password is successfully reset but the device must either; be restarted and logged into again with the new password, or the user must wait a few minutes and then reset the password again to continue past this screen.

As you can imagine this isn’t exactly a smooth user experience, and since this is usually a new employees first impression of IT, it was one I was keen to find a resolution to.

Troubleshooting the issue

As part of my initial troubleshooting I came across some posts online that helped point me in the right direction. One of these posts suggested turning off Password Hash Synchronisation in Azure AD Connect.

Whilst this works as a solution, given the benefits of having Password Hash Sync enabled I did not want to go down the route of turning this feature off. Benefits of having Password Hash Sync enabled include using the same password to log onto Azure AD services and on prem systems, and a really useful feature called Leaked Credential Detection where Microsoft will flag a user account as high risk if they find out that the users credentials have been leaked on the dark web.

The solution to the issue

Through troubleshooting this issue, I realised that the issue was only present on accounts where the “User must change password at next logon” box was checked at the moment the account was created. On accounts where I waited until the account had synced to 365 and a license had been applied to set the “User must change password at next logon” option, the password reset was successful on the first attempt and device setup could continue on uninterrupted.

Further investigation on this solution leads me to believe that this solution relies on the initial sync to 365 to be completed, and a full password sync allowed to run after the change password option is set for this method to be successful.

An odd issue to run into but in the end I was happy to have figured out a fix to keep the user on-boarding process as streamlined as possible.

Leave a Reply

Your email address will not be published. Required fields are marked *