InternalServerError (500) on all NIC ipConfiguration modifications after a cross-subscription move — CREATE and DELETE work, MODIFY does not

After a cross-subscription resource move of a VM and its network resources (both subscriptions in the same

Entra tenant, same region, Canada Central), every operation that MODIFIES an existing network interface's

ipConfiguration returns HTTP 500:

Code: InternalServerError

Message: An error occurred.

details: []

What still works:

• GET on everything
• a no-op PUT of the NIC object, fetched and written back unchanged
• tag writes on the VM, VNet, NSG and public IP
• CREATE a new NIC with a public IP and a static private IP set at creation time (done 3 times)
• DELETE a NIC
• VM writes, including attaching and detaching NICs

What fails, always with the same empty-details 500:

• attaching a public IP to an EXISTING NIC
• changing an EXISTING NIC's private IP

So the pattern is CREATE ok, DELETE ok, MODIFY 500.

Reproduced in three independent clients: the Azure Portal, Az PowerShell (Set-AzNetworkInterface, which

round-trips the whole object) and Azure CLI (az network nic ip-config update, which sends a minimal payload).

Because the CLI builds a completely different and much smaller request and fails identically, I do not think

this is a malformed client payload.

The two most useful details:

1. It ALSO fails on a NIC I created fresh in the target subscription after the move, which was never itself moved - but that NIC was created inside the MOVED virtual network.
2. I then created a completely separate, brand-new virtual network in the SAME subscription, put a new NIC in it, and modified that NIC's private IP. That SUCCEEDED. So the subscription is fine, and the fault is scoped to the virtual network that was moved. Any NIC inside the moved VNet fails; any NIC outside it works.

That points at the moved VNet's subnet / IP-allocation state rather than at any individual NIC.

Also worth noting: an earlier no-op PUT on the original NIC failed with the same 500, then later began

succeeding on its own with no action from me, while MODIFY kept failing throughout.

Already ruled out, with the method:

• permissions - tried under an interactive user and a Cloud Shell managed identity; an authorization failure would be 403, not 500
• resource locks - none on the resource group
• Azure Policy - assignments exist, but policy denials return 403 RequestDisallowedByPolicy, and the Portal attempt's Activity Log claims show MFA was satisfied
• availability-zone mismatch - neither the public IP nor the VM is zonal
• public IP already associated - its ipConfiguration is empty
• public IP SKU - it is Standard, and a brand-new Standard IP failed too
• invalid values - CREATE with those exact same values succeeds
• subnet exhaustion - a /24 with only a few addresses used
• transient - persisted for hours across many attempts

Context that may matter: the move itself returned "ResourceMoveFailed / NotificationAfterMoveFailed" for

Microsoft.Storage against the virtual network, while ALSO reporting "All move in provider succeeded".

Placement did complete correctly - every resource is in the target subscription and readable. My working

theory is that the failed post-move notification left the Network resource provider's state for this VNet

unreconciled, but I cannot see provider-side state to confirm that.

Workaround in use: build a new NIC with its final configuration set at CREATE time and swap it onto the VM.

That preserved the public IP, but I could not restore the original private IP, because assigning it to an

existing NIC requires a MODIFY.

Questions:

1. Is a moved VNet's subnet / IP-allocation state repairable in place, or is recreating the VNet the only option? Recreating it means re-homing every NIC in it, so I would rather not if there is a supported fix.
2. Is this a known consequence of NotificationAfterMoveFailed on a virtual network?
3. Does it affect other subnet-adjacent writes, for example creating VNet flow logs on this VNet?
4. How do I avoid it on future cross-subscription VM moves? I have more production VMs to move, their private IPs are referenced by backup tooling, and setting a private IP on an existing NIC requires a MODIFY - so if the moved VNet is always left in this state, I need a different approach entirely.

Any pointers here are appreciated! Thank you!