Problem/Fix with BES Support 765: Reserve Port for BES Client for DNS Servers (Windows 2008/2008 R2, Windows 2012/2012 R2, Windows 2016)

This Task prevents another application from being dynamically assigned the BES UDP notification port (by default 52311).

In earlier versions of windows, the Task worked by adding a ReservedPorts entry for the BES port. In this Win2008+ version of the Fixlet, it works by moving the entire ephemeral port range to start at one port above the BES Client port (so by default, changing the range from 49152 - 65535 to a range of 52312 - 65535).

I have other configurations that enforce the standard part range 49152 - 65535 which conflicts with this setting so I wanted to propose a better way in case this helps anybody.

The Microsoft-documented way to add a port exclusion is via the netsh command -

netsh.exe int ipv4 add excludedportrange udp 52311 1
would add an excluded range starting at 52311 for a range of 1 port.

…but this usually doesn’t work. This netsh.exe command will fail with message “The process cannot access the file because it is being used by another process” if there is any application using the port (including DNS or besclient). You can work around that by stopping the DNS and BESClient services (and any other process that has been randomly assigned the port). That didn’t fit what I was trying to do (i.e. I don’t want to take down DNS), so I have dug into the undocumented internals and hope this helps somebody.

These exclusions are stored at
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nsi\{{eb004a03-9b1a-11d4-9123-0050047759bc}\29
for TCPv4 exclusions and at

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nsi\{{eb004a02-9b1a-11d4-9123-0050047759bc}\5
for UDPv4 exclusions.

The keys will have a value with a name correlating to the start port and range of ports, and a REG_BINARY value 1200ffff to signify the range is excluded.
The value name’s first two bytes correspond to the start port in hexadecimal - port 52311 corresponds to cc57. The next two bytes of the value name correspond to the number of ports, and are byte-swapped to boot - so a range of 1 corresponds to 0100; a range of 255 ports would have been ff00, a range of 256 ports would have been 0001, and so on.

To check in Relevance, (assuming default port number) we can say
not exists values whose (name of it as lowercase = "cc570100" and it as string = "1200ffff") of keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nsi\{eb004a02-9b1a-11d4-9123-0050047759bc}\5" of registry

If we are not going to assume the default port, we can read the port number from the BES Client GlobalOptions, pad it to 4 hex digits, and check for that value name:
not exists values whose (name of it as lowercase = (last 4 of ("0000" & value "ListenPort" of key "HKLM\Software\BigFix\EnterpriseClient\GlobalOptions" of registry as integer as hexadecimal as string ) & "0100") and it as string = "1200ffff") of keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nsi\{eb004a02-9b1a-11d4-9123-0050047759bc}\5" of registry

We can use a regedit command or reg import to create this value making sure to escape { with {{ in the GUID name), which will be effective on the next reboot.

1 Like

@JasonWalker is this command something that works on all the mentioned platforms?

If you found the exclusions that would help as I was unable to locate them when I wrote the fixlet which is why it ended up the way it did. I’d like for it to become non relevant for sure. This would be a great improvement if we can just put in the excluded range as we do need to exclude more if you are talking about WebUI included.

My expectation is that it works on each platform, but I’ve only tried on Win2008 R2 and on Windows 10.

The easiest way to validate on each would be to use the netsh commands and observe the results are as expected.

A potential complication is that I don’t know the behavior of defining two overlapping port ranges for exclusion.