Recover an accidentally deleted endpoint

If an admin accidentally deletes an endpoint from the dashboard while the agent is still installed on the machine, the agent on that endpoint will keep trying to refresh its credentials and the server will respond endpoint_not_found on every attempt. The agent stops checking in until the credentials are reset locally. This page is the recovery procedure.

Use Reset an endpoint instead when you deliberately want to tear an agent down (decommissioning a machine, moving it between tenants, wiping a test box). That flow uninstalls the agent. This page is about getting an already-installed agent talking to the dashboard again under a new endpoint id without removing anything.

The fix in one step

  1. Generate a fresh enrollment token at /app/enrollment. Single-use is fine - the agent only needs to redeem it once.
  2. On the affected machine, re-run the PowerShell installer with -Upgrade and the fresh token:
    powershell -ExecutionPolicy Bypass -File .\Install-PermitUSB.ps1 `
  -Upgrade -TenantToken '<fresh-token>' -LocalMsi
  3. Within ~30 seconds the endpoint reappears on the dashboard with a new endpoint id. History from the old endpoint stays in the deleted row; new events flow under the new id.

The -LocalMsi flag avoids the installer re-downloading the MSI from the dashboard - assumes you already have PermitUSB.msi sitting next to the script (PDQ Deploy / Intune / SCCM packaging usually does this anyway). Drop -LocalMsi if you want the script to pull the latest MSI by token instead.

What that command does under the hood

It looks like a normal in-place upgrade but the combination of -Upgrade with -TenantToken is the explicit signal that you want to re-enroll. The script:

  1. Stops the agent service and the tray (standard upgrade preliminaries).
  2. Deletes credentials.bin. This is what forces the agent to take the first-run enrollment path instead of trying to refresh a token tied to the deleted endpoint id.
  3. Patches agent.json so its EnrollmentToken field carries the fresh token. (After every successful enrollment this field is cleared, so on a re-enroll the agent has nothing else to use.)
  4. Runs msiexec as a major-upgrade. The MSI rewrites the bootstrap registry with the fresh token too, as a belt-and- suspenders fallback for agents that get there via a different code path.
  5. Starts the service. Agent sees no credentials.bin, reads agent.json, calls /agent/enroll with the fresh token, persists new credentials, and starts polling.

If the agent is on 1.0.25.0 or newer

From 1.0.25.0 onward the agent has its own self-recovery path: when a refresh comes back endpoint_not_found, it peeks at the bootstrap registry's current EnrollmentToken; if the value there is one it hasn't already redeemed, it re-enrolls with that token instead of staying stuck. Functionally that means even an installer push that doesn't take the script-side re-enrollment path (e.g. someone runs msiexec directly with TENANT_TOKEN=<fresh>) recovers cleanly.

The script-side re-enrollment in Install-PermitUSB.ps1 -Upgrade -TenantToken still works on older agents (1.0.24 and below) because it doesn't depend on the agent doing anything clever - the script does the credential reset itself.

If the machine is fully unreachable

If you don't have any remote-exec channel (no RDP, no PDQ Deploy / Intune / RMM, no PSRemoting), there's no way to push the recovery from afar - the agent on the affected machine can't reach the dashboard to be told to re-enroll, and the dashboard has no outbound channel to the agent. In that case the only path is physical access to the machine: run the same Install-PermitUSB.ps1 -Upgrade -TenantToken command locally, or fall back to the Reset an endpoint flow and reinstall fresh.

What to do with the deleted row on the dashboard

It stays in the database in a soft-deleted state - we don't surface its history on the endpoints list, but the events it generated before the deletion remain attached to that row in the underlying store. After the agent re-enrolls it appears as a new endpoint with a new id; the old id and the new id refer to the same physical machine but they're independent rows from the dashboard's perspective.