Introduction
When troubleshooting issues with an Exchange IP-Less/AD-Detached Database Availability Group you cannot use the Failover Cluster Manager to connect to the cluster.
In this post, I’ll demonstrate how to validate a cluster in this scenario for Exchange 2016 or 2013 SP1 DAGs on Server 2012 R2.
IP-Less Clusters
First, let’s provide a bit of background on IP-Less clusters. These are simpler to set up than the the traditional cluster as they don’t require any AD permissions or cluster IPs but are only available in Exchange 2013 SP1 and Server 2012 R2 or later.
You’ll find that there is no Cluster Name Object (CNO) created in AD for the cluster and this is why no AD permissions are required. Note that although it’s called an AD-Detached cluster, both cluster nodes need to be joined to the same domain, even if the cluster is not used for Exchange.
You cannot use the Failover Cluster Manager to connect and manage the cluster because there’s no IP to connect to. Before you go ahead and try it, you also cannot connect to a single node in the cluster either! Sorry. In both cases, you get this connection error:
Cannot connect without an administrative access point
You cannot use Failover Cluster Manager to manage a cluster that was created without an administrative access point.
You must use Windows PowerShell to manage the cluster.
Validate an IP-Less or AD-Detached Cluster
You should validate your DAG cluster nodes before you create the cluster and after any changes that are made to the configuration of the cluster or hardware. It’s also a good idea to to validate your cluster when troubleshooting cluster issues.
You can either use the Failover Cluster Manager or PowerShell to validate the cluster. See below for instructions for both methods. Both will provide the same report.
Validate a cluster using the Failover Cluster Manager
Now, you cannot connect to the cluster but you can validate a cluster. Here’s how:
Open up the Failover Cluster Manager:
Click on Validate Configuration in the pane on the right:
Click next then enter the hostname of one of your Exchange DAG members:
Click Add:
We now see that the other DAG member or members have been found and the DAG name (DAG01) is displayed.
Click Next, select “Run all tests (Recommended)” as below then click Next:
You’re now presented with with a list of tests that will be performed. Click Next:
The cluster validation tests run:
When complete, you’ll be presente with the screen below:
Click on View Report. We’ll go through the warnings in this report later in this post.
Validate a cluster using PowerShell
To validate the cluster using PowerShell, we use the command below. You can run this from any DAG member:
Test-Cluster
You’ll see a number of storage warnings when you run this command. We’ll come to this in the next section in this article.
To view the report, open the report file path which is specified in the last line of the verbose output (yellow text).
DAG Cluster Validation Report Warnings
You shouldn’t see any errors on your report. If you do then your cluster is not supported by Microsoft and you’ll need to go through each error and resolve it. In the case of an IP-Less DAG, you will see some warnings as below and we’ll go through the Storage and System Configuration warnings.
Storage: No disks were found on which to perform cluster validation tests.
When you click on the Storage section, you’ll find a number of warnings:
These are all for the same reason: No disks were found on which to perform cluster validation tests.
The failover cluster validation wizard checks the storage by default and looks for shared storage in use by the cluster then runs a number of tests on this. As this is a Database Availability Group, we don’t require shared storage because the databases are replicated between each server. We’re also using a file share witness so we don’t even have a shared disk for the quorum.
For this reason, you can safely ignore these warnings.
System Configuration
There’s two warnings under System Configuration > Validate Cluster Service and Driver Settings:
These warnings are below:
- The “Cluster Group” does not contain a Network Name resource. The cluster will have to be managed by connecting to the node names.
- The “Cluster Group” does not contain a Cluster IP Address resource. You must manage the cluster by connecting to the nodes.
As we mentioned earlier, an IP-Less/AD-Detached cluster doesn’t have a Network Name or Cluster IP Address resource which means that these warnings are expected and we can ignore them.
Conclusion
In this post, we’ve gone through a bit of the basics of IP-Less/AD-Detached clusters then we’ve demonstrated how to validate your DAG cluster and what errors you can ignore.
For more information on DAG troubleshooting, see the multi-part series here.