none
Cannot create Cloud Witness Quorum disk in Azure File Storage RRS feed

  • Question

  • Hello,

    We have a two-node Windows 2019 Failover Cluster and we want to add a Cloud witness Quorum disk to the cluster. We followed the instructions from the TechNet libraries to create in Azure a File Storage and add this storage as a Cloud Witness disk to the Failover Cluster.

    When we use the add cloud witness wizard in the Failover cluster management console it ends with this error:

    "Please check your storage account name, endpoint, and access key and HTTPS connection"

    In the Windows Firewall ports 443 and 445 are not blocked from inside to the Internet from both nodes. The 'Test-Connection' PS command also is successfull. We don't use proxy or proxy servers for Internet access. The storage account is a 'general purpose' 'standard' account with LRS replication just like the TechNet article adviced.

    It looks like that the Cluster AD object doesn't have the right to connect to Azure resources, however I can't find any documents or blogs that describes such a problem..

    Maybe someone has any idea where to look?


    Saturday, September 14, 2019 1:59 PM

Answers

  • Hello SumanthMarigowda,

    Many thanks for the one-time free technical support!

    And for those who want to know the solution, it was too simple for words! Because there was already a physical Witness Disk configured for the Failover Cluster, the Cloud Witness Disk wizard could not proceed to succesfully add a Cloud Witness Disk. Removing the already configured physical witness disk and running the Cloud Witness Disk wizard again was the solution! All went right..

    Maybe Microsoft could generate a warning during the 'add Cloud Witness Disk wizard' that there already is a witness disk and that this one should be removed first! Or the Failover Clustering setup guide could a little bit specific on this behaviour..

    I'm very glad you people helped me out!

    Thanks,

    Victor

    Friday, September 27, 2019 4:13 PM

All replies

  • Hi

    Can you provide the screenshot by following the below link when go to the 6th Step of the link.

    https://docs.microsoft.com/en-us/windows-server/failover-clustering/deploy-cloud-witness#to-configure-cloud-witness-as-a-quorum-witness

    Thank you


    If this post helps to resolve your issue, please click the "Mark as Answer" of that post and/or click Answered "Vote as helpful" button of that post. By marking a post as Answered and/or Helpful, you help others find the answer faster.

    Saturday, September 14, 2019 2:11 PM
  • Hello,

    The screenshot is in the Dutch language, it's difficult to translate. The wizard ends at step 5 after confirming the three entries.

    Saturday, September 14, 2019 3:20 PM
  • Saturday, September 14, 2019 3:21 PM
  • Could you try translating at-least the error message.

    Thank you


    If this post helps to resolve your issue, please click the "Mark as Answer" of that post and/or click Answered "Vote as helpful" button of that post. By marking a post as Answered and/or Helpful, you help others find the answer faster.

    Saturday, September 14, 2019 3:46 PM
  • Hi,

    Sorry for that.. I Will try to translate it well.

    At the red circle with the X: An error occurred during validation to access Azure from the cluster node <name_of_the_cluster>

    Under the section "Fouten" which means "Errors" "* An error occurred during validation to access Azure from the cluster node <name_of_the_cluster>" and "Check your storage account name, the type of storage account and the network connectivity through HTTPS"

    Saturday, September 14, 2019 7:08 PM
  • Can you confirm the FQDN used for storage and that you can ping that name and telnet from that SQL server to the FQDN on 443?

    Thanks,

    Matt

    Saturday, September 14, 2019 8:46 PM
  • Hello Matt,

    I not really understand what you mean, but I looked into the 'properties' section of the Azure Storage and try to ping to <storagename>.file.core.windows.net and it resolved to another name and IP address: 

    file.dub07prdstr01a.store.core.windows.net [52.239.138.72]

    The ping request didn't succeed

    But when I Telnet to <storagename>.file.core.windows.net 443 I get connection though the screen is fully black, no errors and no cursor. 

    Is this what you mean?

    Thanks

    Victor

    Saturday, September 14, 2019 10:47 PM
  • Hi Victor,

    Yeah, that is expected.  It wont return an ICMP response and blank black screen for telnet is correct.

    Can you screenshot the storage details you use when trying to use cloud witness?  Please blank any keys or sensitive info

    Thanks,
    Matt

    Saturday, September 14, 2019 10:57 PM




    • Edited by VV-Maxx Sunday, September 15, 2019 10:11 AM
    Sunday, September 15, 2019 10:02 AM
  • Hi,

    That all looks OK.  I assume you have verified the account keys?  Are you able to do a test from that VM to ensure it can connect to the storage account with this guide?

    I've never had an issue doing what you're trying and I've done it a lot of times....so I'm sure we can figure it out.

    Thanks,

    Mat

    Sunday, September 15, 2019 5:50 PM
  • Hello Matt,

    Yes it can connect.. I've created a subfolder in this Azure File Storage area and connected it succesfully as a share into this 'Cluster Node' computer with the commands from 'this guide' It works flawless and we can copy and paste files into it and it connects perfectly after rebooting the server..

    So from the Failover Cluster Management Console we can't connect to the same Azure File Storage to let the wizard create a 'BLOB' share on which the Cloud Witness disk runs.. but we can connect a sub folder share within the same storage area using the same credentials (key) from the Windows Explorer!

    Sunday, September 15, 2019 6:54 PM
  • Odd.  And you use the same account creds for both?  I can run a test tomorrow to see what I use in the boxes as I never think too much about it but can show an example of mine working.

    If the same VM can connect via mapped drive then clearly the ports are open so there must be something else there...we'll figure it out though.

    Thanks,
    Matt

    Sunday, September 15, 2019 7:02 PM
  • Yes, same credentials (key string) 

    Thanks,

    Victor

    Sunday, September 15, 2019 9:55 PM
  • @VV-Maxx Just checking are you still finding any difficulties on the above mentioned query?
    Wednesday, September 18, 2019 7:01 AM
    Moderator
  • Hello,

    Yes we still can't configure the Cloud Witness Storage to our Server 2019 Failover Cluster..

    Thanks,

    Victor

    Wednesday, September 18, 2019 11:29 AM
  • This may require a deeper investigation, so If you have a support plan, I request you file a support ticket, else please do let us know, we will try and help you get a one-time free technical support. In this case, could you send an email toAzCommunity[at]Microsoft[dot]com referencing this thread. Please mention "ATTN subm" in the subject field and subscription ID. Thank you for your cooperation on this matter and look forward to your reply.

    Thursday, September 19, 2019 5:41 AM
    Moderator
  • Hello SumanthMarigowda,

    Thank you for the advice, I've send a request for one-time free technical support

    Thanks,

    Victor

    Thursday, September 19, 2019 8:16 AM
  • Hello SumanthMarigowda,

    Many thanks for the one-time free technical support!

    And for those who want to know the solution, it was too simple for words! Because there was already a physical Witness Disk configured for the Failover Cluster, the Cloud Witness Disk wizard could not proceed to succesfully add a Cloud Witness Disk. Removing the already configured physical witness disk and running the Cloud Witness Disk wizard again was the solution! All went right..

    Maybe Microsoft could generate a warning during the 'add Cloud Witness Disk wizard' that there already is a witness disk and that this one should be removed first! Or the Failover Clustering setup guide could a little bit specific on this behaviour..

    I'm very glad you people helped me out!

    Thanks,

    Victor

    Friday, September 27, 2019 4:13 PM
  • Hi,

    That same error also appears if the key or storage name is incorrect.  I know that was not your issue but if others have the same issue then that can also cause it (I did this today).

    Thanks,
    Matt

    Wednesday, October 2, 2019 1:31 AM