\\domain.local slow to load

Soldato
Joined
7 Jun 2003
Posts
16,147
Location
Gloucestershire
Interesting issue here...

Typing in \\domain.local takes a good 10-20 seconds to show anything in the window, but typing in \\domain.local\folder\ always comes up instantly, going back from the sub folder to \\domain.local also takes a while.

Most likely in connection to this we're getting some PCs with quite slow group policy loading times when you first turn them on.

No errors in domain controllers event logs stick out at all, domain controllers are all operating normally when logged in to, general network operation apart from group policy loading times and applying computer settings when a PC is turned on are all fine.

Also takes a long time to produce rsop data but doesn't bring up any errors.

Any ideas?
 
\\domain.local does not even load for me, i think it may be a non standard dns that you have set up? What about if you access the dc directly at \\dcservername ?

Might want to try a group policy setting that is called, wait for network when logging in, to fix slow log in times.

Remove all old Dns records and how many group policy are you loading? One of the sites that i work for used to have a ridiculous amount of gp. The previous admins were idiots and made a gp for every setting pretty much. No jokes it has about 40 group policy settings. It is not recommended to have more than 5 in use on one client/server.
 
\\domain.local does not even load for me, i think it may be a non standard dns that you have set up? What about if you access the dc directly at \\dcservername ?

Might want to try a group policy setting that is called, wait for network when logging in, to fix slow log in times.

Remove all old Dns records and how many group policy are you loading? One of the sites that i work for used to have a ridiculous amount of gp. The previous admins were idiots and made a gp for every setting pretty much. No jokes it has about 40 group policy settings. It is not recommended to have more than 5 in use on one client/server.

\\[fqdn] should always work in an AD environment
 
i can ping it fine but it does take 2-3 seconds before pinging starts, not sure if that's actually a problem. Also no DNS errors to note, nor has the configuration been changed at all in months, and everything else resolves fine and apart from PCs taking a long time to load policies there are no other issues noticed by users on the network during normal use.

and there's probably 5-10 GPs per client maximum
 
i can ping it fine but it does take 2-3 seconds before pinging starts, not sure if that's actually a problem. Also no DNS errors to note, nor has the configuration been changed at all in months, and everything else resolves fine and apart from PCs taking a long time to load policies there are no other issues noticed by users on the network during normal use.

and there's probably 5-10 GPs per client maximum

You have a problem with DNS resolution then. Use nslookup to diagnose further

Ok my mistake my fqdn is not .local. this is why, dim moment. :D

derp. :p
 
Dcdiag on your domain controllers. Also event logs on client for gpo processing would give a hint.
 
How many DC's in the environment?
What O/S version and what domain/functional level?
Does it happen to all machines within the same site?
Are all the DC's in the same site?
Does it happen when machines connect to one or other DC? (Cmd --> type "SET")

Group policy and DFS related issue sounds to me that the link between the client and DC is not right some how, just an inclination. Given that its on some clients and not others would suggest you might have two DC's and one of them isn't playing ball. The above DNS related tests might be a good idea.

I'd do a DCDIAG, REPADMIN, and probably a DFSDIAG to try and get some information into what might be going on. There is a useful little AD GUI tool from MS called "AD Replication Status Tool" that does the above job and gives you a summary of whats wrong and such.

GL
 
Last edited:
Ok my mistake my fqdn is not .local. this is why, dim moment. :D

i suggest you go to work over the weekend, drink a bottle of vodka, change your admin password (while drunk) then sleep it off...

in the morning you will not be able to remember the password and your companys IT systems will be much safer
 
i suggest you go to work over the weekend, drink a bottle of vodka, change your admin password (while drunk) then sleep it off...

in the morning you will not be able to remember the password and your companys IT systems will be much safer

Thank you edscdk, this is the best post I've ever seen on ocuk :D :p

