Home
Join

Some Windows 10 Domain users login taking absurdly long time

Posted by donutreply
Windows 10 Windows Server Active Directory & GPO

So we've had a few users struggle to get signed in (if they even get signed in at all). What happens is that they sign in and Windows just says "Welcome" with the spinning dots, indefinitely. We are talking times upwards of an hour. This seems to be "fixed" with a hard shut down, or reboot if they do get logged in. Afterwards everything is normal.

This seems different than having a bad profile and needing to delete and rebuild. It's only happened once for these users and then it will be fine afterwards. Whereas the bad profiles were repeated offenders. 

It's also a fairly recent problem. 2 users experienced this morning, and couple more in the past 2 weeks. As stated in the title, these are domain users, but they are not roaming.

Since it's happened so much all of a sudden, it makes me think that there was a recent update for Windows 10 or the domain controller that may have caused this.

Thoughts?

Spice (38) Reply (44)
donutreply

Popular Topics in Windows 10

Change user shell - Custom User Interface GPO not working Intune Windows 11 Feature Update Stuck in Offering State Remote re-imaging Command to run a bat file if condition applies Bitlocker Monitoring/Mangement View all topics

44 Replies

  • Possibly Group Policy issues? Are the users having the issues in the same OU and getting the same policies? 
    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down

  • wpheinle wrote:

    Possibly Group Policy issues? Are the users having the issues in the same OU and getting the same policies? 

    Yes they are all in the same OU.

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down

  • Long login times are almost always either DNS set incorrectly on the client (having a DNS Server(s) in the list that isn't a domain controller) or an issue with a Group Policy.

    Spice (13) flagReport
    6 found this helpful thumb_up thumb_down

  • Da_Schmoo wrote:

    Long login times are almost always either DNS set incorrectly on the client (having a DNS Server(s) in the list that isn't a domain controller) or an issue with a Group Policy.

    That sounds plausible, I'll have to look into that.

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • But if it is a DNS issue, even a reboot of the client wouldn't solve that?
    You would have to make a change on the client machine not only reboot it. No?

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down

  • Questions:
    1) did the users try different machine and had the same problem?
    2) other users on the same machine could login normally?

    Spice (5) flagReport
    2 found this helpful thumb_up thumb_down

  • Have just found two similar thread. Please have a read on those:
    https://serverfault.com/questions/471662/domain-login-very-slow-10-minutes
    https://community.spiceworks.com/topic/2116517-windows-10-domain-machine-slow-to-logon

    Spice (3) flagReport
    1 of 2 found this helpful thumb_up thumb_down

  • I would take note of the time when beginning the login process and review eventviewer logs with the timestamps matching the time it took for the logon process to complete. You may see that windows is configuring software, processing GPO, having trouble with DNS, or struggling to load the profile. GPO events in eventviewer will typically show processing time.

    If you don't feel like digging into logs and would rather try excluding variables then try the recommendation from chris-fr, rule out an issue with the computer by trying a known working user account on the problem computer or have the problem user login to a known working workstation.

    Spice (3) flagReport
    1 found this helpful thumb_up thumb_down

  • As an explanation for bogus DNS entries, have you done a sweep for rogue DHCP? We use a very unlikely chunk of private network addresses, and one reason I haven't changed this to my preference is the ease of detecting a rogue DHCP server. VPN's, foreign subnets, all simpler to manage with dis-contiguous or non-overlapping subnets.

    A bogus address assignment with invalid DNS servers, that STILL WORK because it's on the same subnet like 192.168.1.0/24, can be tricky to detect when the clients fail in such an inconsistent manner. Rebooting a client works, perhaps it gets an IP assigned by your valid DHCP server.

    Just a thought.

    donutreply wrote:

    Da_Schmoo wrote:

    Long login times are almost always either DNS set incorrectly on the client (having a DNS Server(s) in the list that isn't a domain controller) or an issue with a Group Policy.

    That sounds plausible, I'll have to look into that.

    Spice (5) flagReport
    2 found this helpful thumb_up thumb_down

  • EminentX wrote:

    Have just found two similar thread. Please have a read on those:
    https://serverfault.com/questions/471662/domain-login-very-slow-10-minutes
    https://community.spiceworks.com/topic/2116517-windows-10-domain-machine-slow-to-logon

    Funnily enough I already looked at both of these before I posted. They weren't exactly what I was looking for.

    Spice (1) flagReport
    1 of 2 found this helpful thumb_up thumb_down

  • Mmcdonald62 wrote:

    I would take note of the time when beginning the login process and review eventviewer logs with the timestamps matching the time it took for the logon process to complete. You may see that windows is configuring software, processing GPO, having trouble with DNS, or struggling to load the profile. GPO events in eventviewer will typically show processing time.

    If you don't feel like digging into logs and would rather try excluding variables then try the recommendation from chris-fr, rule out an issue with the computer by trying a known working user account on the problem computer or have the problem user login to a known working workstation.

    I found this event on all the PC's around the times that they reported it. For security I've replaced the names.

    Source: NETLOGON

    Event ID: 5783

    The session setup to the Windows Domain Controller \\DOMAINCONTROLLER for the domain DOMAINNAME is not responsive. The current RPC call from Netlogon on \\COMPUTERNAME to \\DOMAINCONTROLLER has been cancelled.

    Sounds like DNS issue to me, but not sure what to do about it.

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down

  • Have you looked at the IP addresses configured for DNS on a troubled workstation and confirmed all are domain controllers?

    Spice (3) flagReport
    2 found this helpful thumb_up thumb_down

  • Da_Schmoo has asked probably the single most important question.  It may or may not solve your issue, but until answered, you could be wasting a lot of time and effort.

    At a command prompt on a troubled workstation, type, "ipconfig /all".

    In the results, check that all DNS servers are your domain controllers.  While looking at the results, you can also check that the DHCP server is the one expected.

    Spice (1) flagReport
    2 found this helpful thumb_up thumb_down

  • ich.ni.san wrote:

    Da_Schmoo has asked probably the single most important question.  It may or may not solve your issue, but until answered, you could be wasting a lot of time and effort.

    At a command prompt on a troubled workstation, type, "ipconfig /all".

    In the results, check that all DNS servers are your domain controllers.  While looking at the results, you can also check that the DHCP server is the one expected.

    I checked the DNS Servers and DHCP Server for all the PCs to see if they matched with my own, and all of them seem to have the right IP address. If it was incorrect, could this have been corrected with a reboot?

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • You can enable detailed process messages during logon via registry or a GPO if you want to see where the stall takes place.

    Registry::

    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Policies\System
    “VerboseStatus”=dword:00000001

    Group Policy:
    Computer Configuration > Administrative Templates > System> Display highly detailed messages.

    Maybe that will help?

    Gregg

    Spice (5) flagReport
    1 found this helpful thumb_up thumb_down

  • donutreply wrote:

    ich.ni.san wrote:

    Da_Schmoo has asked probably the single most important question.  It may or may not solve your issue, but until answered, you could be wasting a lot of time and effort.

    At a command prompt on a troubled workstation, type, "ipconfig /all".

    In the results, check that all DNS servers are your domain controllers.  While looking at the results, you can also check that the DHCP server is the one expected.

    I checked the DNS Servers and DHCP Server for all the PCs to see if they matched with my own, and all of them seem to have the right IP address. If it was incorrect, could this have been corrected with a reboot?

    If you have a rogue or multiple DHCP servers on your network, the workstation will use the information provided by the first one that responds so in a situation like this, a reboot might cause it to get the proper info.

    You need to look at the information "ipconfig /all" displays -while- it's broken.  Are the DNS addresses shown you domain controllers and -nothing- else?  Is the address showing for DHCP Server correct?

    Spice (2) flagReport
    2 found this helpful thumb_up thumb_down

  • donutreply wrote:

    ich.ni.san wrote:

    Da_Schmoo has asked probably the single most important question.  It may or may not solve your issue, but until answered, you could be wasting a lot of time and effort.

    At a command prompt on a troubled workstation, type, "ipconfig /all".

    In the results, check that all DNS servers are your domain controllers.  While looking at the results, you can also check that the DHCP server is the one expected.

    I checked the DNS Servers and DHCP Server for all the PCs to see if they matched with my own, and all of them seem to have the right IP address. If it was incorrect, could this have been corrected with a reboot?

    Yes, I think.  The time to check is probably when it's having a issue.

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • Da_Schmoo wrote:

    donutreply wrote:

    ich.ni.san wrote:

    Da_Schmoo has asked probably the single most important question.  It may or may not solve your issue, but until answered, you could be wasting a lot of time and effort.

    At a command prompt on a troubled workstation, type, "ipconfig /all".

    In the results, check that all DNS servers are your domain controllers.  While looking at the results, you can also check that the DHCP server is the one expected.

    I checked the DNS Servers and DHCP Server for all the PCs to see if they matched with my own, and all of them seem to have the right IP address. If it was incorrect, could this have been corrected with a reboot?

    If you have a rogue or multiple DHCP servers on your network, the workstation will use the information provided by the first one that responds so in a situation like this, a reboot might cause it to get the proper info.

    You need to look at the information "ipconfig /all" displays -while- it's broken.  Are the DNS addresses shown you domain controllers and -nothing- else?  Is the address showing for DHCP Server correct?

    Thanks, that makes the most sense. I guess my next question would be how do I do an ipconfig if the computer's stuck trying to log in?

    Spice (1) flagReport
    1 found this helpful thumb_up thumb_down

  • donutreply wrote:

    Da_Schmoo wrote:

    donutreply wrote:

    ich.ni.san wrote:

    Da_Schmoo has asked probably the single most important question.  It may or may not solve your issue, but until answered, you could be wasting a lot of time and effort.

    At a command prompt on a troubled workstation, type, "ipconfig /all".

    In the results, check that all DNS servers are your domain controllers.  While looking at the results, you can also check that the DHCP server is the one expected.

    I checked the DNS Servers and DHCP Server for all the PCs to see if they matched with my own, and all of them seem to have the right IP address. If it was incorrect, could this have been corrected with a reboot?

    If you have a rogue or multiple DHCP servers on your network, the workstation will use the information provided by the first one that responds so in a situation like this, a reboot might cause it to get the proper info.

    You need to look at the information "ipconfig /all" displays -while- it's broken.  Are the DNS addresses shown you domain controllers and -nothing- else?  Is the address showing for DHCP Server correct?

    Thanks, that makes the most sense. I guess my next question would be how do I do an ipconfig if the computer's stuck trying to log in?

    Ye old chicken and egg problem!

    You may be able to disconnect the network cable and have it finish its login quickly, then reconnect the cable. I think it should try to get IP information from the previous DHCP server.

    How quickly does any problem computer log in if the network cable is disconnected prior to entering the password?

    Gregg
    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down

  • what happens if you log into that machine with a different user profile, does it still take an hour or is it quicker. You could log in as admin first then run ipconfig /flushdns to clear any DNS settings then log out and log back in as user. Does the issue still occur after clearing the DNS?

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • Thanks, that makes the most sense. I guess my next question would be how do I do an ipconfig if the computer's stuck trying to log in?

    Can you login to a local user/admin on the PC's?
    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • any chance this Machines have recently made an update from Win10 1803/1809/1903/1909 to 21H2?

    what i saw is that after such Feature upgrade the first login (especially for the first user that logs-in) for eacht user that has a profile on the machine takes a looooong time

     i have done a lot of such updates recently from 1903 to 21H2 and some 5 yeas old Vostro Laptops took an hour for the first login after the update

    Spice (3) flagReport
    1 found this helpful thumb_up thumb_down

  • I've noticed this on both 10 and 11 - moreso on the first login - but if it takes longer than 5 minutes I just do a hard shutdown, reboot and then have them log back in. Just about every time it seems to work and they're able to login just fine. If it happens on an occurrence other than the first login attempt then I just chalk it up to a Windows update that for some reason hung up trying to apply.

    Spice (2) flagReport
    1 found this helpful thumb_up thumb_down

  • So this long log in time happens only on their first time logging into a machine?

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • We had this issue when a defunct mapped drive was still in the group policy and it was taking ages to resolve that it could not find it.  This was only happening for a couple of users and not all which was the most confusing part

    Spice (4) flagReport
    3 found this helpful thumb_up thumb_down

  • Have you recently upgraded the version of windows on said machines?

    We carry out upgrades to the latest version of windows 10 every 6 months and we do tend to see this issue upon first logon of each user if we have used the upgrade assistant instead of upgrading via windows update.

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down

  • I wasn't expecting this many replies when I got into work, haha. 

    Marko0412 wrote:

    any chance this Machines have recently made an update from Win10 1803/1809/1903/1909 to 21H2?

    what i saw is that after such Feature upgrade the first login (especially for the first user that logs-in) for eacht user that has a profile on the machine takes a looooong time

     i have done a lot of such updates recently from 1903 to 21H2 and some 5 yeas old Vostro Laptops took an hour for the first login after the update

    A couple of people asked that, and they were all on 20H2 or higher. I believe that WSUS pushes out updates over the weekend, though it does not push out feature updates. Every Monday log in times are a little longer than usual for some (including me), but never this long.

    Spice (1) flagReport
    1 found this helpful thumb_up thumb_down

  • jrp1416 wrote:

    So this long log in time happens only on their first time logging into a machine?

    No, they've all been using these PC's for quite a while, with the exception of the newest user about 2 weeks ago.

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • chris.hone.5688 wrote:

    what happens if you log into that machine with a different user profile, does it still take an hour or is it quicker. You could log in as admin first then run ipconfig /flushdns to clear any DNS settings then log out and log back in as user. Does the issue still occur after clearing the DNS?

    Well the thing is, log in times are fine except when it breaks. When I do a hard reboot while its stuck, it will work after that. And as far as I know this has only happened once for these users. So it's kind of hard to say whether or not that will work, since I only know it's stuck when someone tells me. 

    As Gregg suggested, I will try unplugging ethernet next time to see if it finishes log in. The thing is, I have no idea when or even if it will happen again, which are the kind of IT problems I hate the most. 

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • Is roaming profiles enabled in your domain?
    Does the user have a wallpaper that has to get pulled from a network location?
    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down

  • I see this after Updates sometimes.  I usually ctrl alt del and log off the user I am signing on, then sign in again. 100% fixes the login. YMMV.  this is just in my environment. 

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • I actually stated this in the initial post, but no, they are not roaming. 

    callMeMrB wrote:

    Is roaming profiles enabled in your domain?
    Does the user have a wallpaper that has to get pulled from a network location?
    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • Sounds similar to an issue I had ages ago in Windows 7, but it was every boot, not just one, then all future boots are fine.

    In my case I had decomm'ed a DNS server, and forgotten to take it out of DHCP - The machines would take 30 plus mins to timeout.  Once I fixed the DNS issue, the timeout issue was also gone.

    Good luck.

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down
  • Some things you can do to eliminate DNS/DHCP as an issue.
    If you can static the settings of a PC to be the proper settings and the issue keeps occuring then it is not DHCP or DNS.
    However, if you static the correct settings and the problem goes away, it could point to DHCP, DNS. and or both (DHCP is handing out the wrong DNS server)
    Another thing you could do is on the switch setup a span port and mirror the port of a problem device to a laptop. Then run wireshark with the DHCP filter and see if you see a rouge DHCP, etc.
    Happy TSHOOTING.
    Spice (3) flagReport
    Was this post helpful? thumb_up thumb_down

  • There was an advisory from Microsoft the other day that older Group Policy administrative template files (ADMX) can cause problems with the latest Windows 10 and Windows 11. They advised updating all ADMX to the latest version(s) as some registry entries have been deprecated.

    Spice (2) flagReport
    Was this post helpful? thumb_up thumb_down

  • Alex Fogerty wrote:

    There was an advisory from Microsoft the other day that older Group Policy administrative template files (ADMX) can cause problems with the latest Windows 10 and Windows 11. They advised updating all ADMX to the latest version(s) as some registry entries have been deprecated.

    Can you tell me what the "problems" were or do you have a link to the statement?

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

  • Alex Fogerty wrote:

    There was an advisory from Microsoft the other day that older Group Policy administrative template files (ADMX) can cause problems with the latest Windows 10 and Windows 11. They advised updating all ADMX to the latest version(s) as some registry entries have been deprecated.

    Be careful with updating ADMX files. Supposedly, the Win 11 ADMX files are NOT backward compatible with older OS versions as all ADMX files have been in the past.

    Gregg

    Spice (3) flagReport
    Was this post helpful? thumb_up thumb_down

  • Most times that I have seen this, it has been Group Policy related or mapped drives related.

    Spice (1) flagReport
    1 found this helpful thumb_up thumb_down

  • I would do a wipe and fresh re-install if at all possible... also, make sure that it's running an SSD not an HDD.

    Regards,

    Jeff 

    Was this post helpful? thumb_up thumb_down

  • Ping your domain name from an affected machine e.g. ping dom.local

    Ping should work without major delays. If there are delays, check your DNS settings.

    Create a new OU, remove all mapped drives, disable all group policy inheritance on that OU, put the affected machine in there, gpupdate /force and see if the issue persists. 

    In Active Directory Sites and Services, check if the subnet of the affected machine is bound to a site. It may be that authentication is happening from a "distant" DC.

    Antivirus playing tricks ?

    Regards,

    V

    Was this post helpful? thumb_up thumb_down

  • Philip2292 wrote:

    We had this issue when a defunct mapped drive was still in the group policy and it was taking ages to resolve that it could not find it.  This was only happening for a couple of users and not all which was the most confusing part

    I have seen this as well with mapped drives that no longer are accessible. After removing the mapped drives, all went back to normal.

    Was this post helpful? thumb_up thumb_down

  • Have you checked to see if they have a giant profile. This will cause it. Pretty common

    Was this post helpful? thumb_up thumb_down

  • donutreply​, ever find a fix?

    Was this post helpful? thumb_up thumb_down

  • Luis C. wrote:

    donutreply, ever find a fix?

    Not Exactly. I will say, I have seen a couple of issues similar to this. If a user is reporting longer login times from cold boot, that only get worse with time? A corrupt profile was usually the issue in that case. In this case it was not. It was a weird one time issue. After a hard reboot it was fine, and I never heard from them again about it. 

    Recently I had a domain user who was working remotely without VPN, so they were not on our network at the time. They said their laptop was doing the "thinking circles" forever and never logging in after they put in their password. They tried a hard reboot and tried again and it did the same thing. What I ended up doing there was hard rebooting to get it unstuck, logging in as myself (had cached credentials), then switching users to them and having them log in. It only took about 3 minutes of "thinking" and they were in. 

    Hope this helps.

    Spice (1) flagReport
    Was this post helpful? thumb_up thumb_down

or sign up to reply to this topic.

Didn't find what you were looking for? Search the forums for similar questions or check out the Windows 10 forum.

Read these next...

  • Snap, AD auth fixes, Canada bans Huawei, Linux, space lasers, & Daredevil

    Snap, AD auth fixes, Canada bans Huawei, Linux, space lasers, & Daredevil

    Spiceworks Originals

    Your daily dose of tech news, in brief. Welcome to not only Friday, but according to Lonny6654 who wrote today's community-created Spark article, it is also World Bee Day. To raise awareness of the importance of pollinators, the threats they face, ...

  • The SOC Briefing for May 20th - Updates Here we Come!

    The SOC Briefing for May 20th - Updates Here we Come!

    Security

    Good morning and welcome to today's briefing. We have a lot of updates and none more relevant than Microsoft since their AD Authentication issues from last week's patch Tuesday. We have some updates for VMware, WordPress, QNAP, SOnicwall and Apple. We th...

  • Spark! Pro series – 20th May 2022

    Spark! Pro series – 20th May 2022

    Spiceworks Originals

    Happy Friday and Happy World Bee Day!  As I had stated in a previous Spark!  I am a first time BeeKeeper this year!  Find out more about World Bee Day and our little friends here. Just a reminder, if you are re...

  • World Bee Day 2022

    World Bee Day 2022

    Holidays

    May 20th is World Bee Day,  a day to heighten awareness about our little friends.  So be sure to celebrate with a glass of Mead and learn more about honey bees.  I have included my take on our little friends an...

  • What do you want to play this weekend?

    What do you want to play this weekend?

    Water Cooler

    I'm always asking "What did you play this weekend" and never "What do you want to play this weekend" but not only that what do you want to do in general?Me? Well, I firmly believe the weekend starts on Friday, but specifically after you clock out. So, wit...