The DoD Banned Ad-Tracking IDs. Troops Still Got Tracked. Your Endpoint Fleet Has the Same Blind Spot.

The Register reported this week that, despite Department of Defense controls on mobile advertising identifiers, location data for US service members is still turning up for sale in broker marketplaces — and Congress wants to know why.

Strip away the national-security framing and you get a failure mode every IT team knows cold: leadership issued a control, everyone downstream assumed it took effect, and nobody had per-endpoint proof that it actually did.

That is not a Pentagon problem. That is your Tuesday.

Assumed Visibility Is the Default State of Most IT Departments

Ask yourself the questions Congress is asking the DoD, translated into your environment:

• The GPO disabling the Windows advertising ID was pushed in 2022. Which devices never received it?
• The CMDB says 850 endpoints. The last network scan found 940. Which 90 have no agent, no owner, and no patch history?
• Your RMM console shows 812 devices checked in this morning. What happened to the other 38, and did anyone get an alert?

In most shops the honest answer to all three is: nobody knows without a week of exports. Here is the uncomfortable mechanism: most RMM platforms treat a device that stops checking in as an absence of data, not as an incident. Silence does not trigger a page. So a contractor laptop imaged from a stale gold image, a machine where a user ran a cleanup utility that killed the agent service, a repurposed workstation that never got re-enrolled — all of them simply vanish from the console, and the fleet quietly carries a 5–15 percent blind spot.

An endpoint that has been unmanaged for 90 days is not a paperwork problem. It is the endpoint that shows up in a breach disclosure as the device that had not communicated with management tooling in months. It is also the direct IT analogue of the article: a control that exists on paper, is enforced nowhere, and gets discovered in an audit nobody scheduled.

The configuration drift is just as real. The Windows advertising ID setting, location services, telemetry levels — Group Policy says one thing, but devices that spent eight months off-network, machines built before the GPO existed, and BYOD endpoints mean actual state differs from intended state. When the privacy officer asks whether ad tracking is actually disabled on corporate endpoints, the honest answer is usually: the GPO says it should be.

Why the Gap Exists: Four Compounding Failures

None of these are exotic. All of them compound:

1. Policy exists; verification does not. The GPO was written once, in one meeting, and never swept fleet-wide against reality.
2. RMM platforms do not alert on absence. A device that stops reporting generates no event, so the single most important signal — this endpoint is no longer managed — is invisible.
3. Tool silos fragment the truth. Inventory lives in Lansweeper or a spreadsheet, RMM in ConnectWise or NinjaOne, monitoring in PRTG or SolarWinds, helpdesk in Freshservice or ServiceNow, patching in WSUS. Each holds a fragment, and reconciling them is a manual export-and-VLOOKUP exercise nobody does weekly. The question what do we have, and is it compliant? has five answers that disagree.
4. Verification is manual, so it is rare. Hand-sweeping 500 endpoints with ad-hoc scripts and spreadsheets takes a week nobody has, so it happens once a year, under audit pressure.

What It Actually Costs

• Discovery lag. A device goes dark on Monday and is discovered on Friday when the user calls about something unrelated. That is four days of real mean-time-to-detect that no dashboard is measuring.
• Audit season. Three days of exporting last-check-in data, patch states, and configuration settings from four consoles into one spreadsheet that is wrong the moment it is finished.
• The MSP context-switch tax. Answering is this client's fleet healthy? requires five logins and a dozen tabs. Every switch is a minute lost and a correlation missed — usually the ticket that should never have existed.
• SLA fiction. Helpdesk timestamps start when the user calls, not when the problem started, so MTTR numbers understate reality. The IT manager defending that SLA report to leadership is defending a number no one can trace end to end.

How AlertMonitor Closes the Gap

AlertMonitor was built on a different premise: infrastructure monitoring, RMM, helpdesk, patch management, and network topology share one agent, one inventory, and one timeline. A device is not an ID duplicated across four tools — it is a single object with live state, ticket history, patch status, and script results attached.

That architecture changes four things immediately:

