LLMNR turn it off, then keep it off

GPO path: Computer Configuration > Administrative Templates > Network > DNS Client > "Turn off multicast name resolution" = Enabled. This writes straight to the policy-backed key below, there's no dedicated "LLMNR service" to restart, since it lives inside the DNS Client (Dnscache) svchost, so gpupdate /force or a normal reboot is all it takes.

reg add "HKLM\Software\Policies\Microsoft\Windows NT\DNSClient" /v "EnableMulticast" /t REG_DWORD /d "0" /f

Annoyingly, there's no equivalent GPO that covers NetBIOS on every adapter in one shot it's a per-interface registry value, so you loop over them.

$regkey = "HKLM:SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces"
Get-ChildItem $regkey | ForEach-Object {
    Set-ItemProperty -Path "$regkey\$($_.pschildname)" -Name NetbiosOptions -Value 2 -Verbose
}

For DHCP-addressed hosts, you can push this centrally via DHCP Option 001 ("Microsoft Disable NetBIOS Option") set to 0x2 on the scope statically addressed hosts won't pick this up, though. There's also a host-wide alternative: setting HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\NodeType (DWORD) to 2 (P-node) stops the client broadcasting NBT-NS queries at all, in favour of WINS/DNS only deployable via Group Policy Preferences or a startup script, again because there's no native GPO for it.

If something legacy still needs LLMNR or NBT-NS alive, the compensating controls that actually matter are SMB signing (see Microsoft's SMB security hardening guide — Windows 11 24H2/Server 2025 require it by default in more scenarios now), LDAP signing plus channel binding (SMB signing alone doesn't stop a relay to LDAP), and Extended Protection for Authentication, which ties NTLM auth to the TLS channel and target SPN so it can't be replayed cross-service even if signing's missing somewhere else. Disabling WPAD is worth doing too, but flag this before you do it: fully killing WinHttpAutoProxySvc can quietly break KDC-proxy-dependent clients (RDP Gateway, DirectAccess), which then silently fall back to NTLM, the opposite of what you wanted. New articles comming in the future.

If you've disabled this before and found it mysteriously back a few months later, you're not imagining it, and it's not usually one single cause.

In-place upgrades reset adjacent network state. Microsoft's own KB4013822 confirms in-place Windows upgrades wipe HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider and related network-adjacent registry entries. That KB is about network providers specifically, not NetBIOS by name, but it's the clearest official evidence that feature upgrades do mutate registry state in this exact neighbourhood treat "a feature update might undo this" as a real risk, not paranoia.

New adapters get a clean slate. NetbiosOptions lives per-interface, keyed by GUID, under ...\NetBT\Parameters\Interfaces\Tcpip_{GUID}. Every time a *new* adapter shows up, a VPN client's virtual NIC, a USB or Thunderbolt dock, a fresh driver install that creates a new interface instance, it gets its own fresh key, defaulting back to enabled. The disable-netbios project from hvs-consulting puts it bluntly: *"There is no GPO that disables NetBIOS completely, the settings of every network interface need to be changed. Even if this is done during installation, new network interfaces like USB Ethernet adapters or USB/Thunderbolt docks again have NetBIOS enabled."* There's a documented real-world example of this too Palo Alto's GlobalProtect virtual adapter has been reported (in their own community forum) re-enabling NetBIOS on every reboot regardless of what you'd set previously.

Local GPO doesn't self-heal; domain-linked GPO does. This next bit is my own read rather than something I found spelled out anywhere specifically for this exact setting, so take it as informed opinion, not documented fact: a domain-linked GPO survives drift because background policy refresh reasserts it every 90–120 minutes (that interval itself is Microsoft-documented, confirmed here) so even if a new adapter or update quietly resets the registry value, the next refresh cycle stamps it back. A *local* gpedit.msc change has no such re-sync mechanism; there's genuinely no supported way for Windows to notice the registry drifted and re-apply a local policy on its own. If you're only setting this via local policy on standalone boxes, that's the gap.

So, the actual fix that sticks:

# Run on a schedule (daily is fine) so it catches adapters that didn't exist last time
Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\services\NetBT\Parameters\Interfaces" |
    ForEach-Object { Set-ItemProperty -Path $_.PSPath -Name NetbiosOptions -Value 2 }

For LLMNR specifically, there's an actual Intune CSP ADMX_DnsClient/Turn_Off_Multicast, available from Windows 10 2004+ / Windows 11 21H2+ — so non-domain, MDM-managed devices aren't stuck. NBT-NS has no equivalent CSP as far as I could establish, so on Intune-only fleets it still needs a Win32 app or a scheduled PowerShell script, same as above.

One genuine exception worth flagging, not a drift bug but a deliberate reason NetBIOS sometimes comes back on purpose: Microsoft Defender for Identity's older (v2.x) sensors depend on UDP 137 being open inbound for their own name-resolution mechanism (documented here). If you disable NetBIOS org-wide with v2.x sensors still deployed, expect MDI health alerts about name-resolution failures and don't be surprised if someone on the team quietly re-opens it to make the alert stop. Sensor v3.x drops this dependency, so that's your actual fix if you hit it, not leaving NetBIOS open. Last thing: CIS Benchmarks (Windows 10/11/Server, Level 1) mandate "Turn off multicast name resolution = Enabled" as a compliance control, so if you've got compliance scanning running anyway, that's a second, independent check catching drift regardless of whether GPO refresh did its job.