So long NetBIOS, it’s been fun!

Without going too far down the “history of NetBIOS” rabbit hole, this protocol has been included in all versions of Windows since Windows for Workgroups, and including Windows7. Back before DNS was adopted as the primary name resolution protocol, NetBIOS was used for PCs in workgroups to find each other by name and communicate. NetBIOS over TCP/IP is a non-routable broadcast protocol and is by nature very chatty on the wire. WINS was created to centralize and resolve NetBIOS name to IP address registrations but DNS is still a much more efficient method and became the basis for Active Directory in Windows 2000.  The problem with overly chatty broadcasts is that all hosts constrained within the boundaries of a broadcast domain (L3 VLAN) have to process every packet that is broadcasted. This can be especially taxing in L3 VLANs with a large amount of hosts.

While Windows has functioned fine without NetBIOS for over a decade, Microsoft continued to support the protocol for legacy applications that required its use.   Having just built a pristine environment with Windows7/Server 2008 R2 and all the latest technology, I decided to explore the elimination of NetBIOS from my environment.

So, why bother?

The number one reason this effort is worthwhile is the elimination of a broadcast protocol from your network stream. This will ultimately free up network interface usage and CPU cycles that are currently processing each packet that any host in the VLAN broadcasts. Run a network trace and you will see an alarming number of name query broadcasts sent and received via UDP/137. As you can see from the network capture below, 66.16 is broadcasting a NetBIOS name resolution request for a host called DC2.

Locally, on a client running NetBIOS run the nbtstat –n command to display the local name table. If you can display this table, that means NetBIOS is alive and well. The wireless adapter is disabled on this client so there will be nothing in the cache for that connection.

Other reasons to abandon NetBIOS include maintaining antiquated browse lists, worrying about which resources might be accidentally visible in those browse lists, and fighting browser master wars. I have no need for this protocol in my network and will take steps to remove it.

How to disable NetBIOS over TCP/IP

There are a few ways to go about disabling NetBIOS programmatically, I want the path of least resistance.  As with any process, you can accomplish this goal manually, but that is tedious, time consuming, and ineffective. While this task can be done via GPO Preferences, this really isn’t the cleanest method either. You would need to create a new GPO Pref registry item targeting the NetBiosOptions value in the PC’s network interface key path. The problem with this method is that each PC will have a different GUID assigned to its network interfaces, highlighted below. You would first need to determine all applicable GUIDs in your network and push this policy so that each can be updated individually. No easy task.

Luckily, if you use DHCP to assign IPs to your clients there is an easier way. By default all Windows clients are set to “default” under the NetBIOS setting portion on the WINS tab in their NIC’s TCP/IP settings. This default setting allows all clients that use a DHCP server to use the NetBIOS settings as defined by that server.


This setting corresponds to the “NetBiosOptions” registry entry, in the aforementioned key path, who’s value of 0 means that the default setting is enabled. Manually disabling NetBIOS above would set a value of 2 on this entry in the registry.


Great! So we can control NetBIOS via DHCP, this is certainly easier than the GPO Pref method. From your DHCP snap-in, navigate to the “scope options” portion of the scope you would like to change. Right-click—>Configure Options. Select the Advanced tab and change the vendor class dropdown to “Microsoft Windows 2000 Options.” You will now see a 001 option to disable NetBIOS. Select it and change the data entry to 0x2, click OK to activate.


**This will not take affect until your clients renew their address leases and pull the new scope options.


On the DHCP client with a renewed IP lease, you will see a new registry entry, in the same key path shown previously, called “DhcpNetBiosOptions” with the corresponding value you set in the scope.


This new key is only read by the system if the NetBiosOptions value is 0. Running nbtstat –n should now yield an empty name cache with no node address.


Another network traffic capture, assuming all clients in the scope have been updated, should yield no NetBIOS traffic. Keep in mind that disabling NetBIOS stops your ability to send broadcasts, not receive them.


Now without all those NBNS broadcasts you can keep tabs with what spanning tree is up to! Winking smile




NetBIOS over TCP/IP Configuration Parameters

MS KB313314


  1. Nice post...I look forward to reading more, and getting a more active part in the talks here, whilst picking up some knowledge as well..

  2. Curious to see if you implemented this in your respective network and what any fallout may have been?

  3. Hi Steve, at the time of this writing, the environment I built was 100% net new so I knew every piece going in and the requirements of all software. Nothing I implemented required NetBIOS so I was able to safely disable without issue. Before you take on something like this, eval all deployed software to make sure nothing requires NetBIOS. At this point it's likely only very legacy softs.

  4. Nice post. If it's helpful, I have a method of (effectively) disabling NetBIOS over TCP/IP (NetBT) using Group Policy. Take a look at my blog at:


Powered by Blogger.