Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Saturday, May 11, 2019 4:47 PM
Running 1809 on a domainjoined laptop. After the update from 1803 to 1809 tha unlock is very slow, 30 seconds.
It's the same on corp net and internet. If I activate airplane mode the unlock is instant.
Any tip on where to look?
/Frode
All replies (12)
Wednesday, May 22, 2019 1:22 PM âś…Answered | 1 vote
An update on this issue, the issue is somehow connected to mapping of home folder. Further, AD remove - rejoin solves the problem on the specific machine.
Also found that this might be AAD related, a tip on Reddit suggests that 'dsregcmd /debug /leave will fix the issue.
Link to reddit:
https://www.reddit.com/r/sysadmin/comments/avpxce/windows_10_1809_unlocking_desktop_issue/
Monday, May 13, 2019 6:35 PM
A little update. We see this problem on several PCs. All have been updated from 1803 to 1809.
The problem is solved by removing the PC from domain and rejoining.
This fix cannot be done in large scale, we have 10.000 workstations installed so we need figure out the cause of the problem.
/Frode
Tuesday, May 14, 2019 6:28 AM
Hi,
Thank you for posting in Microsoft TechNet Forum.
Do you have any policies or scripts that are set to run on unlock?
What if you log in as a local account?
Please refer to the following methods to troubleshoot:
1. Move an existing domain account to a OU that has no GPO linked to it, then log back to a machine.
2. Try with a fresh domain user with GPOs (one that never logged in before) and unlock.
3. Set the "Always wait for the network at computer startup and logon" group policy to not wait. By default, they're waiting on a DC to issue a new Kerberos ticket and download group policies.
4. Try to diagnose the delay mentioned in the following link:
https://blogs.technet.microsoft.com/markrussinovich/2012/07/01/the-case-of-the-veeerrry-slow-logons/
Hope the above information will help you.
Best regards,
Hurry
Please remember to mark the reply as an answer if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Thursday, May 16, 2019 1:12 AM
Hi,
How things are going there on this issue?
Please let me know if you would like further assistance.
Best regards,
Hurry
Please remember to mark the reply as an answer if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Thursday, May 16, 2019 6:49 AM
Hi and thanks for the information. My tech guys are still wrestling with this. We have checked out the troubleshooting tips to no avail. Currently we are monitoring traffic from/to the affected computer and comparing this to computers without the issue.
/frode
Monday, May 20, 2019 9:25 AM
Hi,
Thank you for your feedback.
What problems have you found by comparison?
I will accompany you until the problem is resolved successfully.
Best regards,
Hurry
Please remember to mark the reply as an answer if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Tuesday, May 21, 2019 1:49 PM
We found that this is somehow related to user drive mappings. AD-Users with a home folder drive letter and fileshare defined on the userobject will experience the 30 sec delay during logon or unlocking. Remove the drivemapping and unlocking is instant.
The problem disappears if the machine is unjoined/rejoined to the domain.
Every user experiencing this problem has recently upgraded to 1809.
Friday, May 24, 2019 8:30 AM
Hi,
I'm glad to hear that your problem was solved successfully.
Wish you a happy life.
Best regards,
Hurry
Please remember to mark the reply as an answer if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Thursday, May 30, 2019 11:45 AM
UPDATE
Alright, now we know the problem. Not the solution tough.
It is definitely Hybrid Azure AD machines, from build 1809 (I've tried 1803, 1809 and 1903 and only happens on 1809 and 1903).
I stopped the Synchronization Service Manager for AD Connect (syncs local AD with Azure AD).
Open PowerShell and run
Set-ADSyncScheduler -SyncCycleEnabled $false
Checked that it is actually disabled, should be SyncCycleEnabled : False
Get-ADSyncScheduler
Once is disabled
Run " dsregcmd /debug /leave " in one of the machines with slow unlock.
It works. Then wait till the next sync should have place (You get that info with Get-ADSyncScheduler). Check that the machine is no longer being added to Hybrid Azure AD. Check that the unlock is still fine.
Till we have the solution I'll leave the sync disabled.
#################################################
Things I've found out so far
" dsregcmd /debug /leave " command works great, for a while, as does removing and rejoining the machine to AD. But after a reboot or a random amount of time, the problem comes back.
It's definitely something with Hybrid Azure AD. When you run, any of the solutions mentioned above, the computer does not appeared as joined in AAD. Then the slow unlock goes away. Unlock takes a second or less.
Then when Hybrid Azure AD syncs and the computer appears again as AAD joined, the slow login is back.
Once this happens, it does not matter if the computer is connected to our corporate network, or just any internet connection, the slow login remains.
Even if you delete the machine, manually in AAD console, problem remains, unless you run one of the workarounds mentioned before. Then again, it works, till AAD joins the machine again.
Discarded problems:
If you put it on airplane mode the unlock is instantaneous.
If you use a fake DNS (no internet), but you leave the IP configuration of the corporate network (access to GPOs, Mapped drives, etc...), the unlock again is instantaneous.
So not a GPO problem, not a profile scripts or home drive problem, not a DNS problem (using google, cloudflare, etc, same thing), not a driver problem (different brand machines, same thing).
Next thing to try, stop Hybrid Azure AD sync.
Thursday, May 30, 2019 11:47 AM
Sorry, forgot to say Thank you, for the "dsregcmd /debug /leave" command. Not a definitive solution, but a really, really, helpful answer. Thanks!!
Monday, March 9, 2020 6:17 AM
Did you find a solution? we are having same issue. But for us its random, some of the users issue seems to have fixed itself.
Monday, March 9, 2020 6:52 AM
Hi, the command "dsregcmd /debug /leave" has fixed the issue for us. Not sure if this is a permanent fix, but it's the best alternative so far.
/Frode