Annoying NetBios from latest Windows 10 build

Hi SalishSwede 

I have searched on the Internet and found some articles, you may check.

https://arstechnica.com/civis/viewtopic.php?t=832330

https://support.solarwinds.com/SuccessCenter/s/article/Disable-Netbios-UDP-137-traffic

https://community.microfocus.com/t5/Archive-Discussion-Board/Outbound-NetBios-traffic-to-several-Public-IP-s-over-UDP-137/td-p/1555549

https://support.microsoft.com/en-in/help/323357/how-to-configure-tcp-ip-networking-while-netbios-is-turned-off-on-a-se

Hi

Just a quick note (in case this is of interest to anybody reading this thread) and relating to the last link (the Microsoft one; see the note that Microsoft have included about DHCP configuration) I use DHCP option 43 to configure all my Windows machines to disable NetBIOS over TCP/IP, so the Windows machines are now showing the below configuration:

ipconfig /all

---cut---
   DNS Servers . . . . . . . . . . . : 10.11.11.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

As can be seen below, the required hex string is 01:04:00:00:00:02 (just typed that so it can be swiftly copied and pasted).

Kind regards to all,

Briain

PS An amusing footnote:

Or course, I must also confess that when I initially created the rule, all seemed to be working just as expected until one day, a Ubiquiti WAP firmware update resulted in my WAPs no longer being discoverable by the UniFi 'server' package (the Ubiquiti management software). After SSH-ing into the WAP and looking at its [now bizarre] configuration, I eventually figured out that the WAP must have been responding to that DHCP option 43 and misinterpreting its hex string (it was overriding the default setting on where it should 'look' for the wireless server). After digging into the Ubiquiti web site, I found that one can indeed also use vendor specific DHCP option 43 to define the address at which the wireless server resides (I believe that you can also do that with Cisco WAPs) and after looking once again at my option, I realised that I foolishly hadn't configured the vendor ID aspect of it (it should be set as MSFT 5.0 - just as is shown in the above image - to ensure that only the Windows machines attempt to interpret the hex string). With my initial misconfiguration, everything on my network was capable of being configured by my 'global' option 43 (but fortunately, only the WAP - and that only after an update - and Windows boxes were actually 'listening' for it) and once it was all set up as is shown in the above image, all was then well again (oops; oh well, I've always reckoned that the best way to learn is to break things and then figure out how to fix them). :-)

 Thanks Brian,

I'll give that a try.

 Thanks Brian,

I'll give that a try.