Checking SQL AlwaysOn Backup Target with fn_hadr_backup_is_preferred_replica

If you're sure the user in question has View Server State (and it looks like in your screenshot he does).

Then there are a number of reasons previously put into an msdn blog. Ranging from:

1. Performance Objects and counters set-up during the SQL Server installation failed.
2. A mixture of 64 and 32 bit platforms.
3. Registry permissions have been skewed

To resolve this we can use the same steps outlined in the guidelines for reinstalling the performance counters in a different stack-exchange post:

Using an elevated administrator command prompt perform the following steps.

1. Change the path to the BINN directory of the SQL Server instance you desire to correct.
   (Ex: C:\Program Files\Microsoft SQL Server\MSSQL10.SQL2008\MSSQL\Binn)
2. Execute unlodctr <<REGISTERED SERVER NAME>>
   For example: unlodctr MSSQL$SQL2008 or SQLAgent$SQL2008 ...
3. Execute lodctr /T:<<perf-sql* matching the counters you desire to load>>
   For example: perf-MSSQL$SQL2008sqlctr.ini or perf-SQLAgent$SQL2008sqlagtctr.ini for SQLAgent. The /T is important to load the SQL Server performance counter provider as a trusted provider.
4. Cycle the remote registry service:
   net stop "Remote Registry" then net start "Remote Registry"
5. Force a WMI synchronization using winmgmt /resyncperfctr "<<PID>>"
   where PID is the process id of the WinPriv.exe (you can get this from Task Manager)

The following may also be required:

• Make sure that the correct security permissions have been granted to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib\009
  registry key:

  1. Grant Full Control permissions to the Creator Owner account.
  2. Grant Full Control permissions to the Administrators account.
  3. Grant Read permissions to the SQL Administrators on that box/Node.
  4. Grant Full Control permissions to the System account

It looks like you are experiencing an error with your Windows clustering. A look at the error that you have on the 2nd node:

[RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)' because of 'Startup routine for ResType MSMQ returned 21.'
[RCM] Failed to load restype 'MSMQ': error 21.
[RHS] s_RhsRpcCreateResType: ERROR_NOT_READY(21)' because of 'Startup routine for ResType MSMQTriggers returned 21.'
[RCM] Failed to load restype 'MSMQTriggers': error 21.

This is explained in MSMQ Errors in the Cluster.log on the Failover Clustering and Network Load Balancing Team Blog, where it says:

Root Cause:

These events are logged because the MSMQ and MSMQ Triggers resource types are registered with the cluster service, but the MSMQ resource DLL cannot be loaded because the MSMQ feature is not installed. The MSMQ and MSMQ Triggers resource types are registered by default when the Failover Clustering feature is installed.

This would only be a problem if you are using MSMQ otherwise it can be ignored as benign.