The portal-generated VpnGw1 → VpnGw1AZ upgrade repeatedly fails Microsoft Network preflight validation.

Thank you. That confirms the direction I was considering.

I will schedule a maintenance window when all remote users are disconnected, temporarily remove the Point-to-Site/Remote RADIUS configuration, and then retry the VpnGw1 to VpnGw1AZ migration.

Once the migration is successfully completed, I will restore the existing P2S configuration using the same client address pool, IKEv2/OpenVPN protocols, RADIUS server, and shared secret, and then test with a remote user before allowing everyone to reconnect.

I will leave the NPS/RADIUS server itself running and will not make changes to the existing Site-to-Site connection unless necessary.

If there are any additional precautions you recommend before I proceed, please let me know. Otherwise, thank you for confirming the supported remediation path.

Thank you. I was able to retrieve the inner validation error using Azure CLI.

The specific error is:

VpnClientConfigurationRadiusServerSecretIsNotSpecified

The gateway has a Point-to-Site configuration using RADIUS authentication:

• RADIUS server: 10.0.0.5
• P2S client pool: 172.16.13.0/24
• Protocols: IKEv2 and OpenVPN
• BGP: Disabled

We also queried the gateway using the listRadiusSecrets API and confirmed that Azure does have an existing RADIUS shared secret stored for 10.0.0.5. The normal gateway GET does not return the secret, but listRadiusSecrets does.

Therefore, it appears the VpnGw1 → VpnGw1AZ migration workflow is failing to carry the existing encrypted RADIUS secret into the preflight validation request.

Would the supported remediation be to temporarily remove the Point-to-Site/RADIUS configuration, perform the VpnGw1 → VpnGw1AZ migration, and then recreate the P2S configuration with the same RADIUS server and shared secret after migration?

The Site-to-Site IPsec connection is currently healthy, and we can schedule a maintenance window with all P2S users disconnected.

Tracking ID: b6c6ad21-ec14-42ed-8987-e420c0f8e516

Welcome to Microsoft Q&A!

@Matt Carson I hope you are doing well,

VpnGw1 → VpnGw1AZ migration preflight validation failure is not caused by obvious prerequisites (GatewaySubnet size /24 and Standard Public IP are already satisfied). The key here is the inner validation error tied to your tracking ID.

• The portal migration workflow uses the documented API version 2025-07-01. That version is supported, but the backend validation pipeline performs additional gateway-specific checks before allowing the AZ-aware SKU swap.
• Even when prerequisites look correct, the Microsoft.Network preflight validation can fail if:
  • The gateway is pinned to a legacy compute cluster that does not support AZ migration.
    • There are hidden dependencies (e.g., active BGP sessions, custom IPsec policies) that block the instance swap.
      • The subscription or region has a capacity constraint for AZ-aware SKUs, which is surfaced only in the inner error.

Next steps to identify the blocker

1. Retrieve the inner error details: Run the migration via Azure PowerShell/CLI with -Debug enabled. The command Start-AzVirtualNetworkGatewayMigration (or equivalent REST call) will output the inner validation error that the portal masks.
2. Check cluster compatibility: Use Get-AzVirtualNetworkGateway and inspect the Sku and GatewayType. If the gateway is hosted on a non‑AZ cluster, migration will fail regardless of subnet size.
3. Validate hidden dependencies:
   • Confirm no custom IPsec/IKE policies are attached.
   • If BGP is enabled, ensure peer configuration matches AZ gateway requirements.
4. Escalate with tracking ID: Since you already have b6c6ad21-ec14-42ed-8987-e420c0f8e516, open a support ticket and provide this ID. Microsoft engineering can trace the backend validation logs to pinpoint the exact blocker.

If this answer helps resolve your issue, please mark it as Accepted so others in the community can benefit.