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"
}
}
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"
}
}