Can not register backup for SQL on virtual machine by using Azure recovery service vault

Question

We used Azure recovery service vault for SQL backup. Last time, it worked normally. Recently, yesterday we found that our Sql server did not backup, there is no backup history, recovery service vault empty. We checked the activity log but did not find anything else related. It was so strange. Today, we tried to enable backup for SQL server by recovery service vault, but it was failed at Discovery's DB step. On the NSG rule, we have opened firewall with Service tags for Azure Backup, Storage and AzureAD via port 443.

Looking forward to your help !

Answer 1

Microsoft engineer said that due to our SQL on virtual machines are member of an Azure Load Balancer ( Internal ) which does not have public IP address, as default setting Internal load balancer will not allow to communicate with Azure Backup services endpoint.

In other hand, does not have any option to register Azure Backup services endpoint for Azure subnet, so Azure VM can not connect to Azure Backup service even we have the outbound rules to connect to Azure Backup, Azure AD, and storage account via port 443.

If we want to setup Backup for SQL, we can :

• Remove VM from backend of Internal Load balancer
• Or assign a Public IP address to VM
• Or using NAT gateway

On Sep, I noticed that SQL on our VM still worked well, but from Oct I guess Microsoft has changed their setting, which does not allow the Internal Load balancer to connect to Azure services such as Backup.

Answer 2

Hello,

I have tried to Re-register SQL backup on Vault, I found that AzureBackupWindowsWorkload was provisioning state. Also, plugin was trying to install. After about 20 mins, the process failed, AzureBackupWindowsWorkload plugin removed.

I have reached that VM could not communicate with Azure Backup services endpoint , IP address 20.194.74.5, 20.194.74.6

I think, as MS engineer shared, due to our VMs can not connect to Azure backup service because these VMs are LB internal backend.

As I understand, the outbound connectivity from VMs to Azure Backup service will be transit on Microsoft network instead of Internet, so Outbound NSG to AzureAD, backup service and storage account with port 443 are enough.

TLS 1.2 did not enable, but it is SQL on Prod environment, so we can't do it at the moment.

• Test-NetConnection <region>.backup.windowsazure.com -Port 443 : FAIL
• Test-NetConnection login.microsoftonline.com -Port 443 : PASS
• nslookup <region>.backup.windowsazure.com : FAIL
• C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.RecoveryServices.WorkloadBackup\
  • (and if present) C:\Program Files\Azure Workload Backup\Logs\ Log : connect to 20.194.74.5, 20.194.74.6 fail.

Answer 3

Hi Hanh Trinh,

Thanks for contacting to Microsoft QA.
This usually happens when the AzureBackupWindowsWorkload extension on the VM can’t reach Azure Backup endpoints, or the VM’s registration with the vault is stale (common after RG/subscription moves or if protection was stopped). The wizard then fails at Discover DB even though 443 is open.

please do in order:

1. Re-register the VM with the vault Portal → Recovery Services vault → Backup infrastructure → Azure Backup for SQL in Azure VM → find the VM container → Re-register. This pushes the workload extension again and refreshes the vault mapping.
2. Check the extension and services on the VM VM → Extensions: status should show AzureBackupWindowsWorkload (provisioning succeeded). On the VM (PowerShell):
   • Get-Service AzureWL*
   • Restart-Service AzureWLBackupPluginSvc, AzureWLBackupCoordinatorSvc -Force Also make sure these are running: SQL Writer, Volume Shadow Copy.
3. Verify TLS 1.2 and time Ensure TLS 1.2 is enabled (no SSL inspection/termination on 443), Windows is patched, and time is in sync (w32tm /resync). Older images may need the strong-crypto registry keys for .NET.
4. Prove outbound connectivity from the VM (NSG tags aren’t enough if there’s a corporate firewall/proxy) Allow 443 to these FQDNs (no HTTPS inspection):
   • *.backup.windowsazure.com (region-specific backup service)
   • *.blob.core.windows.net (storage)
   • login.microsoftonline.com (AAD)
   • *.servicebus.windows.net (control/notifications)
   • *.azure-automation.net (as applicable) Quick tests:
   • Test-NetConnection <region>.backup.windowsazure.com -Port 443
   • Test-NetConnection login.microsoftonline.com -Port 443
   • nslookup <region>.backup.windowsazure.com
5. Try discovery again Vault → Discover DBs. You should see instances within a couple of minutes.

If it still fails, grab logs from:

• C:\WindowsAzure\Logs\Plugins\Microsoft.Azure.RecoveryServices.WorkloadBackup\
• (and if present) C:\Program Files\Azure Workload Backup\Logs\

Share the latest error lines and the vault/region—happy to pinpoint the exact egress or registration issue.