Anyway back to the topic at hand.... Seems the slow loading of \\domain.local and the delay in pinging it is only an issue on one of my 9 DCs, I've run the AD replication status tool and been given no errors, i've done dcdiag etc and there's no errors, I've rebooted the server (you never know eh?) and still no joy.

I feel I'm getting closer to finding out the problem with this bit now, although I was hoping the slow loading of domain.local was linked to the issue with PCs taking some time to load policies in the morning, but that doesn't appear to be the case now as the DC having the problem isn't the DC those PCs see.

How many DC's in the environment? 9
What O/S version and what domain/functional level? 2008R2 for both
Does it happen to all machines within the same site? Yes
Are all the DC's in the same site? No
Does it happen when machines connect to one or other DC? (Cmd --> type "SET") No
 
Do a dcdiag /v on it

I did dcdiag /c /v and the only error to note was this one:
Code:
      Starting test: VerifyEnterpriseReferences

         The following problems were found while verifying various important DN

         references.  Note, that  these problems can be reported because of

         latency in replication.  So follow up to resolve the following

         problems, only if the same problem is reported on all DCs for a given

         domain or if  the problem persists after replication has had

         reasonable time to replicate changes. 
            [1] Problem: Missing Expected Value

             Base Object: CN=PDC1,OU=Domain Controllers,DC=Archway,DC=local

             Base Object Description: "DC Account Object"

             Value Object Attribute Name: msDFSR-ComputerReferenceBL

             Value Object Description: "SYSVOL FRS Member Object"

             Recommended Action: See Knowledge Base Article: Q312862

             
            LDAP Error 0x5e (94) - No result present in message. 
         ......................... ICT_DC failed test

         VerifyEnterpriseReferences

I've checked that out and i don't appear to have any attribute attached to that machine account starting with msDFSR, is this because i haven't migrated FRS to DFSR?

EDIT: Whether it's related or not I can't believe i've never migrated SYSVOL from FRS to DFSR.... just been checking and i've never done it, guess i should get cracking on that, is it safe to do during normal hours or is it best waiting for minimum users on the system?
 
Last edited:
i suggest you go to work over the weekend, drink a bottle of vodka, change your admin password (while drunk) then sleep it off...

in the morning you will not be able to remember the password and your companys IT systems will be much safer

:D Thought I was in the SBS2008 thread for a moment ...
 
When you said there was a delay before it started pinging, was that by IP address, or hostname?

Is there any improvement if you do 'ipconfig /flushdns' from a client and then try?
 
When you said there was a delay before it started pinging, was that by IP address, or hostname?

Is there any improvement if you do 'ipconfig /flushdns' from a client and then try?

The delay only occours when pinging the "domain.local". Pinging the DC it's resolving either by hostname or IP resolves instantly.
 
Originally Posted by Knubje View Post
How many DC's in the environment? 9
What O/S version and what domain/functional level? 2008R2 for both
Does it happen to all machines within the same site? Yes
Are all the DC's in the same site? No
Does it happen when machines connect to one or other DC? (Cmd --> type "SET") No

Do the clients in other sites see this problem?

Could it be that clients on the site with the issue are resolving to the DC's in the other sites?

How many DC's in the site with the problem?
 
If you have multiple physical sites in your organisation, then you need to go into AD Sites and Services and check:

- All your sites are setup correctly
- All your DCs are in the correct site
- All inter-site links are setup correctly and reflect the reality of the physical links between sites
- All subnets are setup and in the correct site

If all the above isn't meticulously maintained, then you will have random delays as clients don't know which DC to talk to, and therefore choose one at random (could be the one that is furthest away).
 
Really ****ed off with this problem, i've fixed it now, and let me just say it turned out to be a hell of a lot simpler than a network problem.

Want to know what it was? Of course you do..........The apple mobile device and bonjour services. Soon as i stop either one of those (only seems to happen when they're both running) the problem goes away, unbelievable! That would explain why it never had a set pattern to where this problem occoured, it was only happening to people who use ipads :/
 
Back
Top Bottom