Summary: In Exchange Server DAG setup, a member server (node) is not operational issue can occur due to several reasons. In this post, we will mention some possible solutions to resolve the issue. We will also mention an Exchange repair tool that can help in recovering data from corrupted databases with ease.
In a Database Availability Group (DAG) setup with Exchange Server 2019, you may face a situation where one of the server nodes shows the status as ‘not operational.’ Although the issue is not that critical, you need to consider that in case of failure of other server/s, the cluster will go down as the node (which is supposed to failover onto) is not operational. In addition, you need to also consider that the replication of data will not happen. In this case, if there is a failover, the data will be inconsistent. Below, we will be discussing the DAG member server is not operational issue in detail and the possible solutions to fix the issue.
What would happen if DAG Member Server is not Operational?
Since the Windows Cluster Service works in tandem with the Database Availability Group (DAG), you would also notice that the Cluster Service is not started although it is set to automatic. Though the cluster would still be operational as the Exchange Server is working on another node, you should consider the databases which are on the non-operational server. These databases will stop working. If the database copy is not healthy, it will not mount. You need to also consider, if the operational server fails, there will be no voting majority in the cluster since there are not enough nodes and the cluster will shutdown the services to protect the integrity.
Ways to Fix the DAG Member Server is not Operational Issue
Here are some possible solutions to resolve the DAG Member Server is not Operational issue.
1. Restart the DAG Member Server
Sometimes, a simple reboot/restart of the Exchange Server can resolve the issue of the member being shown as not operational. So, try to restart the affected server and see if the issue is resolved. You can also try to re-install the Failover Clustering feature in the affected server and restart the server.
2. Check for any Changes
It might happen that any changes that are done recently have caused the issue. You can consult with your IT administration team and network team to ensure that nothing has changed. You can also check the change management process of the company for any recorded changes. This will give an indication of where the problem might be and what might have caused it.
3. Check and Start Windows Cluster Service
The Database Availability Group depends on the Windows Server Cluster Service. Without this service, it will not be operational. The service is normally set to automatic startup. However, in this case, you will find that the service is not running. You can try to start the service.
4. Check the Permissions
When starting the Cluster Service, you may encounter an error saying, “Windows could not start the Cluster Service on Local Computer.” If you have setup the Cluster Service to run as a specific user, you should check the user for any issues, like the password has expired or the wrong password was configured or the account is locked out. You should also check the domain user (used to start the Cluster Service) has the necessary local administrator rights on the Exchange Server Machine. For this, go to Computer Management > Local Users and Groups > Groups and check if the user is part of the Administrators Group.
You can also check the permissions of the user in the Failover Clustering Manager. For this,
- Open the Failover Cluster Manager.
- Right-click on the cluster name and click on Properties.
- Go to the Security tab and make sure that the domain user is listed with the right permissions.
Next, check the permissions in the Exchange Server by running the following command in the Exchange Management Shell (EMS).
Add-ADPermission -Identity "<DAG Name>" -User "<Account>" -AccessRights GenericRead, GenericWrite -ExtendedRights WriteDacl
The above command will run the process to grant the rights to the domain user. If it will show a warning, this means that the user already has the permissions.
The user should also have full permissions on the Active Directory Organizational Unit (OU). To check this,
- Open the Active Directory Users & Computers.
- Find the Organizational Unit (OU) where the DAG Servers and resources are.
- Right-click on the server object and click on Properties.
- Under the Security tab, make sure that the account has Full Control on the objects.
5. Check the Event Viewer
You can check the Event Viewer to see if there are any hints to what the problem might be. In the event logs, you can look for the below entries of the affected server:
- Event ID 1069 – This indicates a failover cluster failure of a resource.
- Event ID 1254 – This indicates that the cluster service has failed to bring the cluster role online.
- Event ID 4113 – This indicates an issue with a database copy in the cluster.
If the case of Event ID 4113, you can run the Get-MailboxDatabaseCopyStatus command to identify the issues.
To Conclude
Above, we have discussed various ways to resolve the DAG member server is not operational issue. If the problem persists, you need to consider the fact that the databases on the server might get damaged or corrupted. To recover the data from corrupted databases within minimal downtime, you can take the help of specialized Exchange recovery tools, like Stellar Repair for Exchange. It can assist you in recovering the data from corrupted databases as quick as possible and with no data loss. With this tool, you can open any Exchange Server database in any state and of any size. You can then browse through the data stores without having a running Exchange Server. You can granularly export the mailboxes and other EDB data to PST and other file formats, or to a live Exchange Server with automatic mailbox matching. The tool can also used to migrate the EDB data to a Microsoft 365 tenant.
