Keep MSP key-reset counters increasing across recovery automation

Source facts

When an MSP VM loses its long-lived key, it cannot communicate with Instance Metadata Service or WireServer, and Azure cannot safely issue a replacement automatically. Microsoft documents resetting the key through KeyIncarnationId in the VM model. Repeated or automated requests must use strictly increasing values; otherwise the change might not apply. After the reset, the Guest Proxy Agent periodically retries recovery and acquires the replacement key. Microsoft Learn.

Applicability

Use this procedure only after diagnosing a key-acquisition problem through the documented agent status and logs. Keep it distinct from an eBPF, cgroup, or unsupported-image problem, which has a different recovery path in the source.

DSE recommendation

Coordinate key-reset writers and record the existing counter before submitting the next value. Have one recovery owner control the sequence so a retry or parallel automation job does not send a stale value. Preserve the reason for the reset and the approved VM identity without recording the long-lived secret itself. Do not recycle a hard-coded counter in a reusable recovery template.

Verification

Inspect the resulting VM-model value and then observe the agent’s status as it attempts recovery. Confirm the intended metadata-dependent operation works again, using a controlled request that does not expose credentials. Keep the accepted counter and sanitized status evidence with the incident. If the model update succeeds but the agent remains unhealthy, investigate the reported component state before issuing another reset.

Official references

Microsoft Learn: Troubleshoot MSP. Source reviewed September 9, 2026.