We are a development shop where all 50-odd workstation computers run Windows 7 SP1 and most of our 20-30 servers are Server 2008 R2 or Server 2008 (there are a few scragglers still on Server 2003). We have a flat, single subnet environment where servers and workstations are in the same network. We have DNS servers with dynamic DNS registration enabled and currently we have WINS servers too. In performing some diagnostic Wireshark packet capturing on our network for an different issue, we've seen that there is quite a lot of NetBIOS broadcast noise on our network.
We are looking to disable NetBIOS broadcast by changing the node type of our workstations (and possibly servers) to p-node (or peer only) where WINS will be used as the only name resolution method. We will most likely configure it via the 043 DHCP option to ensure that even non-domain joined clients participate on our network without broadcast. We considered using the Group Policy approach to roll-out the registry key, but this may have detrimental effects on our laptop users when offsite (such as on their home networks).
Here are my questions:
- will this cause issue with any of the few Windows Server 2003 servers we have left, or for any of our Windows 7 clients or other newer Windows servers?
- Further to that, is it even advisable to prevent NetBIOS broadcast or should the noise just be ignored as a typical part of the network?
- We've also considered disabling NetBIOS completely. However, the only way I know of doing so is to disable NetBIOS of TCP/IP. I assume this is the only NetBIOS method left in Windows 7? So disabling this on the NIC (or for the whole PC) disables NetBIOS completely?
- Will disabling NetBIOS mean that the FQDN/long name (eg, companyname.tld) of the domain need to be used for logon purposes due to the short-name (eg, COMPANYNAME) no longer being available? (ie, [email protected] has to be used instead of COMPANYNAME\username) If this is the case, will Windows still show
Logon to: COMPANYNAME
or will it showLogon to: companyname.tld
.
In summary, we're after some guidance on what is common practice for organisations to do with NetBIOS communications these days and the experiences of others when making changes to NetBIOS network configuration similar to my topology.
I've found the below topic which links to a few others, but I'm still not convinced. I'd like to know the steps people took to 'disabling' or limiting NetBIOS and any shortcomings or advantages of doing so.
Edit:
As per questions; running Active Directory, functionality level 2008, prepped for 2008 R2, soon to be R2 functionality.
And I received a decent "why" question, to which I said:
I'm of the opinion that if it isn't needed, it shouldn't be on. Plus, there is a lot of noise on the network from broadcast resolutions - sure these packets are tiny, but I just was after some clarity on what others (perhaps in bigger organisations) have done regarding NetBIOS.
If you don't have any applications that need it, just take down the WINS server and disable NetBIOS over TCP/IP completely, I'd say. Short names still work just fine in a DNS-only network by virtue of search suffixes.
If clients are set to the default NetBIOS setting (enabled except if DHCP says not to), then you can simply set the flag in the DHCP options to disable NetBIOS, under the
Microsoft Windows 2000 Options
vendor class - set an0x2
under the001 Microsoft Disable Netbios Option
- see this MS KB for details.In addition to what Shane posted in his answer, take care not to slay the wrong dragon. Yes, NetBIOS is chatty, but it's not neccessarily a problem that needs to be dealt with. Broadcast traffic, whether it be at layer 2 (ARP, Spanning Tree BPDU's, etc) or layer 3 (NetBIOS, etc) is a normal component of network traffic and communication. The key is to know whether or not the particular broadcast traffic you're focused on (ARP flooding, broadcast storm, multicast storm) is contributing to network issues (most likely congestion) which can manifest itself in duplicate ACK's, packet loss, TCP retransmits, TCP fast retransmits, etc.
My suggestion would be to run a packet capture on your switch (if the switch supports port mirroring/monitoring) with packet capture software that can give you a view of the percentage of traffic that is broadcast traffic as a whole and also what percentage of traffic is NetBIOS broadcast traffic. NetBIOS traffic that is not broadcast traffic (meaning it's unicast traffic) shouldn't present any more of a problem than any other unicast traffic.
I don't know of any hard numbers but if your percentage of broadcast traffic is above a few percent (not more than 5% probably) then you probably have network congestion that's manifesting itself in the symptoms I described above. At that point you should track down the cause of the congestion and resolve it.
One source of network congestion, for example, is heartbeat traffic related to load balancing or NIC teaming.