Enterprise-Scale
                                
                                 Enterprise-Scale copied to clipboard
                                
                                    Enterprise-Scale copied to clipboard
                            
                            
                            
                        Creation of VNET exceeds the maximum character limit for the VNET name
When creating a landing zone, if the Resource Group name is too long, when the template creates the name for the VNET attaching the IDs and RG name, it causes an exception and gives the following error:
While selecting this, we could see that the virtual network created as part of this step has the subscription ID tagged in its name and deployment failed with the error: code\\\": \\\"NetcfgInvalidVirtualNetworkSite\\\",\\r\\n    \\\"message\\\": \\\"Virtual network site is not valid as specified with the name 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXNameTooLongToCauseAProblemWithExceedeingLength'
As per Microsoft Documentation, the limit is 64 characters

Crating the VNET manually doesn't happen, but the templates or the logic shouldn't let the name exceed the limit.
Tagging @jtracey93 as requested by him
Thanks @ositobio - assigning this to myself to investigate and resolve 👍
Initial Investigation
VNet names passed in by the eslzArm.json orchestration template (used by portal deployments) can pass in VNet names longer than 64 characters (max supported length) depending on the region and length of the ESLZ Prefix entered.
VNET Naming Patter Today Explained
<SUBID><enterpriseScaleCompanyPrefix>-vnet-
Total possible length of SUBID + enterpriseScaleCompanyPrefix + "-vnet-" = 52 characters
This leaves only 12 characters for the location section.
Locations names that are longer than 12 characters in length
Using the below PowerShell against Azure Public, I have found the following list of regions that are longer than 12 characters in length:
$locations = Get-AzLocation
$locationHashTable = @{}
foreach ($location in $locations) {
  $locationLength = $location.Location.Length
  $locationDisplayName = $location.DisplayName
  $locationShortName = $location.Location
  if ($locationLength -ge 13) {
    Write-Host -ForegroundColor Yellow "$locationDisplayName is longer than 12 characters: $locationShortName is actually $locationLength characters"
  } else {
    Write-Host -ForegroundColor Green "$locationDisplayName is 12 characters or less: $locationShortName is actually $locationLength characters"
  }
  $locationHashTable.Add($location.Location, $location.Location.Length)
}
$locationHashTable.GetEnumerator() | Sort-Object -Property Value -Descending
Locations potentially impacted
Azure Public
| Name | Length | 
|---|---|
| germanywestcentral | 18 | 
| australiasoutheast | 18 | 
| australiacentral2 | 17 | 
| southafricanorth | 16 | 
| australiacentral | 16 | 
| switzerlandnorth | 16 | 
| brazilsoutheast | 15 | 
| switzerlandwest | 15 | 
| southafricawest | 15 | 
| northcentralus | 14 | 
| southcentralus | 14 | 
| francecentral | 13 | 
| southeastasia | 13 | 
| swedencentral | 13 | 
| canadacentral | 13 | 
| australiaeast | 13 | 
| westcentralus | 13 | 
Azure Gov (Fairfax)
| Name | Length | 
|---|---|
| usgovvirginia | 13 | 
Azure China (Mooncake)
No regions currently impacted
Summary
If a customer selects a region that is potentially impacted by this issue as listed in above tables and sets the ESLZ prefix to 10 characters (it's max length) then VNET deployments will fail using the ESLZ portal experience due to the VNet name being longer than 64 characters.
Workarounds (prior to fix being implemented)
- Deploying the VNet/s manually (Portal, ARM, Bicep etc.)
- Use a shorter ESLZ prefix (using the maths in the "VNET Naming Patter Today Explained" section above) to ensure your VNet name will be 64 characters or less
Next Steps
I will investigate the best way to fix this in the short term and longer term and create required PRs shortly
Linking to #674
Trigger ADO Sync 1
Trigger ADO Sync 2