Can someone please explain how agent re-enroll is supposed to work ?

[dispo2]

I have been trying to add two opnsense vm's into my pulse setup and am having issues (seperate discussion).

To try and diagnose the above I uninstalled the agents and removed the infrastructure entries which resulted in the following entry in Agent Doctor

This agent is intentionally removed and blocked from re-enrolling until an admin allows it.
Removed at 2026-07-31T09:42:13Z
Identity evidence
Allow re-enroll
Uses the existing allow re-enroll action for removed agents.
Required scope: settings:write

I have tried to re-add the agent via the add infrastructure page / created install config text etc and the install works producing the following

[INFO] Verifying agent started successfully...
[WARN] Agent local health is ready, but server registration was not confirmed yet.
[INFO] Installation complete! Agent is running.
[INFO] To uninstall later: sudo bash /var/lib/pulse-agent/install.sh --uninstall
[INFO] To check status: /usr/local/etc/rc.d/pulse-agent status
[INFO] To view logs: tail -f /var/log/messages

However the device is never added to pulse and the 'Check installation status' option fails.

Where is the Allow re-enroll function or how do I delete the Agent Doctor 'removed' history ?

This is pulse 6.1.2

[dispo2]

I have fixed this. I traced the initial issue to duplicated machine-id's.

My attempts to resolve wierd pulse behaviour via uninstalling / deleting / re-enrolling did not work but I had not fixed the machine-id problem at that point.
I tried various methods to change the machine-id on opnsense and all failed after a reboot (went back to original value) so I just re-created the vm's and imported the config. [obviously not a pulse problem]
This ulimately led to two new machine-id's that bypassed any ban history, allowed agent installation and work perfectly.

tl;dr

Having found this post I now know

... in v6.0.0 (removal blocks are now scoped by machine ID and token, and the fix commit references this discussion), with further hardening in v6.1.1 — a fresh token now always clears the block, and blocks expire after 24 hours instead of persisting forever.

The clean way out on current versions: first check what the two records actually are via the agent diagnostics (Settings shows last-seen and token per record). If the stale and live records have different tokens — which they should, since you created separate tokens per host — deleting the stale one won't touch the live one on v6.0.0+. If they still share a token, generate a fresh install command for the live machine first so it reports on its own token, then delete the stale record.

If a live host is already stuck in the banned state, either re-run the installer with a newly generated token (a token created after the removal always re-enrolls), or wait out the 24-hour expiry on 6.1.x. To stop duplicates from coming back on reinstalls, you can pin a stable identity with --agent-id / PULSE_AGENT_ID, per the "Duplicate Agents" section in docs/UNIFIED_AGENT.md.

My initial issue was that the two opnsense vm's had the same machine id.
This led to wierd behaviour in pulse when adding the second machine - the first seemed to vanish but looking at the agent diagnostics it would flicker between the two machines. Whilst trying to diagnose out the issue I unstalled / deleted both machines but then couldn't add them back in.
As I was attempting to fix this / re-enroll before I realised the machine-id issue there is no telling what was going on but adding either machine back in , even with new tokens, did not work. I dont think this is worth diagnosing any further as the whole situation was just a mess.

The one takeaway I have is I think the re-enroll text should be updated to match the above. I couldn't find any 'Active Task' or option that would allow re-enroll so basically stalled.

[behez0n]

I ran into a related but somewhat different identity-continuity case on Pulse 6.2.1 while migrating a Proxmox host.

In my case, the live agent remained online and /api/connections reported its credential as verified, while Agent Doctor reported agent_credential_missing.

Running the Doctor-generated Repair Authentication workflow then resulted in additional suffixed agent identities for the same physical host rather than converging on the existing identity.

I was able to recover the installation and documented the reproduction, continuity-state findings, and final recovery here:

#1748

Posting the reference here because some of the machine identity / credential continuity behavior overlaps with this discussion, even though the exact failure mode appears to be different.