Exchange 2019 CU12 brand new install ECP redirects to OWA

Brass Contributor


Looking for some help from the experts. 
I'm a little confused, I have an Exchange 2016 that is acting up so we decided to go towards 2019.

Install went fine, Exchange is up and alive services working but from wherever I try to connect (localhost or anywhere within the domain) the same account I use for the old Exchange server to get into the ECP redirects me to OWA on the new server. 

I have no idea why. I checked in IIS if there is a redirect on the backend under ECP there is nothing checked. I imported the certificate from the old Exchange server to the new server, set the bindings to the Go Daddy certificate, nothing works. 

I'm at a big of a loss. The installation is completely brand new. From the old server, I can see the new server, see the database, Exchange Management Shell on the new server works fine.


I have read that recreating the virtual directories on the new Exchange server would / can fix the issue but I am unsure how to do it on the new server. 


I was originally thinking there was some kind of redirect going to OWA but I cannot find it anywhere. And the fact that the old server is working fine I cannot understand where the error is coming from.


Can someone shed some light on what might be causing this issue?


10 Replies

Hi @Audi9112450 


Can you check this

  • If your mailbox is located on the Exchange 2010 Mailbox server, you get the Exchange 2010 ECP by default. You can access the EAC by adding the Exchange version to the URL (which is 15 for both Exchange 2013 and Exchange 2016). For example, to access the EAC through the Client Access (frontend) services on the Mailbox server named Mailbox01, use the following URL: https://Mailbox01/ecp/?ExchClientVer=15.

  • If your mailbox is located on an Exchange 2016 Mailbox server, and you want to access the ECP on the Exchange 2010 Client Access server named CAS01, use the following URL: https://CAS01/ecp/?ExchClientVer=14.



@Andres Bohren 


Hello Anders, 

Thanks for answering.

The old Exchange Databases (the old exchange server) is an Exchange 2016

The new Exchange server is an Exchange 2019

I tried using this URL 


It still redirects

I also tried


Same error


I'm unsure where the redirect is coming from, I'm also very confused as to why everything works properly on the old server

Hello again,
I did a little digging. I'm unsure if it's related but the old exchange server is having replication errors. It seems like it is unable to accept any changes from any DC.





Last attempt @ 2023-04-21 18:45:42 failed, result 8456 (0x2108):
The source server is currently rejecting replication requests.





I'm thinking the root of the old exchange server being problematic lies there but if I can get into the ECP on the new Exchange server I'm going to try to move the mailboxes over to the new Exchange server and just remove Exchange from the old server and just demote it in about a week. The new Exchange server and the FSMO DC are replicating correctly. 


It would explain why all the new users I am creating cannot log on to Exchange OWA. I checked in AD on the offending server and no new users are present. 


Hopefully someone can shed some light as to why it is getting redirected to the OWA page.


For reference here is the error from the FSMO server telling me that the Exchange server is rejecting requests





EventID 1925
Additional Data 
Error value: 
8456 The source server is currently rejecting replication requests.

and from the offending server

EventID 2103
The Active Directory Domain Services database has been restored using an unsupported restoration procedure. 
Active Directory Domain Services will be unable to log on users while this condition persists. As a result, the Net Logon service has paused. 
User Action 
See previous event logs for details.




 My registry on the offending server (the Old Exchange) is indeed

  • Path: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters


I should add these are Hyper-V servers and I believe the Exchange server VHDX files were copied over from one physical server to another physical server last year. Which is when the errors started showing up. It wasn't done with an export it was just copy pasted and we kept the UUID and didn't generate a new one. I am unsure if that is the root cause of this but I'd like to get the redirect on the new server solved so I can move the mailboxes over.



PS: One final thing (again unsure if it's related to the redirect) but when I installed Ex2019 CU12 I was forced to download and install IIS URL Rewrite
Checking in on this anyone might have any insight?
not an expert with Hyper-V, but when the server was copied over, did you keep the same IP and MAC address? im not sure whether this would affect AD sync, but i have seen stranger things happen.
So the IP stayed the same but the MAC surely would have changed since it went from one machine to the next.
I believe the VHDX files were copied over and not exported.
So now I believe the Exchange server (which is a DC, yes I know its not a best practice but it is one) can no longer sync with the other DCs and all the changes that happen with new accounts are not reflected on the exchange server.
So my thinking is if I can connect to the new ECP (without being redirected) I am going to create a new database and just transfer over the mailboxes if they can be transferred. As it stands now what's blocking me is I cannot get into the new ECP it just redirects to OWA.
I have no idea why.
I'm sure everything is related but if I can get into the ECP at least I'm a step closer.
Hello Andres,
I'm going to try this but I read in another forum that changing the value from 4 to 0 renders the server in an unusable state.
I'm going to restore the VM from yesterdays backup and try to do it on the restored version so if something breaks at least I have a working VM
I am replying to this
The above solution does not work. In fact it actually broke exchange completely. The services no longer started and the exchange server had to be restored from the backup.
I wouldn't recommend using that procedure if you are not testing it in a dev environment first.
But, thanks for the try andres at leat it gave me something to try!
I wonder if anyone else has ever had this experience. I don't want to spend $795 CDN if I can do this myself I'm just curious to know if we can make this work without getting a MS support engineer involved (pay per incident).