Open davidcreel opened 4 months ago
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @vnetsuppgithub.
Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @vnetsuppgithub.
Updated bug report with more detailed logs. Note: This bug is still present even after upgrading to a recent version of Az.Network.
Description
We have started receiving the following error when using the
Set-AzVirtualNetwork
cmdlet:It is not allowed to modify Sharing Scope property on non-empty subnet.
This happens when using Az Powershell to get, modify, then set the vnet. Even though no changes are made to this property.It appears that older versions of Az.Network do not have the ability to de(serialize) the SharingScope property to/from the API response. And for PUT requests to the VNet backend is interpreting this missing value as an attempt to change the property.
This appears to be a new property with limited rollout so far. We only see it present on VNets in certain regions (North Central US). Even on a very recent version of Az.Network PowerShell module (7.6.0), we still see this error.
Unless something else is going on here, I think any further rollout of this sharing scope property may have the potential to break the
Set-AzVirtualNetwork
cmdlet in a widespread fashion.Issue script & Debug output
Sequence of cmdlets used:
Full output
Environment data
Note: I am running in constrained language mode if that makes a difference
Module versions
Error output