Computer Slow login issue troubleshooting?

Question

Computer Slow login issue troubleshooting?

EnterpriseArchitect 5,851

I am troubleshooting a very strange and annoying issue with my Windows 11 and 10 client OS when connected in a specific offiI am troubleshooting strange and frustrating issue with my Windows 10 and 11 client operating systems when connected to a specific office network.

Let's say the Active Directory (AD) Site is named HeadOffice.

When the computer is connected to the LAN or via WLAN, the login process takes 5-10 minutes. However, when the computer is not connected to the network, the login works smoothly with no issues.

The other AD site does not experience these slow login problems, so I am unsure how to resolve this issue or enable additional logging for further investigation.

S.Sengupta 23,516 Reputation points MVP

2025-05-05T11:56:44.1166667+00:00
It suggests network or AD-related issues specific to the HeadOffice site.

After a slow login experience, examine these logs:

Event Viewer > Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational

Event Viewer > Windows Logs > System Run ipconfig /all nslookup

Use netsh trace

You may also Log in with a new user profile or clean computer.
EnterpriseArchitect 5,851 Reputation points

2025-05-05T12:06:34.1233333+00:00

@S.Sengupta

Does the overly wide (10.10.0.0/16) AD Subnet range defined in the AD Sites and Services also contribute to this slowness issue?

Because the above Catch-All AD Subnet was defined to be managed by the Remote Data Center in a different region.
S.Sengupta 23,516 Reputation points MVP

2025-05-05T15:04:59.5433333+00:00

You've identified a very likely cause of the slow login issues! The overly wide 10.10.0.0/16 subnet definition in AD Sites and Services that's associated with a remote data center can absolutely contribute to login slowness.
EnterpriseArchitect 5,851 Reputation points

2025-05-06T01:45:16.32+00:00

@S.Sengupta ,
Yes, I had a feeling that the mapped DFS-N Network Drive UNC path is pointing to the remote data centre sites, away from this head office AD Site.

How can I check if the DFS-N Root is correctly set up on all DCs at both sites?
EnterpriseArchitect 5,851 Reputation points

2025-05-06T01:46:34.8066667+00:00

@S.Sengupta ,
There is nothing meaningful showing:

Accepted answer

1 additional answer

Your answer

S.Sengupta 23,516 Reputation points MVP

2025-05-05T11:56:44.1166667+00:00

It suggests network or AD-related issues specific to the HeadOffice site.

After a slow login experience, examine these logs:

Event Viewer > Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational

Event Viewer > Windows Logs > System Run ipconfig /all nslookup

Use netsh trace

You may also Log in with a new user profile or clean computer.
EnterpriseArchitect 5,851 Reputation points

2025-05-05T12:06:34.1233333+00:00

@S.Sengupta

Does the overly wide (10.10.0.0/16) AD Subnet range defined in the AD Sites and Services also contribute to this slowness issue?

Because the above Catch-All AD Subnet was defined to be managed by the Remote Data Center in a different region.
S.Sengupta 23,516 Reputation points MVP

2025-05-05T15:04:59.5433333+00:00

You've identified a very likely cause of the slow login issues! The overly wide 10.10.0.0/16 subnet definition in AD Sites and Services that's associated with a remote data center can absolutely contribute to login slowness.
EnterpriseArchitect 5,851 Reputation points

2025-05-06T01:45:16.32+00:00

@S.Sengupta ,
Yes, I had a feeling that the mapped DFS-N Network Drive UNC path is pointing to the remote data centre sites, away from this head office AD Site.

How can I check if the DFS-N Root is correctly set up on all DCs at both sites?
EnterpriseArchitect 5,851 Reputation points

2025-05-06T01:46:34.8066667+00:00

@S.Sengupta ,
There is nothing meaningful showing:

Answer 1

Hi Enterprise Architect,

I have seen catch all subnets work in the past so long as the finer grained subnets match the known network. If all affected machines are in subnets which are not correctly defined then that may be a contributing factor.

My suggestion would be to use tools to check what AD site the machines believe they are in.

GPResult will do if the account executing it is a domain account with local admin.

Powershell will do it if you have the AD commandlets installed/available

old school - you can run ....
nltest /dsgetsite - which will return the AD site the machine thinks it is in
nltest /dsgetdc:DomainName - will show the results of DCLocator - check if the DC is in the expected site

In my experience, logon delays of 5-10 minutes are usually more related to logon processes that occur AFTER authentication. E.g. Roaming profiles, Logon Scripts, Group Policy Processing, etc. These can be impacted if they are processing or accessing resources across slow or congested WAN links (i.e. wrong site). Windows DFS can also use AD site infromation to determine the 'best' server to contact for a target.

HTH

Regards

Answer 2

Darrell Gorter 2,651

Hello,

Start with this page

Tools for Troubleshooting Slow Boots and Slow Logons (sbsl)

https://learn.microsoft.com/en-us/archive/technet-wiki/10128.tools-for-troubleshooting-slow-boots-and-slow-logons-sbsl

Darrell

EnterpriseArchitect 5,851 Reputation points

2025-05-05T15:03:26.7+00:00

@Darrell Gorter ,
This is happening on all computers in a specific AD sites not just one single model only.

Share via

Computer Slow login issue troubleshooting?

1 additional answer

Your answer