Default outbound is blocked, cannot prepare AVD Machine in HOSTPOOL without NATGW.

Starting March 31, default outbound is blocked

After March 31, 2026, new virtual networks will default to using private subnets, meaning that an explicit outbound method must be enabled in order to reach public endpoints on the internet and within Microsoft. For more information, see the official announcement. We recommend that you use one of the explicit forms of connectivity discussed in the following section. For other questions, see the "FAQs: Default Behavior Change to Private Subnets" section.

Therefore, when the subnet as no NATGW, its now impossible to prepare AVD HOSTS because:
https://wvdportalstorageblob.blob.core.windows.net/galleryartifacts/Configuration_1.0.03355.1216.zip is not reachable.

This DSC Blob PATH would only be reachable IF it was a local storage **in the same region.** but since its not it will always fail.

Do you have an alternate approach? I haven’t seen anything documented on the Microsoft side, but this appears to introduce a new requirement.

Since **wvdportalstorageblob.blob.core.windows.net** is a Microsoft-managed storage account, we don’t control the target-side network rules or private endpoint integration. In practice, the session host still needs an explicit outbound path to reach that required AVD endpoint.

##
Virtual machines are still able to access Azure Storage accounts in the same region in a private subnet without an explicit method of outbound. NSGs are recommended to control egress connectivity.
##

{
"status": "Failed",
"error": {
"code": "VMExtensionProvisioningError",
"message": "VM has reported a failure when processing extension 'Microsoft.PowerShell.DSC' (publisher 'Microsoft.Powershell' and type 'DSC'). Error message: 'The DSC Extension failed to execute: Error downloading https://wvdportalstorageblob.blob.core.windows.net/galleryartifacts/Configuration_1.0.03355.1216.zip after 17 attempts: Unable to connect to the remote server.\r\nMore information about the failure can be found in the logs located under 'C:\\WindowsAzure\\Logs\\Plugins\\Microsoft.Powershell.DSC\\2.83.5' on the VM.'. More information on troubleshooting is available at https://aka.ms/VMExtensionDSCWindowsTroubleshoot"
}
}

Start by reviewing the repository's ARM templates and the Azure DSC extension failure, including the VM logs under C:\WindowsAzure\Logs\Plugins\Microsoft.Powershell.DSC\2.83.5 and the unreachable blob URL. The issue does not name a target file, test, or acceptance criteria; a maintainer decision is needed to define whether the outcome is a template change or documentation of an outbound-connectivity requirement.

Written by the indexing model from the issue text.