In my case, this error along with some failing dcdiag tests (like advertising) were caused by the _msdcs zone in DNS having mysteriously disappeared!?! Recreating the zone as an Active Directory integrated zone with only secure updates and then running net stop netlogon and net start netlogon successfully recreated the missing _msdcs forward lookup zone.
Quick history, the Windows 2003 Server was a P2V when I took the server over and owner complained that he had a temp profile loads when he logs on. I checked application event log and found event id 1054. The client did not have a profile in Document and Settings. I had the client log on locally (which created the profile), then logged off, had him RDP then of course it loaded the temp profile but this time go to system properties-advance-userprofiles-highlight user- change type-local profile. Log off/on and local profile should load now. This scenario might work for some.
Another resolution using the /usepmtimer switch, as others have posted, see ME895980
"This problem occurs when the computer has the AMD Cool'n'Quiet technology (AMD dual cores) enabled in the BIOS or some Intel multi core processors. Multi core or multiprocessor systems may encounter Time Stamp Counter (TSC) drift when the time between different cores is not synchronized. The operating systems which use TSC as a timekeeping resource may experience the issue. Newer operating systems typically do not use the TSC by default if other timers are available in the system which can be used as a timekeeping source. Other available timers include the PM_Timer and the High Precision Event Timer (HPET)."
We had a Windows 2003 as PDC which was not able to even find himself. M326152 helped as the server was connected to a Netgear Gigabit switch. Maybe it was because the Switch was too cheap. Helped anyway.
I found that my pc was connected to an older switch, and it wasn't receiving its group policies correctly. Plugged into a new switch and the problem was solved.
I had the same problem (The error description was "An unexpected network error occurred"). Every tests we did was fine except the user login over VPN. GPResult and netdiag gave no errors. We changed the MTU size for the VPN traffic to 1400 and the problem was fixed.
My problem was an old entry in _msdcs under my domain (an old DNS server was configured). Once I removed that the problem was gone.
I initially fixed this by using the solution proposed by Christophe Derdeyn, but I have since found a more complete solution that addresses the underlying fault.
If you have any sort of multi-core or multi-processor system, have your server ping itself. Repeat this command several times. You may see negative ping times, or ridiculously high ping times. For instance, on my affected server I was seeing:
Reply from 192.168.254.180: bytes=32 time=1273ms TTL=128
Reply from 192.168.254.180: bytes=32 time<1ms TTL=128
Reply from 192.168.254.180: bytes=32 time=-1273ms TTL=128
Reply from 192.168.254.180: bytes=32 time<1ms TTL=128
This behavior is due to a glitch in HAL detection which results in Windows using the time-stamp counter (TSC) instead of the PM timer as the mechanism for QueryPerformanceCounter function calls. Server 2k3 SP2 *should* use the PM timer on all APIC and ACPI systems, but sometimes it does not. Because each processor maintains its own TSC and these counters are not sychronized with one another, QueryPerformanceCounter may return inconsistent results. This causes the spurious ping times, and causes problem for GPO transfer rate calculations (hence Christophe Derdeyn's solution)
You can read more about this issue in this blog by the Active Directory Services Team - "Userenv 1054 events as a result of time-stamp counter drift" (see the link below, in the Links section).
You can fix this by forcing Windows to use the PM timer for QueryPerformanceCounter. Set the /usepmtimer switch in boot.ini and reboot the system. Your pings should look normal now and the 1054 errors every 5 minutes will go away.
This issue is probably present on non-DC servers and Windows XP-based clients as well. It probably wouldn't hurt to check them for goofy ping times and apply this fix as needed.
I have several HP Proliant DL 385 G2 as AD\GC\DNS. I was getting these errors until I updated the Network configuration utility that HP has on their website. I also set each NIC to 1000\FULL.
We have an AMD Opteron dual core system that was recording this event every 5-10 minutes. After reading another post here that updating a different AMD processor driver fixed the issue, we checked for a driver update for the Opteron. We found the following page: “AMD Opteron™ Processor Utilities and Updates”. The specific driver update is dated September 2007 and is called “AMD Opteron™ Processor with AMD PowerNow!™ Technology Driver Version 1.3.2.0053 for Windows XP and Windows Server 2003 (x86 and x64)”. There is also another update direct from Microsoft referring to a known issue with the AMD PowerNow! driver, last updated October 11, 2007. It is possible the update above can cause the issue in this document, so as a precaution I have included it here as well. See ME924441
for the update from Microsoft.
In my case, this problem was caused by the "AEGIS Protocol (IEEE 802.1x) v 184.108.40.206" driver that was probably installed together with the ASUS WLAN driver. This event occurred together with Event ID 14 from source W32Time, Event ID 29 from source W32Time and Event ID 5719 from source NETLOGON. After disabling this item in the network card properties, all these errors were gone.
As per Microsoft: "A network connectivity or configuration problem exists. Group Policy settings cannot be applied until the problem is fixed". See MSW2KDB
for more information about this event.
Also, see ME933458
and the links to "Fixing Scripts policy settings problems", "Troubleshooting network problems", WITP76721
for additional information on this event.
In my case, I had an issue with a wireless USB lan, but solved it. First, I logged on as local administrator, and did the setup of the Wireless USB, then rebooted and it worked. As for the GPO, I did add two settings in the Registry (FOR LOCAL ADMINISTRATOR, the same user i did the Wireless setup for):
Windows Registry Editor Version 5.00
I had to add the "Windows" and "System" folders.
We have a new Opteron server (1210, AM2 socket) on a Tyan S3950 mainboard (Broadcomm HT-1000 chipset). This server was promoted to a DC and now holds all the FSMO roles. We began to see this event every 5 minutes continuously whether a user was logged on or not. DNS and Ethernet tweaks did not help. I found a blog entry that said to install the "AMD Athlon™ 64 X2 Dual Core Processor Driver for Windows XP and Windows Server 2003". After installing this driver and rebooting, the 1054 events are gone.
In my case, this was caused by the firewall on my WinXP machine. Trend Micro PC-cillin Internet Security 2007 blocks ICMP requests by default. If you allow ICMP-traffic for the local network (or just the DC), the error will go away.
In my case, I got this error only if a specific user logged in. For this user, the login-script (mapping drives) did not work. If another user or an administrator logged in, the login-script worked. Gpresult said that the GPO that contains the login-script was applied. I solved this problem by moving the user to another OU (to apply other GPOs), login once and move the user back to the original OU. After this, the login-script was applied properly. On another PC with the same problem, I just gave the user admin privileges for the next login and the problem was solved under normal privileges as well.
I was getting this on my Exchange frontend server. I opened up ICMP on my firewall between the dmz (demilitarized zone) and the domain controllers and the group policy was able to apply.
On our server, I removed the logon script in the GPO and this fixed the problem.
In my case, I resolved this by updating the network card driver to the latest version, despite the fact that I had done that only 3 months ago. Always worth checking this early on as it is simple to do.
In our case, the problem occured due to Group Policy settings pulled across a VPN. The solution was to disable slow link detection on the DC. See ME910206
for information on how to do that.
In my case, this problem occurred because a traditional ping between this server and the DC was stopped by the firewall.
In our case, the problem was in the limitation of the ICMP packet size to less then 2048 bytes by our ISP. See ME816045
for information on how to change the default setting (2048 bytes) in system registry.
I had a W2K3 SBS2003 with 2 NICs, one connected to the Internet and the other to our Intranet. I had the 1054 Userenv event every 5 minutes. Enabling the Userenv debug mode (as described in some of the other posts) showed the following behavior:
USERENV(20c.aa4) 14:20:57:242 PingComputer: First and second times match.
USERENV(20c.aa4) 14:20:57:242 PingComputer: First time: -25
USERENV(20c.aa4) 14:20:57:242 PingComputer: Second time: -25
USERENV(20c.aa4) 14:20:57:257 PingComputer: First and second times match.
USERENV(20c.aa4) 14:20:57:257 PingComputer: No data available
USERENV(20c.aa4) 14:20:57:257 ProcessGPOs: DSGetDCName failed with 59.
To correct the problem I set this flag in the registry to force it to treat the link as fast.
Windows Registry Editor Version 5.00
This has reduced the frequency of the errors to a few times a day and the GPO seems to be updating correctly.
You might get this event after turning on the firewall on a DC. See ME555381
for information on how to configure the Windows 2003 SP1 firewall for a Domain Controller.
I had this problem on two Win2k3 member servers and resolved it by disjoining the domain, then re-joining the domain.
I was having this problem on a Win2k3 member server using a static IP address. I changed the DNS suffix (was incorrect), and this solved the problem.
I was running ZoneAlarm and it had denied access to the Windows Logon Module. Try shutting down ZoneAlarm (or any other personal firewall) and run gpupdate from a command line.
This problem can occur if the user is authenticating to a MIT Kerberos realm with a Kerberos name mapping defined in AD. See ME827182
for a hotfix applicable to Microsoft Windows Server 2003.
You can also turn on debug logging for Userenv which will give you a lot more information about what is breaking:
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Value Type: REG_DWORD
Value Data: 10002 (Hex)
The log file created will be located in “<drive>\Windows\debug\usermode\userenv.log”.
As per Microsoft: "This problem may occur if the Group Policy engine or Active Directory times out while it waits for the network to start. A race condition may occur between the TCP/IP protocol and the network adaptor driver when they try to register with the Microsoft Network Driver Interface Specification (NDIS). If the TCP/IP protocol registers with NDIS before the network adaptor driver, for a short time it prompts higher user mode networking components that network connectivity is not available. During this short time, the Group Policy startup script cannot be downloaded". See ME840669
to resolve this problem.
This behavior can occur if you have not started the Netlogon service. See ME299563
for more details.
From a newsgroup post: "I solved the problem. Something odd was happening in the DNS configuration. While in the DNS console everything looked fine, in the SBS administration console, Computer management (local), Service and application, DNS there was something different: The zone was pointing to another address. I had to delete zone and recreate the reverse lookup zone manually. Then stop logon service, flush DNS and register DNS again with IPCONFIG /registerDNS".
I encountered this problem on my DC. The DC is a Win2k3 and I installed on it a firewall. This firewall was blocking all the connections via 127.0.0.1, so the Netlogon service was not able to communicate. To fix the problem, I stopped the firewall and I restarted the Netlogon service.
I had the same error message on my Windows XP client. It appeared right after I changed a Domain. UNC-names were resolved right, but I could not search the network environment. The problem was caused by the fact that the server's NIC was configured for IPSec. Since I was not using IPSec I changed this on the server and solved the problem.
In my case, ZoneAlarm (personal firewall software) caused this problem. After I uninstalled this program, the problem disappeared.
I had this error on several laptops, Dell Latitude C600, they were not processing group policy for software installation. Reinstalling the NIC driver, 3Com 10/100 Mini PCI Ethernet Adapter fixed the problem.
In our particular environment we had a 2003/XP computer separated from the 2003 DC over a VPN. All DNS settings were correct, and NIC drivers updated. We also disabled the DHCPMediaSense feature. In the end, after looking very closely at the firewall logs, it appears that the firewall product that we were using was dropping ICMP packets larger than 512 bytes (NG SmartDefense) in anticipation of an Denial of Service attack. It appears that at some point in the conversation, the client computer trys to send an ICMP packet of 2048 bytes. Why? Now that we upped the maximum ICMP packet size to 2048 and rebooted the client machine, the group policies process fine.
I have the same problem in a 2k native domain with XP clients. Errors were generated after blocking ICMP on workstations with IPSec. XP did not apply group policy until I stopped the IPSec service. After applying the policy without blocking ICMP, everything started working again.
I also had this error. My notebooks were not getting the full group policy. Updating the Realtek RTL8139/810x NIC drivers fixed the problem.
Try flashing with the latest BIOS. We had a Dell Latitude C600 laptop out of the office for three months that would not process GPOs once the person brought it back in, could not find domain controller, etc. This error was among several. Long story short, we flashed the BIOS from A7 to A23 and it processed the GPOs immediately. Nothing else worked, including re-joining the domain, updating the NIC driver and so forth.
Also had this problem on machines with Gigabit NICs. Setting the registry key “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\DisableDHCPMediaSense” to “1” as per ME239924
This error did not go away for me until I configured the settings in “Group policy->Computer Configuration->Administrative Templates->System->Net Logon->DC Locator DNS Records” on my DNS servers. It seemed a logical place to go. My workstations could not find a DC through DNS and my DNS was not dynamically updating its SRV records. I thought that was dynamic, but apparently not.
In my case, this error occurred on a domain with 2 servers, one with Win2k and the other one with Windows 2003. The error was caused by Norton Internet Security, which is installed on both. Even the firewall was configured on both machines to trust each other’s IP address, the error was still there. The solution I came up with was to include “localhost” (127.0.0.1) to be a trusted IP on both machines.
I had this problem with a new domain controller running Windows 2003. DHCP was installed on the server, but not yet configured or authorized. Removing DHCP, or configuring and authorizing it resolves the issue.
I had the same issue with Broadcom 440x drivers in Dell Inspiron and Dimension computers using the XP built in driver (ver 3.5.1). Updating to the latest driver (3.6.0) solved the issue.
refers you to ME239924
to disable DHCP Media Sensing in the registry. This problem has appeared to all of my machines with Gigabit NICs. Read warning about side affects. This fix will most certainly cause problems for mobile users, but it worked for my desktop machines.
The problem is not with the NIC or DNS, but rather with the Microsoft XP OS. The Netlogon service is not robust enough to account for variances with some network cards and network environments. Most switches will run the Spanning Tree Protocol (STP) to detect network loops and shut down any ports with a loop. The process of detecting loop causes the switch port to go through multiple states: blocking, listening, learning, and finally forwarding. The switch is not able to transfer any traffic until the port reaches forwarding state. On most switches, this takes about 30 seconds after starting STP initialization. As the PC boots, some NICs perform a reset, which also forces the switch port to reset. If spanning tree is enabled it will take a minimum of 30 seconds before that port is capable of traffic. If XP is not able to transmit during that 30 seconds it will be logged as a failure and it will not retry. Windows 2000 is generally more robust in this respect. PortFast is Cisco terminology and allows you to set specific ports so they go straight from the blocking state to the forwarding state. It should be enabled on all ports with clients attached, to avoid timing problems. The reason you do not see a problem with all NICs is because some never perform a reset. This means the spanning tree cycle is never initiated. See Dell Support Forum for more details.
I have had the same error with a notebook running XP. Computer Configuration was just not applied to this machine whilst other PCs (even identical Notebooks) had the same GPO applied without problems. After having tried every possible solution on this site, I think the following did the trick:
1. Took PC out of domain and deleted the computer account there.
2. Applied new SID to the PC.
3. Changed the File System of "C:\" from FAT32 to NTFS (wanted to do this on this machine for a long time, so even if it may have nothing to do with the GPO-Problem, I list it up here to be 100% accurate).
4. Joined the domain again & rebooted properly.
5. Then moved the PC-Account in the ActiveDirectory to the container with the GPO I want to apply to the PCs. Then finally, the GPO was applied just as for the other PCs.
Use "netdiag.exe" (Win2k server support tools). See ME247811
for more details.
If you're using DHCP, make sure the DNS Server option (006) is set in your scope options.
For Microsoft Windows Server 2003 see ME324174
See the link to ME291382
for DNS troubleshooting.
Error: "A socket operation was attempted to an unreachable host." - As per Microsoft, this event may occur if the address for the configured preferred Domain Name System (DNS) server on the client is not valid or unreachable. See ME298656
Error: "The specified domain either does not exist or could not be contacted." - The error should point to the problem, that is, the domain controller is not available (network problems, the server is down, etc..) or the client computer is not configured properly in order to find it (i.e. wrong DNS server). This error was also reported by users that installed a personal firewall on their computer (i.e. ZoneAlarm) without configuring it properly (so the firewall blocked the access to the domain controller).
From a newsgroup post:
"All computers must point to the DS for DNS resolution. See TB727055
- "Troubleshooting Common Active Directory Setup Issues in Windows 2000" and ME237675
- "Setting Up the Domain Name System for Active Directory". These two articles fixed the same problem for me. W2K and XP both require an accurate DNS server that accepts active updates.
From a newsgroup post: "I have the same problem and the only thing I have read
that makes any sense is someone saying there was a XP hard drive image problem at Dell. They reinstalled XP from the Cd that can with the computer. They said all the problems were solved."
The Intel Pro 1000 MT series of NICs in confuction with Windows XP shows an Error code 1054
. This problem is related to the initialization rate on the NIC vs. the fast load of the OS. Installing an update driver from Intel resolves this or hacking the registry in this area.
Error: "The specified domain either does not exist or exist or could not be contacted". As per Microsoft: "Windows XP-based systems that use Gigabit Ethernet devices may not be able to join an Active Directory domain, which aborts the Group Policy download process. The problem occurs because link status fluctuates as the network adapter (also known as the network interface card, or NIC) driver initializes and as the network adapter hardware negotiates a link with the network infrastructure. The Group Policy application stack executes before the negotiation process is completed and can fail because of the absence of a valid link." See ME326152
I have this problem with a Wireless LAN card. The card doesn't support Zero Configuration and the NIC software doesn't load until after logon so it cannot connect to the DC until after the logon to the local workstation.
If you are experiencing this event on a WinXP Pro Station and Group Policy settings are not being applied properly (whether it be User Policies i.e. Folder redirection or computer Policies i.e. Software Installation) check the local GP settings under Computer\Administrative Templates\System\Logon\[Always wait for the network at computer startup and logon]. What this does is disable the Windows XP Fast Logon Optimization, which causes XP to check cache credentials for logon information and does not wait for the network state to be available; so logon time is faster. On the negative-side of this it can cause group policy defects. See ME305293