Unable to enable SQL AlwaysOn High Availability when joined to specific cluster.

Andy 86 Reputation points
2020-12-14T20:27:01.213+00:00

Hello.

I'm having difficulty enabling AlwaysOn High Availability on any new server I add to a failover cluster. All servers are running Windows Server 2019 Datacenter. The server joins to the cluster with no issues.

The error states:
Unable to save the AlwaysOn High Availability settings [return code: 0x80041033].

There are servers already on the cluster that have always on enabled, so it worked at some point.

When we add the same server(s) that produce the error on another cluster we can enable always on without issue.
Therefore I believe the issue must lie with the cluster itself.

We can't find anything specific in the logs for this issue outside what I have listed.

Has anyone else come across this issue?

Thanks.

SQL Version: Microsoft SQL Server 2016 (SP2-CU15) (KB4577775) - 13.0.5850.14 (X64)

SQL Server
SQL Server
A family of Microsoft relational database management and analysis systems for e-commerce, line-of-business, and data warehousing solutions.
12,678 questions
Windows Server Clustering
Windows Server Clustering
Windows Server: A family of Microsoft server operating systems that support enterprise-level management, data storage, applications, and communications.Clustering: The grouping of multiple servers in a way that allows them to appear to be a single unit to client computers on a network. Clustering is a means of increasing network capacity, providing live backup in case one of the servers fails, and improving data security.
958 questions
Accepted answer
  1. Cris Zhan-MSFT 6,601 Reputation points
    2020-12-16T06:15:48.113+00:00

    Hi anonymous user-2453,

    >Windows Management Instrumentation has stopped WMIPRVSE.EXE because a quota reached a warning value. Quota: HandleCount Value: 37458 Maximum value: 4096 >>WMIPRVSE PID: 5332 Providers hosted in this process: C:\Program Files\Microsoft SQL Server\130\Shared\sqlmgmprovider.dll, C:\Program Files\Microsoft SQL >>Server\130\Shared\sqlmgmprovider.dll

    It looks like this is a WMI issue. I would recommend you to read this blog-WMI: How to Troubleshoot WMI High Handle Count.

    Based on the application log information you provided, because the handle quota is much higher than the set limit, you may need to perform data collection to find out the cause of the high handle count.

    If possible, stop the always on availability group role in the failover cluster manager Before trying to enable the AOAG feature. But this will shut down the availability group and make the databases temporarily unavailable.Please decide based on your environment, this is just an attempt.

    Please also refer to this similar case.

    If the answer is helpful, please click "Accept Answer" and upvote it.
    What can I do if my transaction log is full?--- Hot issues November
    How to convert Profiler trace into a SQL Server table -- Hot issues November

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Cris Zhan-MSFT 6,601 Reputation points
    2020-12-17T03:02:20.357+00:00

    Hi Andy-2453,

    When the problem only occurs in a specific cluster, it does make us suspect that this cluster has something special.

    Stop the role is an attempt, not sure if it is the solution, and in that post with a similar situation to yours, the questioner mentioned that he has reinstalled SQL Server and WSFC cluster, which seems to be of no use. Maybe you need to collect data then open a support incident.

    0 comments
  2. Trayce Jordan 6 Reputation points Microsoft Employee
    2022-06-21T22:23:46.973+00:00

    I recently ran into the same error message using PowerShell, though I had no WMI errors or handles issues.
    Our issue was intermittent and only on the would be secondary.
    Our theory was that the "secondary" (in quotes because it wasn't one yet, but designated to be) could not contact the cluster.
    To confirm our theory, we shut down the cluster services and ran our PowerShell code - and we reproduced the issue at will.
    So more than likely the problems above were because the cluster could not be contacted.

    On another note - a "cluster" is more than a "name" - so if you delete everything to do with a cluster, but don't disable AlwaysOn feature, even if you create a new cluster with the same name, it won't work properly. You would have to disable the AG feature and then re-enable the AG feature (restarting each time) before you would be able to successfully get the feature installed and running properly.

    0 comments