Occasional problem using Active/Passive Windows Cluster with Message Queuing Role

Question

Hi,

I am experiencing an occasional problem with an Active/Passive Windows Failover cluster and would like to get some help and guidance on how to find the root cause to the problem. The cluster is setup using two Windows Server 2019 with a quorum disc as witness. The cluster has an Message Queuing role and this is where I can see the problem.

When testing the installation everything seems to work as expected on both nodes and even when failing over the functionality is as expected. So far everything seems fine but when using the failover cluster manager every now and then I can see an information message saying "Problem Accessing Client Access Point. For more data see Information Details". When clicking on "Information Details" an error message is displayed stating "Unable to find a Client Access Point dependency for Message Queuing 'MSMQTEST'". This can happen on both nodes and after a refresh the message disappear.

I have no way to reproduce the error but it keeps coming back occasionally. As this is a very critical service in our installation we have a bad feeling and would very much appreciate some input on this error to be able to solve it. We cannot see that this has an negative effect on the functionality in the test environment but when moving to production the workload will be completely different and any problem would be non acceptable.

Is there anyone out there that has experienced a this scenario? Any suggestions of where to look for any logging that can help in the right direction?

BR, Stefan

Answer 1

I have run into that issue quite a few times with a clustered MSMQ role on Server 2016 and 2019. I do have a couple 2019 clusters with MSMQ clustered that do work every time, but I also have one that I could not get to work and another that occasionally will give errors opening the management console. I've been following the path of a DNS issue or AD rights on the role, but still no luck on what could be causing it.

It's getting bad enough that I am currently looking for an alternative to using MSMQ in a clustered role at all, considering that since Server 2012 it also takes almost a minute for MSMQ to failover, which seems a bit too long for my purposes.

Derek