ECP won't work unless the old Exchange server is on.

Susan Dodds 191

All Exchange servers listed are Exchange 2019.

Long story short, I have a single server environment.

Box A became unusable after a windows update made it so Microsoft Filtering Management Service would not start. No error besides it failed to start.

This caused me to throw together Box B in a hurry. Luckily, migration still works so I can save the mailboxes.

However, when I switch my internal DNS (autodiscover and word.contoso.com) to the new box or disconnect Box A from the network, the ECP becomes unavailable on Box A, Box B, and any computer trying to access the ECP until I turn DNS back to Box A or put Box A back on the network.

I have it so internal and external URL's are the same. The URL's are the same on each box. This has worked going from 2013 to 2016 to 2019.

What am I missing?

2 answers

Jake Zhang-MSFT 4,980 Reputation points Microsoft Vendor

2024-08-26T08:23:33.0866667+00:00
Hi @Susan Dodds,

Welcome to the Microsoft Q&A platform!

It sounds like you are dealing with a complex issue involving your Exchange 2019 servers and DNS configurations. Here are a few steps you can take to troubleshoot and resolve the issue:

Ensure that the DNS records for autodiscover and the mail domain are correctly pointing to Box B. Check both internal and external DNS settings.

Verify the internal and external URLs configured for the Exchange services on Box B. You can do this using the following PowerShell commands on Box B:
Get-ExchangeServer | fl AutoDiscoverServiceInternalUri Get-WebServicesVirtualDirectory | fl InternalUrl,ExternalUrl Get-OwaVirtualDirectory | fl InternalUrl,ExternalUrl Get-EcpVirtualDirectory | fl InternalUrl,ExternalUrl
Ensure that the URLs are correctly set to the new Box B server's address.

Check the health of relevant services on Box B. Ensure that all necessary Exchange services are running:
Get-Service | Where-Object {$_.DisplayName -like "*exchange*"} | Select-Object DisplayName, Status

Ensure that the SSL certificates are properly configured on Box B. If the certificates are not correctly installed, the ECP might fail to load.

Verify the Outlook Anywhere settings and ensure they are set correctly for Box B:
Get-OutlookAnywhere | fl ExternalHostname, InternalHostname

Reset the ECP virtual directory on Box B if necessary. Sometimes, resetting the virtual directory can resolve issues with accessibility:
Remove-EcpVirtualDirectory -Identity "ServerName\ecp (Default Web Site)" New-EcpVirtualDirectory -Server "ServerName"

If you have a DAG setup or any form of mailbox replication, ensure that the databases are properly mounted and replicated on Box B.

Use the Exchange Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) to test the connectivity to Box B. This can help identify any issues with autodiscover or other services.

Double-check the network configuration and firewall settings to ensure there are no blocks or issues preventing proper communication with Box B.

Taking these steps should help you identify and resolve the issue with accessing the ECP on Box B after changing the DNS records.

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

Best,

Jake Zhang
Please sign in to rate this answer.
Susan Dodds 191 Reputation points

2024-08-28T05:52:48.68+00:00

Thank you for the reply.

Verified

The autodiscover cmdlet you give returns blank. The other cmdlets on 2. show the correct URL's. However, when I use this cmdlet, I get the correct autodiscover URL:

Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like "Version 15.2*") -And ($_.ServerRole -Like "*Mailbox*")} | Get-ClientAccessService | Format-Table Name,AutoDiscoverServiceInternalUri -Auto

What needs to be running is running.

Got the SSL installed and configured in the IIS manager backend. Issue is a can't find page/can't connect error generated by the browser, not a certificate/connection error generated by Exchange.

Verified

What is the implication of this? What all happens when that is done? I ask since resetting a primary interface sounds risky and want to know what all that entails.

No DAG.

That thing hates me enough as it is but my setup has worked no problem before.

Haven't needed to make special exceptions in the past.

Couple things of note:

I just realized I forgot to point my pointers in my router to the new IP but that shouldn't effect it when testing it internal since the internal DNS should handle that.

When the old Exchange boots up from a shutdown/reboot now since the windows update, it now takes about a full hour before any OWA/ECP/management shell starts working (used to be under 30 min). It might be possible I'm not allowing enough time to allow for its new lease on life to hand over the reigns but at the same time, I only have so long to wait as it's in production. I haven't had a chance where I can let it set for long periods of time to wait and see.

Jake Zhang-MSFT 4,980 Reputation points Microsoft Vendor

