I am trying to setup Managed Backup (in Azure SQL) using SQLServer 2014 (Ent 64bit) and it is failing.

I have the credential created with Identity as the Storage account name and Password set with current Access key, I've tried both keys as well.

When I run through the GUI to Enable managed backup, set the retention period, add the SQL credential (which updates the Storage URL) and I press OK, I get the follow error message back: Alter failed for

SmartAdmin 'Microsoft.SqlServer.Management.Smo.ObjectKeyBase'. (Microsoft.SqlServer.Smo)

Failed to access the storage URL 'https://[storageaccountname].blob.core.windows.net/' using credential 'MyCredName'. Provide a valid SQL Credential for the storage URL. (Microsoft SQL Server, Error: 45207)

I downloaded Azure Storage Explorer from codeplex to test connection and it works, I can browse, upload, delete from my local machine.

I tried this from one of our on prem servers as well and same error. What am I missing?

  • Error message is clear,can you double check your credential Aug 18, 2016 at 16:18
  • That was my thought too, which is why I am thinking I am missing something super simple. The credential has been deleted and recreated numerous times. I've tried key 1 and key 2, still no dice. I validated it authenticates and provides access to the URL by using Azure Storage Explorer.
    – nkdbajoe
    Aug 18, 2016 at 16:45
  • Is the URL correct? Don't you need to provide the container as well? I don't know for sure, which is why I'm asking. Aug 18, 2016 at 22:23
  • URL is correct, yes. I did try the container, however that is not permitted. Specifying a container name is not allowed as part of the URL configuration. Input an URL for the storage account without the container, such as: 'mystorage.blob.core.windows.net'.
    – nkdbajoe
    Aug 19, 2016 at 15:44

1 Answer 1


Issue identified. The network admin didn't have the separate Azure domain environments trusted, although he said that he did. I tried this and failed in our SQL DEV environment/domain in Azure, which isn't trusted. I then, for sake of troubleshooting and communicating to the powers to be, tried it from our SQL QA environment/domain in Azure and it worked flawlessly! The network admin compared the two environments and found the issue. Network issue after all.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.