In one case, the time on all computers in the domain appeared to be the same, but the domain controller had a time zone of "(GMT-08:00) Pacific Time (US & Canada); Tijuana" and the workstation had a time zone of "(GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London", so in fact the time was different by 8 hours. This was fixed by setting the time on all computers in the domain to have the same time zone of "(GMT) Greenwich Mean Time : Dublin, Edinburgh, Lisbon, London" and setting the time to be the same.
In another case, this occurred on a stand-alone domain controller that during testing had had its time set back by one year. This was fixed by restoring the computer from a backup.
In another case, on Windows 2000 Server SP4 this occurred on a domain that was created by restoring an image of a domain controller and then promoting two other domain controllers with DCPROMO. It was found that AD replication was not working. It is believed that the original image may have contained Active Directory objects that were older than the tombstone lifetime interval or some other corruption. This was fixed by using DCPROMO to demote/re-promote one domain controller at a time and seizing the FSMO roles.
See the link to "Citrix Support Document ID: CTX105618
" for details on this event.
From a newsgroup post: "My company had a problem in which client computers couldn't map a drive to our file server. Users received the error message "Unable to impersonate using a named pipe until data has been read from that pipe". We also couldn't apply Group Policy Objects (GPOs) to the affected servers. When administrators tried to log on to the servers, they received this event. The problem was that the event log was full and needed emptying. The solution we found for this problem was to start regedt32 and ensure that the KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa subkey was set to crashonauditfail, with REG_DWORD as the subkey's type and 0 as its value. In our case, the value was set to 2 and needed to be changed. A value of 2 means that the system halted because it couldn't report auditable events; the system sets crashonauditfail to 2 just before it halts. A value of 0 prevents the system from halting when it can't report all auditable events".
Users were reporting slow logins; computers seem to hang up at “Applying Personal Settings”. The system would finally login after about 3-4 minutes of waiting. I have a mixed OS environment of Win2k desktop and Windows XP Pro laptops. I was also experiencing the same problem on all of my Win2k SP4 and Windows 2003 std. member servers. The only servers not affected were my AD servers hosting DNS.
I checked the event viewer and all computers logged the following errors: “Windows cannot establish a connection to <mydomain.com> with (0)” and “Windows cannot query for the list of Group Policy objects. A message that describes the reason for this was previously logged by this policy engine”.
I started having the slow login problem after I demoted several AD servers located at remote branch office. All remote branch offices are connected to my main office via a VPN tunnel to a Watchguard VPN Concentrator.
To resolve the problem I unlinked the group policy in AD users and computers, and deleted the mydomain.com zone in DNS (did this on all servers hosting DNS). I recreated/rebuilt the mydomain.com zone in DNS and on all hosting servers. I recreated group policy and rebooted my DNS servers.
After about 15 minutes, all member servers were able to login without any delays. The events 1000 from source Userenv did not reoccur in the server event logs. I also had all of the users that reported the problem reboot there computers and they no longer experienced login delays.
provides information on resolving this issue.
"As the message says, this event should be preceeded by another one that usually provides more info on why the Group Policy objects could not be queried. A typical example of such event is:
Windows cannot establish a connection to <server name></server> with (1787)
Error code 1787
means: "The security database on the server does not have a computer account for this workstation trust relationship". See ME257623
for more details.
For this error, I noticed that for servers with dual NIC cards have this error quite frequently and what I like doing is naming each of the NICs to LAN and WAN so I can tell which is which. Then I open the Network Properties and go to Advanced Settings on the menu bar and change the bindings - for which has priority to the LAN. Then reboot all these errors go away.
"This error was caused by group policy not being appropriately applied. I received this error on workstations in conjunction with not being able to logon locally to Win2k Server for use with Citrix (Terminal Services). After a lengthly phone call to Microsoft, it was determined that this was because the Default Group Policy was somehow linked to two separate policies on disk. Unlinking, NOT DELETING, the Default Group Policy and refreshing all policy information should fix the problem. From that point, new polices should have no trouble being created or applied."
This error may occur if there is a date difference between the client computer and the domain controller. Just adjust date and time on the client workstation and reboot.