RM Programming — Over-Wi-Fi Across Sites/Subnets

Overview
Programming MOTOTRBO R7 radios and repeaters over Wi-Fi with Radio Management (RM), across sites and subnets. RM Server / Device Programmer runs on pbr-radio-kl1 (10.8.40.10), RM version 2.157.149.0.
Out of the box, RM Wi-Fi programming only works when the radio and the Device Programmer are on the same subnet, because discovery uses mDNS multicast (224.0.0.251:5353) which doesn't route. Four changes were needed to make it work across sites — all four are required.
The Four Fixes
1. Disable Windows mDNS on the RM server (registry — most important)
Windows' Dnscache service binds UDP 5353 and silently consumes the radios' incoming discovery announcements — the Motorola Device Programmer never receives them. Radios show Waiting For Device forever with no error.
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" `
  -Name EnableMDNS -Value 0 -PropertyType DWord -Force
# Then REBOOT the server
Verify after reboot — the Motorola DP process (not svchost) must own the port:
Get-NetUDPEndpoint -LocalPort 5353 | Select LocalAddress,OwningProcess
2. Set Device Discovery Server Name in the radio codeplug
CPS → Wi-Fi → per network profile: set Device Discovery Server Name to 
pbr-radio-kl1 (or 10.8.40.10). This makes the radio send its discovery announcement unicast to the server (routable) instead of local multicast. Set it on every Wi-Fi profile the radio uses. DNS-SD port 5353, interval 90 sec.
3. RM Machine Authorization
RM Server Utility → Machine Authorization: the machine running the Device Programmer (including the RM server itself) must be listed with the Programmer permission ticked. Without it, connections fail with the generic "Failed to connect to the RM server" dialog and jobs never dispatch.
4. Use 10.8.40.10, not localhost
In the RM config, Job Processor and Device Monitor/DP settings, set the RM Server address to 
10.8.40.10 — not localhost. With localhost, cross-site writes fail with Error 450 ("connection could not be established with the selected connection type") while local writes still work.
Quick Troubleshooting
Symptom
Check
Waiting For Device forever, cross-site
Fix 1 — who owns UDP 5353? Windows updates/rebuilds can re-enable mDNS
Cross-site radio never discovered at all
Fix 2 — Device Discovery Server Name missing on the active Wi-Fi profile
"Failed to connect to RM server" dialog
Fix 3 — Machine Authorization
Error 450 on cross-site writes only
Fix 4 — localhost addressing
Ports
UDP 5353 (radio → server, discovery) · TCP 443 (RM server/clients) · TCP 8002-8003 (DP → radio, programming session) · TCP 50000-50100 / UDP 20000 (IP Program, repeaters). Traffic currently rides the Palo Alto intrazone-default allow — add explicit rules if radio VLANs move to their own zone.
Notes
If this breaks after a Windows update or server rebuild, check the EnableMDNS registry value first.
If the server IP changes, update it in both the radio codeplugs (Fix 2) and RM component settings (Fix 4).