Can't Create Cluster Witness with Azure Storage RRS feed

  • Question

  • I have created an Azure storage account with the following configuration:

    Account Kind: Storage V2 (General Purpose V2)

    Performance: Standard

    Secure Transfer Required: Disabled

    Access-Tier: Cool (Also tried Hot)

    Replication: LRS

    I have tried creating a cloud witness through Cluster Manager and also through Powershell, with the following command:

    Set-ClusterQuorum -CloudWitness -AccountName myaccount -AccessKey mykey

    But always get the following error:

    An error occurred while validating access to Azure from cluster node 'Clustername-C.DomainName.com'.    Verify the Azure storage account name, storage account type, storage account key, and network connectivity over HTTPS.At line:1 char:1

    I have tried re-generating the keys. 

    I have tried creating a different account (v1 general purpose)

    I have downloaded Azure Storage Explorer to the node to check I can access the account

    Any ideas welcome

    Wednesday, November 6, 2019 1:07 PM

All replies

  • Hi,

    What do you put for the 'myaccount' part of the PS?  When you do this through Failover Cluster Manager, the storage name you add is not the FQDN, it is just the subdomain.  So if your storage account for this is domain.blob.core.windows.net - you only have to type 'domain' and it adds the rest.

    If you go via Failover Cluster Manager, can you send a screenshot of what you add (but please mask the account key).



    Wednesday, November 6, 2019 7:12 PM
  • Do you still get the same error message when secure transfer required is disabled ? it seems that it mentioned the use of HTTPS in the error message.
    Wednesday, November 6, 2019 9:35 PM
  • Just checking in if you have had a chance to see the previous response. We need the previously asked information to understand/investigate this issue further.
    Friday, November 8, 2019 7:55 AM
  • Yes, I am specifying the account name correctly.


    • Edited by SQLPete79 Saturday, November 9, 2019 9:08 AM
    Saturday, November 9, 2019 9:00 AM
  • Yes. I have toggled Secure Transfer Required on, and it gives the same error as when it is off.
    Saturday, November 9, 2019 9:03 AM
  • Sorry, for delay. I still have the issue and have replied to both queries.
    Saturday, November 9, 2019 9:03 AM
  • Hi,

    Are you able to telnet to the FQDN of the storage account on 443 from the SQL servers? And have you double checked the key is valid?

    I've only seen an issue in this way when the ports are closed or the key isnt valid as the screenshot you sent looks correct for what is needed.

    I've just looked at my accounts that use this and they are all V1 - have you tried that?

    The MS docs say it needs to be a general purpose and Standard as yours is but mine all show as V1 so may be worth trying that? 



    Sunday, November 10, 2019 8:06 PM
  • Thanks. I have tried a V1 and a V2 account.

    From the cluster nodes, I can run successfully run Test-NetConnection against the storage account on 443.

    I also know the key works, as I have connected using it (from the cluster nodes) Azure Storage Explorer. I did also try rotating the key, however. Didn't help.

    If it helps, the failure is really fast. It doesn't seem like its trying to authenticate.

    Monday, November 11, 2019 7:45 AM
  • Hi,

    The only other difference with all of the ones I have done, is all mine have ''Secure Transfer Required' set to enabled whereas yours is disabled.  This can be changed from the 'configuration' blade of the storage account.

    Thats the only other thing I can think of currently.



    Monday, November 11, 2019 10:51 PM
  • Thanks Matt,

    I have tried with this set to both on and off. It doesn't make a difference.


    Tuesday, November 12, 2019 3:27 PM
  • Hi Pete,

    Weird...if the telnet works on 443  then DNS is obviously working.  The settings you have look correct for what is needed and match loads of mine that work successfully. 

    Do you have a support contract with MS for this to contact them directly?  The only other thing I would suggest to try is to use the other storage key...so if you've used the primary key, try the secondary.

    Other than that it all looks like it should work.



    Tuesday, November 12, 2019 8:50 PM
  • Is there any update on the issue?

    If the suggested answer helped for your issue, do click on "Mark as Answer" and “Vote as Helpful” on the post that helps you, this can be beneficial to other community members.

    Thursday, November 14, 2019 4:35 AM
  • Second key also tried and not working.

    No support contract.


    Thursday, November 14, 2019 5:51 AM
  • @SQLPete79 We will try and help you get a one-time free technical support. In this case, could you send an email to AzCommunity[at]Microsoft[dot]com referencing this thread as well as your subscription ID. Please mention "ATTN subm" in the subject field. Thank you for your cooperation on this matter and look forward to your reply.


    Do click on "Mark as Answer" on the post that helps you, this can be beneficial to other community members.

    Thursday, November 14, 2019 11:01 AM