Ошибка 4319 netbt

                Локальная таблица NetBIOS-имен

       Имя                Тип          Состояние
    —————————————————-
    SRV1           <00>  Уникальный  Зарегистрирован
    WORKGROUP      <00>  Группа      Зарегистрирован
    SRV1           <20>  Уникальный  Зарегистрирован
    WORKGROUP      <1E>  Группа      Зарегистрирован

NIC2:
Адрес IP узла: [192.168.0.11] Код области: []

                Локальная таблица NetBIOS-имен

We have received many alerts on the error Event ID 4319 as seen below.
Event log: System
Event Source: NetBT
Event ID: 4319
Message Contents: A duplicate name has been detected on the TCP network.
The IP address of the computer that sent the message is in the data.
Use nbtstat -n in a command window to see which name is in the Conflict state.

The cause of this issue has been systems that have more than one network card, this is more common in laptops that will use a hardline in the office. you can see this by using the command ‘nbtstat -n’ multiple network cards have the same NetBIOS name.

To correct this behavior you could prevent both network cards from connecting at the same time, although that is not a viable tactic to us. What we have decided to do is disable NetBIOS over TCP/IP on the wireless card.  If you are doing this remotely you can run the following commands.

First you will need to know what the index number of your network card is, you can retrieve that with the following command.

wmic nicconfig get caption,index,TcpipNetbiosOptions

You can see the index number listed next to each network card name, in this case we are looking for the wireless card, that would be index number ‘2’. You can also see the TcpipNetbiosOptions column is showing a ‘0’, that means it is set to DHCP server options or fail over to enabled if DHCP has no options set. we will need the TcpipNetbiosOptions value to be ‘2’ to disable NetBIOS over TCP/IP, and with the index number we can run the following. (Change the index to the nic relevant to your issue.)

wmic nicconfig where index=2 call SetTcpipNetbios 2

Hi,

We have an Server 2016 that is out Hyper-v server. this server has 4 nic’s.

nic 1 is not beening used.

nic 2 is connected to the LAN ( NO IP and used for Hyper-v )

nic 3 is connected to the LAN 10.0.10.40 ( is GW and DNS is set)

nic 4 is connected to the LAN 10.0.10.22 ( No GW and NO DNS is set)

in our DNS I can see a single entry for the server that point to nic 3 and
we are not running WINS

Now in the Application logs of this server we see the error 4319 NetBT. The event says run the nbtstat-n

to see which name is in the Conflict state.

I did run it and see this, but see any info regarding any conflict.

Ethernet:
Node IpAddress: [0.0.0.0] Scope Id: []

    No names in cache

NIC4:
Node IpAddress: [10.0.10.22] Scope Id: []

                NetBIOS Local Name Table

       Name               Type         Status
    ———————————————
    NTS91          <00>  UNIQUE      Registered
    mydomain     <00>  GROUP       Registered
    NTS91          <20>  UNIQUE      Registered

NIC3:
Node IpAddress: [10.0.10.40] Scope Id: []

                NetBIOS Local Name Table

       Name               Type         Status
    ———————————————
    NTS91          <00>  UNIQUE      Registered
    Mydomain     <00>  GROUP       Registered
    NTS91          <20>  UNIQUE      Registered

NIC1:
Node IpAddress: [0.0.0.0] Scope Id: []

    No names in cache

vEthernet (Mydomain_SW):
Node IpAddress: [169.254.246.120] Scope Id: []

                NetBIOS Local Name Table

       Name               Type         Status
    ———————————————
    NTS91          <00>  UNIQUE      Registered
    Mydomaion     <00>  GROUP       Registered
    NTS91          <20>  UNIQUE      Registered

Any idea what is the case of the conflict?

Thanks

Shahin

Posey’s Tips & Tricks

How To Troubleshoot Bogus Duplicate Computer Name Errors

Brien troubleshoots how to fix a naming error when the error is the actual problem.

A couple of weeks ago, I upgraded some of my lab servers to Windows Server 2016. Although the upgrade process seemed to work flawlessly, my hectic schedule prevented me from doing an exhaustive post-upgrade review until a few days ago.  I won’t bore you with all of the details of my review process, but there was one step in the process that yielded some unexpected results.

I wanted to check the server’s System log to see if it contained any serious errors. I therefore opened the Event Viewer, clicked on the System Log and then used the Filter Current Log option to show any errors that had occurred. Most of the error messages were no big deal, but surprisingly I found numerous instances of NetBT error 4319. A closer examination of this error revealed that the system had detected a duplicate computer name somewhere on my network.

My immediate assessment was that the error message had to be erroneous. I work out of my home and only have about a dozen physical and a few dozen virtual machines on my network. I am the only one who ever makes any configuration changes, and I knew that I had not renamed any computers lately. Besides, the computer name (Hyper-V-2) has been dedicated to a specific physical server for the last five years.

I knew that the error was false, but I also knew that I needed to verify that no computer name conflicts existed on my network. I was also going to have to find a way of making the error message go away.

My first step in the resolution process was to take a look at the event properties. As you can see in Figure 1, the Event Properties dialog box indicates that a duplicate name has been detected on the TCP network. It also confirms that the server’s name is Hyper-V-2.mgmt.com, which is exactly what it is supposed to be.

If you look at the event description in the figure above, you will notice that it says that the IP address of the computer that sent the message is in the data, and that you can use nbtstat -n to see which name is in a conflict state.

I therefore opened an elevated Command Prompt window and executed the nbtstat-n command. Upon doing so, I was presented with a list of three occurrences of the computer name that was in question. Each of these occurrences was listed by network adapter name and by IP address, as shown in Figure 2.

As I looked at the information in the figure above, two things quickly became apparent. First, the last address on the list was the server’s own IP address, so that listing wasn’t an issue. Second, the other two IP addresses that were shown are part of my DHCP address scope. Clearly, these addresses were not statically assigned.

Still wondering how I could have a computer name conflict, I entered the IPConfig /all command. This command displays an exhaustive list of the computer’s IP address configuration. The resulting data confirmed that all three of the IP addresses that had been cited within the nbtstat results were assigned to the local server. In other words, the server has three network adapters, each of which has its own unique IP address. For whatever reason, Windows did not like the fact that my server had three network adapters.

Of course it is totally normal for a physical server to have multiple network adapters, so I wasn’t completely sure why an error was being triggered. As I further considered the problem, I began to think about how the computer name is used within the Windows networking stack.  To make a long story short, I traced the problem to the File and Print Sharing for Microsoft Network component, which you can see in Figure 3. This component was enabled on all three of my network adapters. Disabling File and Print Sharing for Microsoft Networks on all but one of my network adapters caused the error to go away.

As you can see, there was a simple fix to the problem. Even so, I had never seen this particular issue before, so troubleshooting the problem took some time.