Describe the bug
When a VMSS has upgrade policy set to Manual, az vmss extension set (without --no-wait) updates the VMSS model and then polls instance provisioning state waiting for completion. Since instances are not automatically upgraded in Manual mode, the command blocks and eventually surfaces the provisioning error from the previous extension execution.
This makes it impossible to determine whether the current extension set call succeeded or failed because the previous error keeps returning on every az vmss extension set call.
Steps to Reproduce
- Create a VMSS with upgrade policy Manual
- Run az vmss extension set with a CSE configuration that will fail
- Run upgrade on VMSS instances
- observe failure
- Fix the configuration and run az vmss extension set again with a valid configuration
- Observe that the command returns the error from step 4, not the result of step 5
Workaround:
Pass --no-wait to decouple the model update from instance provisioning, then separately call az vmss update-instances.
Related command
az vmss extension set
Errors
NA
Issue script & Debug output
NA
Expected behavior
Have az vmss extension set be aware of manual update and not poll and not throw the error from before even without --no-wait
Environment Summary
azure-cli 2.85.0
core 2.85.0
telemetry 1.1.0
Extensions:
application-insights 1.2.3
azure-devops 1.0.2
costmanagement 1.0.0
log-analytics 1.0.0b1
quota 1.0.0
redisenterprise 1.4.0
Dependencies:
msal 1.35.1
azure-mgmt-resource 24.0.0
Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe'
Config directory 'C:\Users\DaniilM.azure'
Extensions directory 'C:\Users\DaniilM.azure\cliextensions'
Python (Windows) 3.13.11 (tags/v3.13.11:6278944, Dec 5 2025, 16:26:58) [MSC v.1944 64 bit (AMD64)]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context
No response
Describe the bug
When a VMSS has upgrade policy set to Manual,
az vmss extensionset (without --no-wait) updates the VMSS model and then polls instance provisioning state waiting for completion. Since instances are not automatically upgraded in Manual mode, the command blocks and eventually surfaces the provisioning error from the previous extension execution.This makes it impossible to determine whether the current extension set call succeeded or failed because the previous error keeps returning on every az vmss extension set call.
Steps to Reproduce
Workaround:
Pass
--no-waitto decouple the model update from instance provisioning, then separately call az vmss update-instances.Related command
az vmss extension set
Errors
NA
Issue script & Debug output
NA
Expected behavior
Have az vmss extension set be aware of manual update and not poll and not throw the error from before even without --no-wait
Environment Summary
azure-cli 2.85.0
core 2.85.0
telemetry 1.1.0
Extensions:
application-insights 1.2.3
azure-devops 1.0.2
costmanagement 1.0.0
log-analytics 1.0.0b1
quota 1.0.0
redisenterprise 1.4.0
Dependencies:
msal 1.35.1
azure-mgmt-resource 24.0.0
Python location 'C:\Program Files\Microsoft SDKs\Azure\CLI2\python.exe'
Config directory 'C:\Users\DaniilM.azure'
Extensions directory 'C:\Users\DaniilM.azure\cliextensions'
Python (Windows) 3.13.11 (tags/v3.13.11:6278944, Dec 5 2025, 16:26:58) [MSC v.1944 64 bit (AMD64)]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context
No response