provides information about a hotfix released by Microsoft for a situation when this event is recorded if a non-Microsoft DHCP Relay Agent is used.
This error occured on client in domain when client has set fixed IP address. The solution was to set fixed DHCP reservation on server and to set dynamically (from DHCP) obtained IP address on client.
I updated the network card drivers to the latest version all works fine now.
See the information about this event in this article: EV100160
- Error: "Not enough storage is available to process this command" - In my case, this problem was caused by non paged pool space. Please follow these steps and check also the KBs to resolve the problem:
1. Set page pool size to 1.5x-3x of your RAM. For example for 1GB of RAM, set the page pool to a value between 1.5 and 3 GB.
2. Click Start, click Run, type regedit in the Open box, and then click OK. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. On the Edit menu, point to New, and then click DWORD Value. Type PoolUsageMaximum as the entry name, and then press ENTER. Right-click PoolUsageMaximum, and then click Modify. Click Decimal. In the Value data box, type 60, and then click OK.
Setting the value at 60 informs the Memory Manager to start the trimming process at 60 percent of PagedPoolMax rather than the default setting of 80 percent. If a threshold of 60 percent is not enough to handle spikes in activity, reduce this setting to 50 percent or 40 percent.
3. Click Start, click Run, type regedit in the Open box, and then click OK. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management. On the Edit menu, point to New, and then click DWORD Value. Type PagedPoolSize as the entry name, and then press ENTER. Right-click PagedPoolSize, and then click Modify. Click Hexadecimal. In the Value data box, type a value of FFFFFFFF, and then click OK. Setting PagedPoolSize to 0xFFFFFFFF allocates the maximum paged pool in lieu of other resources to the computer.
4. Quit Registry Editor.
5. Restart the server for the changes to take effect.
for additional information on this problem.
* * *
On another occasion, I had this issue again on x86 cluster and none of recommendations helped me. I had implemented ME924390
and issue did not occur again. Also re-sync cluster, and rejoining from domain fixed this but it is causing downtime.
* * *
In another situation, I was experiencing again with NET LOGON issue, SPN records, Kerberos, NLTEST, and connections beetwen servers and domain controllers.
It was randomly were lossing connection with DC and only re-joining in domain solved this issue
There also appeared issue with communication with Kerberos, SPN ( even SPN was set correctly in schema ) recprds, and NLTEST was always unsuccessful
This issue did not fixed renaming and rejoinging of systems, neither re-promoting of DCs.
I have fixed this by:
1. removing another gateways from NW connection
2. inserting only primary and secundary DNS system into NW settings of servers
3. removing DNS systems which were not domain members from NAME Servers settings on domain DNS systems
Implementing the fixes described at ME948496
I recommend to implement the first patch on all systems, and second one ( depends on the network load ).
* * *
You may want to check ME931192
On a Windows 7 machine, disabling IPv6 resolved the issue for us.
Our problem was that hours on our 2 ESX servers that are hosting our 2 AD DC were not on a real NTP Server. Once this settings has been updated to correct server, our NT4 Workstations are now able to connect to AD.
Low level Firewall services, specifically "OfficeScan NT Firewall" will generate this event if the workstation is a little on the sluggish side. The service is enabled and started by default even if you are NOT using the Firewall features of this product (Trend Micro Officescan). Stopping and disabling the service may resolve event id 5719 where the source is NETLOGON.
Note: If you are using the Firewall features you might want to consider some kind of wait / dependency.
In my case, I could log in via the console with my domain credentials, but RDP would error out with "Logon rejected for <user> Unable to obtain Terminal Server User Configuration. Error: The RPC server is unavailable."
I could browse to other computers via Network Places, but was getting Access Denied when I'd try to browse to the problem machine from another box. I was also getting Event ID 11167 from DNSAPI, Event ID 1219 from Winlogon, and Event ID 18 from W32Time. I tried every fix out there from all of the different sites (including Eventid.net) with no success. Finally, I looked at Winsock2 and noticed that it was corrupt! The server was a Windows 2003 Enterprise SP2 and I ran "netsh winsock reset" at the command prompt, which fixed the issue. In my case, I had to re-add the server to the domain, but that's only because I''d just removed it to troubleshoot. You may be able to get away with just resetting winsock and rebooting the server. You can find more information about troubleshooting Winsock problems at ME811259
I had this problem when our ARP cache on our core router started resolving to another host. After clearing the arp cache the problem was resolved.
In our case was "Not enough storage is available to process this command" on terminal servers (2000, 2003) caused by OCS Inventory NG - opensource inventory and package deployement sofware. After several days were all TCP ports betwen 1000 and 5000 exhausted by svchost.exe processes started from OCS server share.
We started experiencing this problem after installing the hotfix mentioned in ME948496
. Uninstalling this specific update solved the problem.
We found that our WINS 1C record had several values, the first value being 0.0.0.0. This caused a small number of NT workstation clients to not be able to authenticate. We deleted the entry on each WINS database, and re-registered each DC using “NBTSTAT -RR”.
For me, this error popped up after the system became unresponsive. I was unable to connect to the machine via RDP or file share and a reboot was needed in order to get the machine back online. Once I dug deeper, I found that there was a problem with the Veritas Patchlink Update Service (the process name is GravitixService). This service would consume most of the resources of the box causing the server not to respond to requests. As per ME953612
, this issue requires a patch from the vendor for Patchlink. I ended up just removing the agent.
We had a strange problem with our Windows 2003 SP2 servers not accepting network credentials or throwing RPC errors. These errors seemed to come out of nowhere. The only way to temporarily fix the problem was to login with a local account and reboot the servers. After the reboot everything was fine. The problem only affected about 10 to 15 of our servers and there seemed to be no commonality as to which ones were affected and which ones were not. But the problem was steadily getting worse.
I opened a call with Microsoft and they had two suggestions:
1 - Make sure that your NICs do not have any power settings that might be causing them to go to sleep. Check for a Power option in Device Manager and turn it off or change it to don’t go to sleep.
2 - ME936594
- Network related problems after installing Windows 2003 SP2.
Our servers didn't have power settings for the NICs. Microsoft told us to use these settings to eliminate the problem. So we are pushing out the following registry entries to all 200+ servers to fix the problem.
So far it has been about a week and the problem has not reoccurred on any server that has been patched. We have over 100 servers patched so far.
I received this error after moving several Windows 2000/2003 servers from a network with a Windows NT 4.0 PDC (no BDCs) that is located across a T-1 (the servers were moved to a managed data center). Originally, the servers were authenticated on the NT 4.0 domain. Once moved, the servers could not associate with a domain controller. This problem was resolved by resetting the secure channel and resetting the computer accounts as per Microsoft ME216393
. After performing the secure channel reset, the issue went away.
An installation of WinGate Proxy Server prevented various network services from running correctly, including NetLogon. The workstations that attempted to access the server, reported EventID 5513 from source NETLOGON. Removing WinGate fixed the issue.
- Error: "Not enough storage is available to process this command" - According to ME821546
, this problem has been identified as an issue that affects Visual Basic 6.0 n-Tier applications that are using COM+ packages that have been exported as an "Application Proxy" and installed on a client "Citrix" server. The "Authenticated Users" group must be given the "Impersonate a client after authentication" user right. This can be achieved in Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment.
Without the right the "Services.exe" process (which runs the COM+/DCOM sub system) will start to eat up Non-Paged Pool memory until it is gone, causing the Server to quit responding. This error is logged to the system event log.
To resolve this issue, identify the user account that is used to run the AFS Packages, and then assign the "Impersonate a client after authentication" user right to that user account. To do this, follow these steps:
1. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
2. Expand Local Policies, and then click User Rights Assignment.
3. In the right pane, double-click Impersonate a client after authentication.
4. In the Local Security Policy Setting dialog box, click Add.
5. In the Select Users or Group dialog box, click the user account that you want to add, click Add, and then click OK. (Adding the user group "Authenticated Users" fixed our issue.
6. Click OK.
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 1054 from source Userenv. After disabling this item in the network card properties, all these errors were gone.
In my case, this is related with a network card that is hidden in device manager. This occurred in a virtual machine converted from a physical server. Old network adapter remained unremoved in device manager but to remove it one has to declare the environment variable devmgr_show_nonpresent_devices=1 (see ME269155
). Removal of hidden network card was a solution for my case.
- Error: "There are currently no logon servers available to service the logon request" - See ME271925
- Error: "The remote procedure call failed and did not execute" - See ME911799
Also check ME247782
and the links to "Troubleshooting network problems", "Dell Support Document Number: TT109223
9", "IBM Support Document id: MIGR-58745", WITP75930
for additional information on this event.
In my case, the Terminal Server (Windows Server 2003 R2) has two NICs. One of them is connected to the G.SHDSL Router/Modem and the other one is on Ethernet backbone and communicating with DC/DNS (Windows Server 2003 R2). I have received this error after Event ID 5783 from the same source. The problem was resolved after changing the connections order for "Adapters and Bindings" as LAN was on the top (Network Connections-Advanced Settings).
In our case, we had this problem on our NT 4.0 BDC (with Exchange 5.5) in an AD 2003 domain. I solved the problem by activating Netbios over TCP/IP on the PDC. After that, it is necessary to restart the Netlogon service on the BDC.
This event will occur when creating trusts between Windows 2000 and Windows 2003, if the DNS server has not been configured properly. To fix this:
1. Configure Windows 2000 DNS Server Active Directory integrated zone to allow zone transfer to Windows 2003 DNS server
2. Configure Windows 2003 DNS Server Active Directory integrated zone to allow zone transfer to Windows 2000 DNS server
3. Add Windows 2000 AD integrated zone to Windows 2003 DNS server as Secondary zone
4. Add Windows 2003 AD integrated zone to Windows 2000 DNS server as Secondary zone
5. Ensure WINS records have been added to both Windows 2000 and Windows 2003 WINS server for the trust domain
5. Setup the trust
- Error: "Not enough storage is available to process this command" - Because of out of memory errors, at the same time we looked at the swap file. It was smaller than the recommended size. After increasing the swap file size, this 5719 error went away.
In our case, the remote registry service was stopped. We started the service and all is well.
If the client is on another subnet than the domain controller, and the DC has the Windows firewall enabled, make sure these ports are open:
- UDP 53 for DNS
- TCP 135 for RPC
- TCP 445 for SMB (part of File and Printer Sharing)
- TCP 1025
- TCP 389 LDAP
To troubleshoot this, enable the firewall log in Control Panel -> Windows Firewall -> Advanced tab -> Security Logging Settings. Now retry your connection and then check the c:\windows\pfirewall.log file.
I had the problem on some of my Windows XP Professional clients in an AD 2003 domain. The built-in NIC was a SIS 900 10/100. I solved the problem by using the (older) NIC driver from Microsoft and not the one provided by SIS. The error went away after rebooting.
We experienced a problem were we could not transfer (via FTP) a file to a server and received this error message in the System event log. Access was being denied and we could not connect. All user accounts showed up under the administrators group with SIDs rather than user accounts. We found that the primary WINS server was hung up and could not resolve names. We rebooted the WINS server and everything started working normal.
This problem was also causing my Citrix Web Client to report "ERROR: The Metaframe servers reported an unspecified error" to users, when attempting to log in. It seems that the last Domain Controller the server had contacted failed, and although three others were available, it refused to use them when authorization was subsequently needed. I added WINS entries and added the Domain Controllers to the HOSTS file. I rebooted and everything was OK.
- Error: "Not enough storage is available to process this command" - In our case, this problem was caused by a homegrown application that was acquiring up all of the available TCP/IP ports and not releasing them. As soon as we stopped this application all was well. We modified the application to correct the problem.
I ran into this problem on a Windows XP workstation under AD. Disabling the terminal services service solved it instantly.
We got this problem on a Windows 2003 member server in an NT4 domain. Simply look at the network configuration and add WINS servers, which are essential for 2003 server to declare itself to the domain controllers in this type of domain.
This behavior can occur when the WINS Client (TCP/IP) protocol is bound to the internal network adapter. This adapter is only for clustering. See ME249909
for more details.
- Error: There are currently no logon servers available to service the logon request - See ME269119
From a newsgroup post: "When I was trying to fix this problem, I found out that the PDC and BDC were using the NICs in a teaming load balance configuration. We broke the teaming and disabled the second adapter. This fixed the problem for us".
for information on how to establish trusts with a Windows NT-Based Domain in Windows Server 2003.
Verify that general network connectivity is available. See MSW2KDB
for more details on this event.
We removed all trust relationships to the decommissioned legacy domain, but the problem persisted. Removing the entries of the old domain in the lmhosts file solved the problem in our case. The server in question is an NT4 Server box.
In our case, an update of our NIC drivers helped us to get rid of this problem. The NIC in question was a Broadcom NetXtreme Gigabit adapter.
- Error: "Windows cannot find the machine account, No authority could be contacted for authentication" – If this error appears on the machine that is hosting DNS and the machine is not a DC, you may need to change a startup order of the Netlogon service. In registry go to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon", and in the DependOnService key add DNS after LanmanWorkstation. In my case, this solved the problem.
After the DCs of a child domain were just simply shut down without DCPROMO, I followed the articles ME230306
, but there was still was some traces left of the child domain. After searching the web, I found a link on the Minasi forum that suggested to remove a lingering Trust from "Domains and Trusts". That did the trick. See the link to “Minasi forum topic ID 9485” for details.
If you have NT workstations in a Win2k environment, a possible cause for this error can be found in faulty configuration of DHCP; the "Enable Updates For DNS Clients That Do Not Support Dynamic Update" option must be checked, also the same thing for "Always Update DNS".
- Error: "There are currently no logon servers available to service the logon request" - If you are using MS ISA with firewall clients on your workstations, try uninstalling and reinstalling the MS firewall client. This solved the problem in my case.
Running in a static IP environment NT4 Domain with Win2K Member Servers, resolving this problem was to add the PDC and BDC to the "hosts" file.
My WinNT 4.0 PDC had secondary WINS address changed to an IP other than itself. Per ME150737
, this can cause issues with Domain connectivity. After setting the WINS primary and secondary addresses back to the PDC, everything cleared up.
This can happen if you have a domain name specified under "Active Directory Domains and Trusts" that does not exists or cannot be reached. To fix the problem go to "Start->Programs->Administrative Tools->Active Directory Domains and Trusts". Right click your domain name and select Properties. Go to the Trusts tab and delete any trusted domains that do not exist or cannot be reached.
- Error description: "There are currently no logon servers available to service the logon request" - I found this on a Windows NT 4.0 Workstation client PC. The PDC for this LAN was also the LAN’s DNS/WINS server, but it was not specified in the client PC's network stack. I added the PDC as sole DNS and WINS in the client PC's network stack (so that the client PC could find the PDC for domain disengage/join functionality), then disengaged the client PC from the domain and rejoined.
We fixed this problem on a Windows 2003 member server in an NT4 domain by making the netlogon service dependent on WINS before starting. After this, the error was gone and I could log into the box with a network account.
We were also getting this error on a Windows 2003 Member Server (in a Windows 2003 AD) which had its own DNS Server Service Running. The problem was that the server was booting up and several services were trying to run (including NETLOGON) before the Member Servers DNS Server Service had started. This resulted in no name lookup for the Active Directory Domain and hence could not contact any Domain Controllers.
After setting the correct TCP/IP settings, the problem persisted. It appears that the problem was the AVM ISDN Card. I deactivated the "AVM Fritz!webPPP overISDN Network Adapter".
Possible causes are wrong entry’s in the LMHOST file on the BDC (e.g., when you have an IP range change in your LAN). When wrong referrals to BDC's are made it might cause the BDC to stop replicating with the PDC. Also starting the server manager or user manager on the BDC becomes impossible (No PDC found message). Solution is to change the LMHOST file on the PDC to the right settings and reboot both PBC and BDC.
A number of new client systems with Intel Pro 1000 cards, talking to Cisco 3500 switches, would not get a DHCP lease from the servers. After reviewing the servers for anomalies, we called Microsoft who recommended the following registry entry. After making the change, we were able to successfully get a DHCP lease and consequently log into the domain.
Another potential issue found was that the switches were set to autosensing, as was the client. Even when the client was set to 100/full-duplex, we could not always get connectivity. It was not until the ports on the managed switch were set to the same speed and duplex as the card that communications occurred consistently. The same problem was duplicated on a Cisco 6500 series as well. This occurred only when the card on the client was a 10/100/1000. A PRO 100 card, as an example, did not exhibit the same behavior. This same fix is related to some general DHCP errors and warnings as well.
In my case, setting the NIC to 100Mps and Full Duplex, instead of auto-negotiate fixed the problem.
I just migrated our network from NT to W2K3. I replaced our old PDC and BDC with new machines. One stand-alone server of our was having this problem, and when I checked out the "imhosts" file, there was an entry for: "OldPDCName x.x.x.x #pre #dom". So I deleted the entry, since that PDC no longer existed, and the problem vas fixed.
This happened after stopping one of the domain controllers. I guess that Netlogon is trying to connect to the same DC it connected previously. Since this DC has been stopped, Netlogon can neither find this one nor the other running DC and fires this event.
IIn my case I tried ME163204
but it didn't fix my problem. Eventually I found out that the problem was with the speed of my PC and the fact that none of the other services are fully loaded when netlogon attempts to contact the domain controller. I slowed down netlogon allowing other services to load completely. My problem was with a Dual PIII, SCSI Raid 5 which booted in a couple seconds.
Removing the trust relationships for non-existent NT4 domains eliminated this error on my Windows NT4 DC.
I cleaned out stale/invalid entries in my LMHOST and HOST files located at C:/WINNT/System32/Drivers/etc and the problem was resolved. I could confirm this by going to Active Directory Sites and Services and performing a replication between the domains. The event log entries for File Replication Services had event ID 13516 (source NTFrs). Also, the 5719 event no longer appeared at regular intervals.
We found that removing the 2000 server from the domain and rejoing solved the problem.
for a description of the Netlogon service on Windows NT 4.0.
- Error: "The RPC server is unavailable." - It usually indicates a lack of connectivity between the computer reporting the error and a domain controller for its domain. It could be improper TCP/IP settings, bad cabling, faulty network card, etc… See also the link to Error code 1722
- Error: "There are currently no logon servers available to service the logon request." or "No domain controller available" - This is typically a connectivity problem. See ME228901
The same error can occur if the workstation and stand-alone server computer accounts are mistakenly treated as LanMan backup domain controllers (BDC) by the primary domain controller (PDC) - see ME180114
If this error occurs on Windows NT 4.0 Terminal Server, see ME232476
. To resolve this issue, you must either edit the existing values or add the following registry entries for both MaxWorkItems and MaxMpxCt to the servers from which the clients are requesting resources.
says that this can occur also due to a limitation on the UDP packet size when Windows Kerberos Authentication package is using UDP. The article provides information about changing the Kerberos configuration so it will use TCP instead of UDP.
As per ME221790
, if running IIS, the server may be running out of work contexts for a particular client. In Windows 2000, there is a hard-coded upper limit of 125 work contexts for all types of clients (Windows NT, Windows 95, and Windows 98).
specifies that this error can occur when you upgrade a Microsoft Windows NT 4.0-based primary domain controller (PDC) or backup domain controller (BDC) that uses the FAT file system to Windows 2000 Server or Advanced Server, and you do not convert the file system to NTFS during the Setup process. See the article for resolution.
describes a situation when this event can occur due to a slow network a PPTP connection would drop packet fragments that arrive out of order. The latest Windows 2000 Service Pack should solve the problem.
- Error: "Not enough storage is available to process this command." - Microsoft has confirmed that this is a problem in Microsoft Windows 2000. This problem was first corrected in Windows 2000 Service Pack 3. It occurs due to a nonpaged memory leak in tcpip.sys. See ME317854
- Error: "There are currently no logon servers available to service the logon request." - As per ME202840
, the Spanning Tree Algorithm feature on a switch can cause this.
This error may occur when the computer browser service is hung.
As per ME310339
: "One possible cause of this error is that you have run out of Buffer space in the NetBT Datagram buffer".
Error: "There are currently no logon servers available to service the logon request." - This can be also be caused by a bad wireless connection (e.g. poor signal).
Error: "The authentication service is unknown." - no info
Error: "There are currently no logon servers available to service the logon request" - This error also appears when you have multiple domains and the computers you have configured are not on a network where their computer accounts reside e.g. they must communicate through a firewall for authentication. Try entering static entries in the LMHosts file for the authentication PDC/BDC and if this does not help, additionally add Wins and DNS IP addresses in "Local Area Connection" TCP/IP settings.
We got this error when a trusted domain was removed from the network. The trust relation was still there and this was causing this error. After removing the trust relationship the error no longer occurred.
Error: "There are currently no logon servers available to service the logon request." - The reason was that Active Directory had settings for a trusted domain that did not exist. When I deleted all references to that trusted domain, Windows quit logging the events.