Hello. Currently I have an issue that has caused me much grief. Hopefully someone here can point me in the correct direction...
I have 4 DCs on my network currently. 1 is Server Enterprise 2003 x64 SP2, the other 3 are all Server 2008 Enterprise X64.
Over the last couple months I've been experiencing issues where my clients will get very long log on times (around 10-15 minutes). When this happens, I see in the event log 2 warning everytime:
"The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (Logon)."
"The winlogon notification subscriber <GPClient> took XX second(s) to handle the notification event (Logon)."
*NOTE: XX is any number between 90 and 1013 so far.
XP Clients will display messages regarding the processing of GPOs has failed and they will be applied in the background (dont have exact txt in front of me).
Funny thing though, if I log off and log back in it works just fine - possibly cached.... but I'm am forcing clients to connect to the network and to process GPOs during each logon.
Even more mysterious - if I can catch it right, if I attempt to connect to my domain via SMB (ex. \\domain.name.com) where I should get the shares NETLOGON and SYSVOL, the window will wait about 10-15 seconds before being displayed. Every other time it pops right up. I think there is some corelation between the DCs not showing me the share and GPClient having issues accessing the GPOs, but I cant find any proof of it, nor do I know how to fix it if I could prove it.
I have also caught this problem on a DC itself when trying to login - of course to troubleshoot this very error. When the DC does it though, I cant access the DC directly from other workstations/servers. Only way to fix is to restart the DC, but each of the 2008 DCs seem to do this at different times, and during each "outage" the main domain name is still accessible, SYSVOL is still accessible to users of the domain, DNS and AD still work, authentication is still working, etc. Just the DC at that moment needs to be restarted otherwise it wont respond to requests anymore.
Checked networking - DCs are in 4 different buildings (local area, not wan), each building connections are working as well as we can tell (multiple servers at each location and none are having connectivity issues that I can observe)
Event logs on DCs/clients - besides the mentioned event logs, no other notifications are presenting themselves.
Replmon - Shows all is well. Tested with various AD and DNS changes and all DCs show the info just fine after a couple seconds.
Checked services - all that should be running are.
Perfmon - systems are not being taxed in anyway (Dell PowerEdge 1950s, 16GB Ram, 2xQuad Core Xeons, etc)
So, anyone have any ideas where I should look?
Do you mean that the issue (slow logon) disappeared after you restarted the DC? How do you know which DC need to be restarted?
Please create a new clean OU, move a client machine and a user object to this new OU, and then block inheritance. Logon the client machine with the user account, does the issue disappear?
As this thread has been quiet for a while we will be changing the issue type to ‘General Discussion’.
If you wish to return to this question you can go ahead and change the type back to ‘Question’. Then you can click Options, select Change Type, and change the Tread Type to Question.
If the issue has been resolved, we’d love to hear your solution. By sharing your experience you can help other community members facing similar problems.
Sorry for the delays in writing a response.
All client machines are using 2 of my DCs as DNS servers. The DNS is AD Integrated. They all use DHCP to get their information.
Yes, the slow logon issue resolves itself when I reboot the DC. I only know which DC by using the AD snapin from the RSAT. If try to connect to each DC, the one causing the problem refuses to respond. I get "RPC Server did not respond."
This happens on any OU across the entire domain. Even in new test OUs and on new Test machines. When one DC chooses to act up, any machines that try to authenticate to it experience the issue. Vista and XP, though Vista is the only one that gives me the GPClient errors. The XP machines will tell me something to the effect that the Group policy will update in the background.
I am still having this issue and it is very frustrating.
Yes, got it solve by disable IPv6.
The following errors are ALL gone!!!!
Event ID: 6006
The winlogon notification subscriber <GPClient> took 542 second(s) to handle the notification event (Logon).
Event ID: 6005
The winlogon notification subscriber <GPClient> is taking long time to handle the notification event (Logon).
- Edited by Louie Su Tuesday, November 16, 2010 8:30 PM spelling
I would recommend disabling IPv6 on both. At the moment there is no benefit only security issues with leveraging IPv6. It is wasted configuration, more to monitor and completely unnecessary, not to mention innately with 6 to 4 enabled all 6 traffic can ride on 4 and still effectively bypass the Network Address Translation. You will be more secure disabling IPv6 until the time enabling 6 becomes mandatory because everyone is using it.
I would recommend disabling IPv6 on both. At the moment there is no benefit only security issues with leveraging IPv6. It is wasted configuration, more to monitor and completely unnecessary, not to mention innately with 6 to 4 enabled all 6 traffic can ride on 4 and still effectively bypass the Network Address Translation. You will be more secure disabling IPv6 until the time enabling 6 becomes mandatory because everyone is using it.BTW: there are Microsoft KB articles that recommend against disabling IPv6.
Wow, this is an old post but sadly this issue has hit one of the customers of the company I work for.
I found that the cause of this issue was incorrect DNS settings on the client side (namely google's public DNS being configured). Setting this as auto resolved this issue for me and I haven't had any recurrences.
Late but I hope this helps anyone experiencing the same problems. Also, disabling IPV6 is something I too would advise against.