Allow for a restart when using VM Reapply during extension recovery

Source facts

Microsoft documents VM Reapply as a way to send a new GoalState to a VM. It usually does not reboot the guest, but it can trigger a pending update that requires a restart. The extension troubleshooting guidance therefore recommends a time when brief downtime is tolerable. The same guidance requires the VM Agent to be running and reporting Ready for extensions to work correctly. Microsoft Learn.

Applicability

Use this review when an extension-recovery plan includes Reapply. Establish the actual agent and extension state first; the existence of an extension failure alone does not identify a cause or prove that Reapply will solve it.

DSE recommendation

Schedule VM Reapply when the workload can tolerate the documented interruption risk. Have the application owner agree on the access or service checks needed afterward, and preserve the current error evidence before taking the action. Keep the chosen operation explicit in the change record rather than using an imprecise instruction to refresh the VM.

Verification

Observe the VM, agent readiness, extension status, and representative workload behavior after the authorized operation. Record whether a restart occurred and whether the original failure changed. Compare the new evidence with the pre-change record before deciding on another recovery step. If the extension remains unhealthy, return to its specific diagnostic guidance instead of repeating Reapply without a new explanation. Do not report a successful control-plane request as proof that application service has recovered.

Official references

Microsoft Learn: Troubleshooting Azure Windows VM extension failures. Source reviewed September 9, 2026.