Exchange 2013 unable to edit the DAG settings

Innocent Heartvoice 296

My environment is Exchange 2013 with a single CAS server and a DAG with two servers in the primary site and one server at the DR/secondary site. I am facing an issue where, when I try to edit the DAG properties, I receive the error message: "The Microsoft Replication service may not be running on server ABCD. Error: Error 0x6d9 (There are no more endpoints available from the endpoint mapper from the cli_RpccGetDBSeedStatus)."

I received the same error while creating a database copy on another server: "The seeding operation failed. Error: The Microsoft Replication service may not be running on server. Error: Error 0x6d9 (There are no more endpoints available from the endpoint mapper from the cli_RpccGetDBSeedStatus)."

The current situation is that the databases are now mounted, but when I switch the database from the primary server to the second server, Outlook disconnects and goes into a disconnected state.

I changed the File Share Witness path, but mistakenly added another one, and now two paths are showing for the File Share Witness.

This situation is quite messed up, and I need support to ensure the databases can smoothly transition from one server to another.

2 answers

Andy David - MVP 149.1K Reputation points MVP

2024-05-30T10:44:09.86+00:00

Exchange 2013 is out of support.

My recommendation is to not continue to troubleshoot this and build a new DAG using Exch 2019.

Then migrate your mailboxes and settings to the new servers

You can use the Deployment Asst to assist in the migration:

https://learn.microsoft.com/en-us/exchange/exchange-deployment-assistant?view=exchserver-2019
Please sign in to rate this answer.
Innocent Heartvoice 296 Reputation points

2024-05-30T12:21:36.55+00:00

We have already decided to move to the cloud, either to Office 365 or Google Workspace, by the end of this year. However, before moving online, we need to stabilize the current infrastructure. If you have any recommendations or suggestions to resolve this issue, please let us know.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
Jake Zhang-MSFT 6,375 Reputation points Microsoft Vendor

2024-06-03T03:19:01.58+00:00
Hi @Innocent Heartvoice,

Welcome to the Microsoft Forum for technical support.

Thanks for your detailed description. The issue you are experiencing involves DAG (Database Availability Group) in Exchange 2013. Below I will give you some initial suggestions for the issue you are experiencing.

First, let's deal with the error message "The Microsoft Replication Service might not be running on server ABCD. Error: Error 0x6d9". This error is usually related to RPC connectivity. Here are some possible solutions:

Check RPC connectivity: Make sure that the Microsoft Exchange Active Directory Topology service on server ABCD can communicate via RPC. You can try to verify this error through a web logon. If it is a port issue, you may need to check the settings of the new router.

Check DNS records: Make sure that the DNS records are correct. Sometimes incorrect DNS records can cause this type of problem.

Next, let's resolve the "Seeding operation failed" issue. This is usually related to the DAG network configuration. Here are some steps:

In the Exchange Management Console (EAC), go to Servers > Database Availability Groups.

Confirm your DAG network configuration. You can manually configure the DAG network in the DAG network properties. If you can't find the manual configuration option in the EAC, you can use the Exchange Management Shell to run the following command to display the DAG network configuration settings and verify that the DAG network was successfully configured: Get-DatabaseAvailabilityGroupNetwork <DAGNetworkName> | Format-List

Make sure the DAG network is configured correctly, including the IP address and subnet.

If you changed the file share witness path, make sure the path is correct. You can use the following command to view the current status of the DAG witness server: Get-MailboxDatabaseCopyStatus -Server <ServerName>

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

Best,

Jake Zhang
Please sign in to rate this answer.
Innocent Heartvoice 296 Reputation points

2024-06-04T11:19:00.0866667+00:00

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.

Jake Zhang-MSFT 6,375 Reputation points Microsoft Vendor

2024-06-06T09:10:11.8633333+00:00

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:

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

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.

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.

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

Innocent Heartvoice 296 Reputation points

2024-06-06T13:28:57.7066667+00:00

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?

Jake Zhang-MSFT 6,375 Reputation points Microsoft Vendor

2024-06-12T09:59:37.7166667+00:00

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:

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).

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

Innocent Heartvoice 296 Reputation points

2024-06-13T09:52:01.5566667+00:00

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.

Jake Zhang-MSFT 6,375 Reputation points Microsoft Vendor

2024-06-14T01:41:44.3466667+00:00

Hi @Innocent Heartvoice,

I'm glad to hear that your problem has been solved, and I'm grateful that you've shared your solution.It is my pleasure to provide you with technical support.

Best,

Jake Zhang

Innocent Heartvoice 296 Reputation points

2024-06-14T07:16:02.8+00:00

Yes, Indeed.

I really appreciate your kind support and contribution to this issue. Your efforts have shown a great learning path.
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.

Share via

Exchange 2013 unable to edit the DAG settings

2 answers

Your answer