• Heartbeats are monitored like services. If a Windows endpoint or server stops checking in, that is an alert with a priority — not silence. The DoD-style blind spot surfaces in minutes, not at next year's audit.
• Fleet-wide scripting lives in the same console as monitoring. Select a device group, run the audit script, and results land in the same timeline as alerts and tickets. A compliance sweep across 500 endpoints is a 10-minute run, not a week of exports.
• Remote sessions open from the device record. Find a machine with the advertising ID enabled or a dead agent service, open a remote session from the same screen, push the fix, and the remediation is logged on that device's timeline next to the alert that triggered it. No tab-switching between a monitoring console and a separate RMM.
• For MSPs, device groups are per-client. A scheduled compliance sweep across all 40 clients is one policy, not 40 manual sessions.

The old workflow: monitoring tool flags an issue → open the RMM → the device is not there → hunt through Active Directory → search the helpdesk for history → fix it → update the ticket → (maybe, someday) update the inventory. The AlertMonitor workflow: heartbeat or config alert fires on the object that already carries the ticket history → remote session or script push → remediation logged → the inventory is accurate by construction, because there is only one.

Practical Steps You Can Run This Week

1. Find your silent endpoints. In AlertMonitor, go to Devices and filter by Last Check-in greater than 24 hours. Then make it permanent: create an alert policy that fires on any workstation with no check-in for 24 hours and any server with no check-in for 1 hour. This single policy converts an assumed inventory into a live one.

2. Sweep advertising ID and location posture across every Windows endpoint. Push this script from AlertMonitor across your Windows device groups. Results come back per-device into the same timeline, and the export doubles as audit evidence:

# Fleet audit: advertising ID + location tracking posture (run via RMM across Windows endpoints)
$result = [ordered]@{
    Hostname         = $env:COMPUTERNAME
    AdvertisingID    = 'ENABLED or unmanaged'
    LocationServices = 'NOT policy-disabled'
}

$adId = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\AdvertisingInfo' -Name 'DisabledByGroupPolicy' -ErrorAction SilentlyContinue
if ($adId -and $adId.DisabledByGroupPolicy -eq 1) { $result.AdvertisingID = 'Disabled by policy' }

$loc = Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\LocationAndSensors' -ErrorAction SilentlyContinue
if ($loc -and $loc.Disabled -eq 1) { $result.LocationServices = 'Disabled by policy' }

[PSCustomObject]$result | Format-List

# Exit non-zero so the RMM run is flagged when out of compliance
if ($result.AdvertisingID -ne 'Disabled by policy') { exit 1 }

3. Enforce, don't just report. For the devices that fail the audit, push the fix — no desk visit, no phone call walking a user through privacy settings:

# Enforce: turn off the Windows advertising ID via policy key, fleet-wide
New-Item -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\AdvertisingInfo' -Force | Out-Null
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\AdvertisingInfo' -Name 'DisabledByGroupPolicy' -Value 1 -Type DWord

# Verify it took
(Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\AdvertisingInfo' -Name 'DisabledByGroupPolicy').DisabledByGroupPolicy
Write-Output "Policy applied and verified on $env:COMPUTERNAME"

4. Make every script fail loudly when the agent is unhealthy. A script result from a machine whose management agent is degraded is not trustworthy. Put a guard clause at the top of your runbooks:

# Guard: fail loudly if the management agent is not healthy
$svc = Get-Service -Name 'AlertMonitorAgent' -ErrorAction SilentlyContinue
if (-not $svc -or $svc.Status -ne 'Running') {
    Write-Output 'AGENT MISSING OR STOPPED - treat this endpoint as unmanaged'
    exit 1
}
Write-Output "Agent OK on $env:COMPUTERNAME ($($svc.Status))"

5. Schedule the sweep monthly. In AlertMonitor, attach the audit script to a monthly schedule across all Windows device groups. Every run appends to the same timeline your team already works from, so when the privacy officer or an auditor asks for proof, the answer is a filter, not a project.

The Question to Ask Your Own Fleet

Congress is asking the Department of Defense to prove a control, endpoint by endpoint. Ask your fleet the same question this week: show me every endpoint, its last check-in, and its actual configuration state — not what policy says it should be.

If producing that answer takes a spreadsheet, four consoles, and three days, the blind spot is real, and it is growing quietly. Close it with one agent, one timeline, and alerts that fire on silence.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources