Exchange 2013 unable to edit the DAG settings

I reconfigured the File Share Witness directory, and some of the error messages disappeared. However, I am still receiving an error message in the EMS when running "Get-DatabaseAvailabilityGroupNetwork": "A server-side administrative operation has failed. The Microsoft Exchange Replication service may not be running on server xyz.local. Specific RPC error message Error 0x6d9 (There are no more endpoints available from the endpoint mapper) from cli_GetDagNetworkConfig."

Additionally, when activating the database on another server that is part of the DAG, users get disconnected from Outlook and are unable to access OWA. Previously, it was working fine. I am unsure what the main issue is, but it seems there is something on the network causing the HA to not work properly on the DAG.

Hello @Innocent Heartvoice,

Thanks for your response.

Regarding the error you encounter, this indicates that there are problems with RPC communication between the server, which may affect the high availability group (HA) function of the database availability group (DAG). In view of the fact that the database will disconnect the database on another DAG server, other information connected to the Outlook and OWA, there may be problems such as network configuration and client access services.

I suggest you try the following methods to solve the problem:

1. Make sure that the Microsoft Exchange replication service runs on the wrong server. You can use the following command to check and start the service:

Get-Service MSEXCHANGEREPL

Start-Service MSEXCHANGEREPL

2. Check the services related to RPC, such as whether the RPC Endpoint Mapper and Remote Procedure Call (RPC) service run normally. You can use service management tools to check:

a. In the Windows search bar, enter the Services.msc and open it.

b. In the service list, find the Remote Procedure Call (RPC) service. This service usually cannot be stopped or restarted because it is crucial to the Windows system.

c. Next, find the RPC Endpoint Mapper service and check its status. This service is also a core service, and its state should be running.

3. Make sure no new firewall rules may prevent RPC communication. This includes any network firewalls between the Windows Firewall and DAG members on the local computer.
4. Make sure that all the services required for client connection are running normally. This includes services on the client access server (CAS), which helps connect to Outlook and OWA. You can use the following PowerShell command to check the status of related services:

Get-Service MSEXCHANGEADTOPOLOGY, MSEXCHANGERPC, MSEXCHANGEFRORONTENDTRANSPORT, MSEXCHANGETRANSPORT, W3SVC, IISADMIN | FORMAT-Table Name, Status, Status

Please feel free to contact me if you have any queries.

Best,

Jake Zhang

Hello Jake,

I really appreciate your detailed response. I have checked all the services and executed the EMS and all services are running and couldn't find any issues or error messages. I agree with point 3 that something might be blocked by the firewall, but I haven't been able to identify what or where the ports are being blocked.

Could you kindly suggest any clues to find the root cause of the problem and resolve this issue?

Hi @Innocent Heartvoice,

Thanks for your response.

Based on your description, we are glad that we may have found the problem. Regarding how to determine what or where the port is blocked by the firewall, we suggest that you follow the following methods to solve the problem:

Check the firewall rules and ports. Make sure that the firewall rules allow the ports required for Exchange DAG operations. Here are some basic ports that should be open:

1. Microsoft Exchange Replication Service

a. MSExchangeRepl: Usually uses dynamic RPC ports and requires RPC endpoint mapping (port 135).

b. Client Access Service: Port 80 (HTTP) and 443 (HTTPS), used for Web services such as OWA.

c. MAPI: Port 135 (RPC) and dynamic RPC port range (default is 49152-65535).

2. You can use the telnet tool to verify the connection from another DAG member to these ports on the target server: telnet <target server> 135 For a specific dynamic port, you can use: telnet <TargetServer> <PortNumber>

Please feel free to contact me if you have any queries.

Best,

Jake Zhang

Hello Jake,

Thanks for the response.

Finally, I am pleased to inform you that the issue has been resolved. The solution involved putting the new server into maintenance mode and directly upgrading from CU7 to CU23. I followed the steps outlined in these articles: "Put Exchange Server in Maintenance Mode" and "Take Exchange Server Out of Maintenance Mode".

After performing the steps detailed in both articles and restarting the server, I moved the database to the new server. The connection was established immediately, and Outlook Web Access (OWA) also started working properly.

I believe the core issue was that the new database was hosted on new server hardware running on VMware, whereas the previous server was on old hardware running on Hyper-V. Despite discussing the problem with many individuals, no one considered that the difference in virtualization platforms might be the cause.

Updating to CU23 resolved the problem, and now the Exchange mailbox is functioning correctly. This experience highlights the importance of ensuring compatibility between the virtualization platform and server updates to avoid similar issues in the future.