0

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 – TheGameiswar Aug 18 '16 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 '16 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. – Randolph West Aug 18 '16 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 '16 at 15:44
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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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