Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to www.eventid.net. The EventId.Net for Splunk Add-on assumes that Splunk is collecting information from Windows servers and workstation via the Splunk Universal Forwarder.
The winlogon notification subscriber <Profiles> took 606 second(s) to handle the notification event (Logon).
|English: Request a translation of the event description in plain English.|
In our case, the machine had invalid DNS servers defined. Since all the lookups were timing out, it caused logins to be very slow, like 15 minutes long.
I got this along with Event ID 6005. Determined that issue was due to GP Folder Redirection and Drive Mapping. Since this was only an issue on one computer, I added the server to the HOSTS file in the problem computer which seemed to solve the issue.
In my case it was a mistake on the DC (virtual), 10 minutes served as administrator. DC was a DNS server. The problem was in the wrong setting up DNS.
See also the comments for event id 6005 from Winlogon (link below). Event 6005 and 6006 are in most cases recorded together.
My server was Windows 2008 R2 and had the NetApp SnapDrive application installed on it. Changing the SnapDrive service from "Automatic" to "Automatic (Delayed Start)" fixed the issue for me. The "Applying computer settings" message delay decreased from 4 minutes to 20 seconds.
From support forums:
We've been having the same problems on our clients running vista. Logon times were around 10 minutes and event ID 6005 and 6006 from source WinLogon were logged. In our case the problem was caused by an update deployed on the clients but not on the DC's. Since the updates was for GPO client side extensions this caused login problems. The update in case was ME943729. When we installed the updates on our DC's the problem was gone and logging on went back to normal.
* * *
Verify if there are some logon scripts applied to this machine and the policy “Run logon scripts synchronously” is enabled. If so, temporarily disable the policy or remove the logon scripts to check the result.
* * *
In my case, a user had a 10-minuted delay before every logon. Other users logged on just fine on the same machine. I've tried to re-create the profile, to update network drivers etc. The only thing I found is that it was due to Synchronous Application of Group Policy. But it is not accepatble for us to turn it off. So I continued to look for the real 'root cause'.
The actual reason was very trivial and not related to hardware at all. We have some logon scripts for mapping network drives for different users. And in this particular case the user did not have the permissions required to connect to the network share. So the script hang for exactly 10 munutes, which is the default time-out."
* * *
In my case, I fixed the problem by updating the drivers for the network card.
|Private comment: Subscribers only. See example of private comment|
|Links: Event id 6005 from Winlogon|
|Search: Google - Bing - Microsoft - Yahoo - EventID.Net Queue (0) - More links...|
|Custom search for *****: Google - Bing - Microsoft - Yahoo|
Send comments or solutions
- Notify me when updated