2024-08-30T06:59:21.7866667+00:00

Hi @Susan Dodds ,

Thanks for your response!

It sounds like you’ve already done a lot of troubleshooting! Let’s address your concerns and next steps:

Since the Get-ExchangeServer cmdlet returns blank but the other cmdlets show correct URLs, it seems like the AutodiscoverServiceInternalUri might not be set correctly. The cmdlet you used (Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like "Version 15.2*") -And ($_.ServerRole -Like "*Mailbox*")} | Get-ClientAccessService | Format-Table Name,AutoDiscoverServiceInternalUri -Auto) is correct and should give you the right information. Ensure that the AutodiscoverServiceInternalUri is set correctly on all relevant servers.

Since the issue is a “can’t find page/can’t connect” error, it might be related to DNS or network settings rather than SSL. Double-check your internal DNS settings and ensure that the internal DNS is correctly pointing to Box B.

Resetting the ECP virtual directory can help resolve issues with accessibility. When you reset the virtual directory, it removes the existing configuration and creates a new one with default settings. This can fix misconfigurations but will temporarily disrupt access to the ECP. Here are the steps:

Remove the existing ECP virtual directory:
Remove-EcpVirtualDirectory

Create a new ECP virtual directory:
New-EcpVirtualDirectory

This process should be done during a maintenance window to minimize disruption.

Ensure that your router’s pointers are updated to the new IP. Even though internal DNS should handle it, having the correct pointers can prevent potential issues.

The increased boot time after a Windows update might indicate underlying issues. Check the event logs for any errors or warnings that could give you more insight into what’s causing the delay.

Given your setup and the steps you’ve already taken, it might be beneficial to allow more time for the old Exchange server to fully boot and hand over control. If possible, schedule a maintenance window where you can let the server sit for a longer period to see if it resolves the issue.

Please feel free to contact me for any updates. And if this helps, don't forget to mark it as an answer.

Best,

Jake Zhang

Susan Dodds 191 Reputation points

2024-08-30T12:34:15.3866667+00:00

Thank you for the reply

Not sure what caused it (the planets aligning just right, changing the pointers/forwarders, or some other factor) but it appears to be working now with Box B by itself.

Still some time before I completely remove Box A but Box B can now run without Box A.

It's looking like an Exchange admin account can only function on a specific box if that account's mailbox resides on a database on that server. The mailbox of the admin account I was using hadn't been moved over yet.

Jake Zhang-MSFT 4,980 Reputation points Microsoft Vendor

2024-09-03T07:44:01.8633333+00:00

Hi @Susan Dodds ,

It’s great to hear that Box B is now functioning independently. The issue with the Exchange admin account makes sense—having the mailbox on the same server can be crucial for proper functionality.

Do you have a plan for moving the remaining mailboxes over to Box B?

Jake Zhang-MSFT 4,980 Reputation points Microsoft Vendor

2024-09-04T02:54:27.9866667+00:00

Hi @Susan Dodds ,

Is there any update on this thread? If the issue has been resolved, please mark the helpful replies as answers, this will make answer searching in the forum easier and be beneficial to other community members as well. Thanks for your understanding.

Best,

Jake Zhang

Jake Zhang-MSFT 4,980 Reputation points Microsoft Vendor

2024-09-05T01:28:49.94+00:00

Hi @Susan Dodds ,

Since you haven't replied for a long time, I would like to ask if your problem has been solved. If it has been solved, I hope you can click the "Accept Answer" button on the answer to the useful reply. This will help other users with similar problems in the forum to find solutions to their problems under this answer. Thank you very much for your understanding and improvement of the forum environment! Have a nice day!

Best regards,

Jake Zhang
Sign in to comment

Use comments to ask for clarification, additional information, or improvements to the question.
DURAI, JEYAKUMAR(Admin) 0 Reputation points

2024-08-28T06:13:44.6566667+00:00

Hi,

Did you check if the arbitration mailboxes were moved from Exchange 2016 to 2019? The ECP will not work until they are moved to the Exchange 2019.

https://www.alitajran.com/move-arbitration-mailboxes-in-exchange-server/
Please sign in to rate this answer.
Susan Dodds 191 Reputation points

2024-08-28T06:24:09.89+00:00

Thank you for the reply.

All 7 arbitration mailboxes are on the new server database.
Sign in to comment

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

Share via

ECP won't work unless the old Exchange server is on.

2 answers

Your answer