Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 4321 Source: NetBT

The name "<server name>" could not be registered on the Interface with IP address <ip address 1>. The machine with the IP address <ip address 2> did not allow the name to be claimed by this machine.
On Windows 10 machines in our Windows domain environment we had that error with the following name part: "DOMAINNAME     :1d". The error started to occur after we disabled NetBIOS over TCP/IP through a DHCP scope option. See EV100655 (How to disable NetBIOS over TCP/IP by using DHCP server options). It was resolved by disabling Computer Browser service on the machines.
In my case, I got rid of this error by changing the IP address assigned to my computer.
In my case, I had created a new DC and for no apparent reason it started logging NetBT errors every few minutes. I followed another post on here from Joe Donner (many thanks by the way Joe) and restarted the browser service on the DC in question and the DC that was mentioned in the error message. All appears to be fine now.
I had 2 NICs, (Ethernet + wireless). Both tried to register on WINS domain with same name (my computer name) so this event was generated. If this is your case too, there is nothing to worry about and you can ignore it (or disable one of the NICs).
See the information about this event at T736044.

In my case, a W2k3 member server (2003 domain) suddenly started to generate this error, at different time intervals. I added the WINS server in the network configuration and the problem was solved.
I began experiencing system (WinXP Home, SP2) crashes, and review of the event log revealed this error. I had just downloaded some photos from a digital camera, and I've noticed that one of the comments here described a similar problem. Per the suggestion in that post, I renamed the computer, re-booted, and now all seems fine. In hindsight, I had just pulled the USB cable out of my PC's USB port without either turning off the camera or ''safely removing hardware''. That may or may not have contributed to this situation.
I uninstalled the Cisco VPN client and that corrected the issue for me.
I uninstalled the Cisco VPN client and that corrected the issue for me.
In my case (a Windows 2000 domain), a WindowsXP machine generated Event ID 4321/NetBT and 1058/Userenv errors after connecting a digital camera using USB port. I tried some suggestions here and didn't fix the problem. Finally I let the computer re-join the domain with a new name and the problem was fixed.
In my case, I moved a share from one server to the other and wanted to rename that new server with the name of the old server. I took the old server offline and added the ip address of the old server to the new server. It turned out that I had to set the ip of the old server as the primary ip on the new server and only then I was able to join the server to the domain.
I got this error on a couple of computers. It turns out this was being caused by the Symantec Ghost that was installed. The computers were imaged from one computer which originally had the problem. Possibly this computer was also imaged. Each of the computers that had this error were trying to register themselves as the original computer on the network adapters. After un-installing and re-installing Symantec Ghost on the affected machines everything was cleared up.
In my case, I just disabled "lmhostlookup" in WINS (TCP/IP settings) and the problem was solved.
In my case, the primary WINS address was wrong on both NICs on the server. I corrected them and restarted Computer Browser service.

In my case, the clock on a DC was wrong because it ran in a virtual machine with a wrong configuration on the ESX server. This caused various errors for authentication (Kerberos) and so the second DC was unable to update his DNS record.
In my case, I wanted to forward DHCP broadcasts from a remote site back to the central site, however, I enabled the forwarding of NetBT as well which resulted in the DC at the remote site not being able to become the segment master browser. As soon as I limited the forwarding to JUST the DHCP client requests, the error on the DC at the remote site ceased.
I received this event after installing a new router on a seven PC network running XP Pro with no server OS running. All seven machines had internet access and could ping one another, but attempting to access shares failed. Turning off all PCs, resetting the router, and starting the machines one by one solved the problem.
I got this error with an incorrect subnet mask on a Windows 2003 Server. I corrected the subnet mask, rebooted, and the error did not re-occur.
I had installed a NIC temporarily for troubleshooting an unrelated problem. I removed the NIC without un-installing the drivers. Event ID 4321 began after I brought the machine back up on the original NIC. There was still IP information in the registry bound to the NIC I had removed. I used Device Manager to remove the absent hardware, which removed the bindings. To get Device Manager to display devices not currently installed, either set the environmental variable or enter at a command prompt "set devmgr_show_nonpresent_devices=1".  If you use the command prompt, then on the next line type "devmgmt.msc" to open Device Manager. Go to "View" and select "Show Hidden Devices".  You can then uninstall the drivers for the removed NICs, which also removes the bindings (see ME241257 for additional information).
I fixed this error by adding the network address range to the Trusted Networks in the Norton Internet Security Firewall configuration settings.
In my case, cleaning WINS (duplicated IPs) & runing "nbtsat -r" on the affected server, followed by a restart of the server solved the problem.
In my case, the problem was solved by stopping and disabling the Computer Browser service.
If you receive this event after you add a Samba Linux server to a Windows Server 2003 domain or to a Windows 2000 domain, then see ME924853.

In my case, the server had a /8 ( netmask while the other machines had /16 (255.555.0.0). I changed the server's mask to /16 (255.555.0.0) and the problem was solved.
I cleared this event by adding a WINS server entry onto the offending clients network settings. The WINS server was the server that would not allow the offending client to claim the address.
I experienced this error on a Windows 2003 Domain Controller which I had shut down to remove a fault SCSI card. When booted up again, it started logging this error in the event log every couple of minutes. The machine that "did not allow the name to be claimed" was another Windows 2003 Domain Controller. No WINS is present on the network. DNS seemed in order. I restarted the Browser service on both machines, and restarting it on the second domain controller seemed to do the trick.
This event occurred after installing Windows 2003 SP1. The Dell server is connected to a Dell Powerconnect Switch. Turning the "Spanning Tree Protocol" feature off solved the problem.
This error was appearing on my Exchange Server. We do not have WINS Server and I have found several scenarios like this on the net. In my case the Exchange server was in conflict with the PDC emulator role server for Domain Master Browser. I set the Computer Browser Service to manual on the Exchange server, rebooted, and the event was gone.
This problem can occur on dualhomed SBS boxes if the external NIC is higher in the binding order than the internal NIC.
I received this message on an XP workstation with static IP and an incorrectly configured subnet mask. When I fixed the subnet mask, the system worked perfectly again. If you get this error, it pays to triple-check that all your basic network settings (e.g. IP address, subnet mask) are correct.
In my case, this problem occurred after using RAS. After the problem occurred, I was unable to browse and print from Windows 95 and 98 clients. To resolve the problem I removed the static entry for the RAS Server in the WINS database.
If you receive this event when you start a Microsoft Windows XP workstation, see ME822659.

As per Microsoft: Your computer cannot access the network because it could not contact the Windows Internet Name Service (WINS) server to register its name . This could be caused by loss of network connectivity". See MSW2KDB for additional information on this event.

This problem is directly related to DNS, and ME291382 deals with it. You will also probably see Event ID 1054 messages in the application logs. In this case, a recent application install led to DNS being reconfigured, which resulted in the client losing Domain communication.
NetBIOS code "0: - Upon performing a check of "nbtstat -an" at the server, it lists <server name> a status of "Conflict". In order to resolve this, I opened up WINS, right mouse clicked on Active Registrations, Display Records, clicked Find Now, found the <server name>    [OOh] record and deleted the entry. I then went back to a command prompt and ran "nbtstat -R", rebooted the server and the error went away and upon a recheck of nbtstat -an, the server name was registered.

Windows Event Log Analysis Splunk App

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



Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.