InternalOperationError while scaling VMSS

Question

InternalOperationError while scaling VMSS

Mark Carrington 0 MVP

I am currently unable to scale one of my scale sets in or out - all scaling attempts fail with an InternalOperationError whether performed in the portal, CLI or via the API.

Other scale sets appear unaffected. I can also make other changes to the VMSS configuration such as changing the mix of VM SKUs, and the running instances are working as expected.

Saraswathi Devadula 16,035 Reputation points Microsoft External Staff Moderator

2026-07-09T09:45:21.65+00:00
Hello **Mark Carrington

**An InternalOperationError on VM Scale Set (VMSS) scaling typically points to something failing inside Azure or related resources during the update. Since other scale sets work and your VMSS is otherwise configurable (like changing VM SKUs), the most common things to check are locks, unhealthy/partial instance states, transient platform issues, and capacity constraints.

I request you to retry the same scaling action from the portal first, then (if using CLI) retry the operation.

Also, try to verify if any resource locks are existing. Locks can block VMSS operations even when other changes succeed.

In the Azure portal, go to your VM Scale Set.

Check Settings > Locks for:

the VMSS resource itself.

associated resources like disks and network interfaces.

Look specifically for Read-only or Delete locks.

Remove any such locks, then retry scaling.

-- If some instances are stuck in problematic states, the scale operation can conflict and fail.

Go to the VMSS Instances tab. Look for instances in states such as: Failed, Stopped or improperly deallocated states.

If you find instances that aren’t fully deallocated/healthy, deallocate them and then retry scaling.

az vmss deallocate --resource-group <resource-group-name> --name <vm-scale-set-name>

-- If the scale set is in a bad operational/config state (without it being obvious), redeploying can reinitialize the deployment path.

Portal:

VMSS page → Support + troubleshooting → Redeploy + Reapply → Redeploy

az vmss update-instances --resource-group <resource-group-name> --name <vm-scale-set-name> --instance-ids '*'

If there’s an ongoing incident impacting compute, scaling may fail while other operations appear normal.

Check Azure Service Health for compute-related issues in your region.

If there’s an incident, it’s usually best to retry after it’s resolved.

-- Even if your VMSS is otherwise healthy, scaling up/down might hit capacity constraints depending on region/zone/fault domains and VM size.

If the error details you’re seeing mention capacity, try scaling down to a lower capacity target first, then scale up gradually.

az vmss scale --resource-group <resource-group-name> --name <vm-scale-set-name> --new-capacity <desired-capacity>

(And if you use Availability Zones, ensure your fault domain/platformFaultDomainCount setup is appropriate.)
Saraswathi Devadula 16,035 Reputation points Microsoft External Staff Moderator

2026-07-10T11:00:07.2966667+00:00

Hello Mark Carrington
I hope you had the opportunity to review the information shared earlier, and I hope this information was helpful! If you still have questions, please let us know what is needed in the comments so that the question can be answered.
Mark Carrington 0 Reputation points MVP

2026-07-10T12:10:30.9233333+00:00

Thanks for the update. I did originally try the scaling operation through the portal, CLI and API and all gave the same result.

There are no locks on the VMSS.

The list of instances shows 5, but the portal shows "Status: 5 out of 6 succeeded". There's no obvious way to view the 6th instance to get more information on the state of that extra instance.

The "Redploy" option you mentioned wasn't visible, but I did successfully run the az vmss update-instances command. This didn't have any immediate effect, but 30 minutes later my scaling commands started to work again. Unsure if this command triggered something to resolve the problem or whether there was some other background issue which cleared in time, but I am now able to scale the VMSS again as normal.

2 answers

Your answer

Saraswathi Devadula 16,035 Reputation points Microsoft External Staff Moderator

2026-07-10T11:00:07.2966667+00:00

Hello Mark Carrington
I hope you had the opportunity to review the information shared earlier, and I hope this information was helpful! If you still have questions, please let us know what is needed in the comments so that the question can be answered.
Mark Carrington 0 Reputation points MVP

2026-07-10T12:10:30.9233333+00:00

Thanks for the update. I did originally try the scaling operation through the portal, CLI and API and all gave the same result.

There are no locks on the VMSS.

The list of instances shows 5, but the portal shows "Status: 5 out of 6 succeeded". There's no obvious way to view the 6th instance to get more information on the state of that extra instance.

The "Redploy" option you mentioned wasn't visible, but I did successfully run the az vmss update-instances command. This didn't have any immediate effect, but 30 minutes later my scaling commands started to work again. Unsure if this command triggered something to resolve the problem or whether there was some other background issue which cleared in time, but I am now able to scale the VMSS again as normal.

Answer 1

hey hey Mark Carrington & thx for jin me here at Q&A portal,

I assume this looks platform-side. The same scale operation fails through the portal, CLI, and API, while other VMSS changes still work and other scale sets are fine. That points to a stuck or inconsistent backend state on this specific scale set, not a client-side issue. Check the Activity Log and the failed VMSS operation details for a correlation ID and any inner error. InternalOperationError by itself is too generic to fix from the customer side.

I’d avoid repeated scale attempts for now and open an Azure support case with the VMSS resource ID, region, timestamps, correlation IDs, orchestration mode, and whether the failure happens for both manual capacity changes and autoscale.

If the scale set uses Flexible orchestration, mixed VM SKUs, Spot instances, or capacity reservations, mention that too. But the real root cause still needs Microsoft Compute backend logs.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more