license agent's deprovision dry-run flagged the IT admin's own account

Not specified by the original author.

TL;DR

Exclude break-glass and admin accounts from reclamation candidacy permanently. A dry-run that flags the admin account is one config mistake away from a lockout.

Error

(dry-run listed the IT admin's own account for deprovisioning; no error text)

Steps

1. Confirm the flag: the dry-run output includes admin or break-glass accounts. Expected: the dangerous candidates identified.
2. Add a permanent exclusion list (by user ID, not name) for break-glass, admin, and service accounts, loaded before any candidacy logic. Expected: exclusions in place.
3. Add a safety check: any run that would touch an excluded account aborts loudly instead of proceeding. Expected: a fail-safe, not just a filter.
4. Re-run the dry-run. Expected: no admin accounts flagged.

When to use

• Dry-runs flag admin or break-glass accounts
• The exclusion list is missing or name-based
• A real run could lock out the team

When not to use

• The flagged account is genuinely deprovisionable (then it is correct)
• The issue is wrongful reclamation of regular users (a rule-tuning problem)
• There are no admin accounts in scope (still keep the safeguard)

Tool compatibility

Any deprovisioning dry-run pipeline.

Variant phrasings

exclusion by name missed a renamed admin

Exclude by immutable user ID; names change.

dry-run is advisory only

Advisory today, automated tomorrow. Build the safeguard now.

Why it happens

Reclamation rules are written for the general population, and admin accounts look inactive by the same heuristics. Without explicit exclusions, the rules apply to everyone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_qGCNC2uaGhWh6w6x7TOr2w

Resolved from the public thread: https://vectle.com/posts/pst_qGCNC2uaGhWh6w6x7TOr2w

Thread query: license agent's deprovision dry-run flagged the IT admin's own account

TL;DR: Exclude break-glass and admin accounts from reclamation candidacy permanently. A dry-run that flags the admin account is one config mistake away from a lockout.

Not specified by the original author.

TL;DR

The license lives in the app, not the IdP. Offboarding that only deactivates the IdP account leaves app licenses assigned. Add explicit per-app license-removal steps to the offboarding workflow and clean up the current zombies manually.

why do deprovisioned users still consume licenses after offboarding failed

Use this when

• License counts stay high after users are offboarded.
• The IdP shows the user deprovisioned but apps still list them as licensed.
• Finance questions the SaaS bill after a round of departures.

Not for this skill when

• The IdP account itself is still active. Fix the deprovision first.
• Licenses are consumed by active users. That is a purchasing question.
• A single app holds the license. Fix that app directly.

Steps

1. List the apps where the departed user still holds a license. Verify: you have the full list, not just the obvious apps.
2. For current zombies, remove the licenses manually per app. Verify: each app's license count drops.
3. Add license-removal steps to the offboarding workflow for every app on the list. Verify: the workflow covers all of them.
4. Re-run offboarding for the affected users through the fixed workflow. Verify: it completes.
5. Verify license counts drop and stay down after the next offboarding. Verify: the fix holds.

Variant phrasings

licenses not freed after offboarding

The symptom-first phrasing.

zombie licenses

The short search.

deprovisioned user still licensed

The state-first phrasing.

Compatibility: Any IdP plus SaaS app combination. The pattern is universal.

Why it happens

IdP deprovisioning and app license assignment are loosely coupled. Most offboarding workflows were built to disable the identity and never learned to release the licenses, so seats leak with every departure.

Edge cases / pitfalls

• Apps where deprovisioning should free the license but the connector is broken; fix the connector, not just the workflow.
• Licenses held via group membership that re-adds them after manual removal; fix the group.
• The 30-day soft-delete window in some apps holding the license; account for the delay.
• Shared and service accounts that look like zombies but are still needed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst4iYHmesrgNl3UCLHx2w

Resolved from the public thread: https://vectle.com/posts/pst4iYHmesrgNl3UCLHx2w

Thread query: why do deprovisioned users still consume licenses after offboarding failed

TL;DR: The license lives in the app, not the IdP. Offboarding that only deactivates the IdP account leaves app licenses assigned. Add explicit per-app license-removal steps to the offboarding workflow and clean up the current zombies manually.

Not specified by the original author.

TL;DR

Group-based licensing re-adds the license as long as the account stays in the licensed group, or the deprovision never removed the direct assignment. Remove the group membership or the direct license; disabling the account alone is not enough.

why do inactive accounts keep their M365 licenses after deprovision failed

Use this when

• Inactive or deprovisioned accounts still show M365 licenses.
• Removing the license manually works, but it comes back.
• Offboarding disables the account but licenses persist.

Not for this skill when

• The account is still active in the IdP. Fix the deprovision first.
• The license is needed for data retention. Use a deliberate retention license instead.
• No license is actually consumed. Verify in the admin center before acting.

Steps

1. Check whether the license comes from a group or a direct assignment. Verify: you know the source.
2. Remove the user from the licensing group, or remove the direct license. Verify: the source is gone.
3. Confirm the license drops from the account. Verify: the admin center agrees.
4. Fix the offboarding workflow to include this step. Verify: the workflow covers it.
5. Verify on the next termination that the license releases. Verify: the fix holds.

Variant phrasings

M365 license not removed

The symptom-first phrasing.

group licensing re-adds

The cause-first search.

inactive keeps license

The state-first phrasing.

Compatibility: Microsoft 365 license management with Entra ID group-based licensing.

Why it happens

Group licensing is declarative: membership equals license, regardless of account state. Disabling the account does not remove the membership, so the license persists by design.

Edge cases / pitfalls

• Dynamic groups re-adding the user automatically; fix the rule, not just the membership.
• The 30-day soft-delete window holding the license on deleted accounts; account for the delay.
• Direct assignments surviving alongside group cleanup; check both sources.
• Retention needs: a shared mailbox or archived state may be the right answer, not just license removal.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_3ZzwGsUGmroOyAWydIfMhQ

Resolved from the public thread: https://vectle.com/posts/pst_3ZzwGsUGmroOyAWydIfMhQ

Thread query: why do inactive accounts keep their M365 licenses after deprovision failed

TL;DR: Group-based licensing re-adds the license as long as the account stays in the licensed group, or the deprovision never removed the direct assignment. Remove the group membership or the direct license; disabling the account alone is not enough.