locked
How to reset Exchange 2013 ECP Admin Page broken RRS feed

  • Question

  • Ok Folks,

    Originally I was getting access to the http://localhost/ecp page but now when I type this URL I get the OWA page and only after flushing the cache on the browser I can see the Exchange Admin login page. But then I try logging in and I get a Page Not Found error!!

    Is there a way to reset the IIS ecp virtual directory or perhaps when I set the Application Pool items to ApllicationPoolIdentity which BPA was compalining about it broke then. To be honest I think it may also be a certificate problem, Im kinda grasping at straws here and need to know how to reinstall the ECP component??

    Ill stop my rambling and let an expert hold my hand please!!

    Jim


    Jim

    Monday, January 28, 2013 3:05 PM

Answers

  • Hi Steve,

    Thanks much I'll give this a go this evening. On another subject are you familiar with the exchange 2013 recieve connector and resetting it. It seems I'm not able to telnet to port 25 from outside and 2013 has a different structure IE front-end and back-end connectors.

    Anyway I'll let you know.

    Jim


    Jim

    • Marked as answer by jim t s Tuesday, January 29, 2013 3:09 PM
    Monday, January 28, 2013 8:59 PM
  • Hi

    You can remove and recreate the ECP virtual directory in the same way that you could in Exchange 2010: http://technet.microsoft.com/en-us/library/ff629372.aspx.

    Then please follow the guidance in this article: http://support.microsoft.com/kb/2778897 

    Cheers, Steve

    Monday, January 28, 2013 3:38 PM

All replies

  • Hi

    You can remove and recreate the ECP virtual directory in the same way that you could in Exchange 2010: http://technet.microsoft.com/en-us/library/ff629372.aspx.

    Then please follow the guidance in this article: http://support.microsoft.com/kb/2778897 

    Cheers, Steve

    Monday, January 28, 2013 3:38 PM
  • Hi Steve,

    Thanks much I'll give this a go this evening. On another subject are you familiar with the exchange 2013 recieve connector and resetting it. It seems I'm not able to telnet to port 25 from outside and 2013 has a different structure IE front-end and back-end connectors.

    Anyway I'll let you know.

    Jim


    Jim

    • Marked as answer by jim t s Tuesday, January 29, 2013 3:09 PM
    Monday, January 28, 2013 8:59 PM
  • On another subject are you familiar with the exchange 2013 recieve connector and resetting it. It seems I'm not able to telnet to port 25 from outside and 2013 has a different structure IE front-end and back-end connectors.

    Hi Jim,

    You can go to https://www.testexchangeconnectivity.com/ to do an Inbound SMTP E-Mail test first.


    Frank Wang
    TechNet Community Support

    Tuesday, January 29, 2013 6:35 AM
  • I ran the test for incoming mail and fails. Seems to me recieve connector is messed up as i have port 25 open on firewall and also if i try to telnet to mail server i do not connect. Do we have a way to rebuild the recieve frontend connector?

    Jim

    Tuesday, January 29, 2013 3:22 PM
  • Steve, I actually said it was answered before confirming the following command works

    Set-EcpVirtualDirectory -Identity "E15MBX\ecp (Exchange Back End)" -WindowsAuthentication $true -FormsAuthentication $false

    I get an error when I run this

    Set-EcpVirtualDirectory : The operation couldn't be performed because object 'E15MBX\ecp (Exchange Back End)' couldn't
    be found on 'WSRV.WCC.JC'.

    It appears it cannot find the Backend ecp? Any Ideas?

    Jim


    Jim

    Tuesday, January 29, 2013 5:13 PM
  • Hi Frank, I had my in and out backwards <grin>. The error is that I cannot send out as I get this error when running the TEC tool outbound test:

    Attempting reverse DNS lookup for IP address 207.194.56.230. Reverse DNS lookup failed.

    Additional Details

     

    A Winsock error occurred while trying to resolve the host. Error: 11004

    Any thoughts?

    Jim



    Jim

    Tuesday, January 29, 2013 5:45 PM
  • On Tue, 29 Jan 2013 17:45:10 +0000, jim t s wrote:
     
    >
    >
    >Hi Frank, I had my in and out backwards <grin>. The error is that I cannot send out as I get this error when running the TEC tool outbound test:
    >
    >Attempting reverse DNS lookup for IP address 207.194.56.230. Reverse DNS lookup failed.
    >
    >
    >
    > Additional Details
    >
    >
    >
    > A Winsock error occurred while trying to resolve the host. Error: 11004
    >
    > Any thoughts?
     
    Only that there really is a PTR record for that IP address:
     
    Non-authoritative answer:
    230.56.194.207.in-addr.arpa canonical name =
    c207.194.56.230.voicemobility.com
     
    That 11004 error is typically "host cannot be resolved".
     
    If you're having a problem with your DNS it would certainly be a
    problem sending e-mail to other domains.
     
    ---
    Rich Matheisen
    MCSE+I, Exchange MVP
     

    --- Rich Matheisen MCSE+I, Exchange MVP
    Wednesday, January 30, 2013 3:36 PM
  • Hi Rick,

    I was finally able to determine sending is working. So it is actually recieve that is the problem. However I ran into another issue whereby I can no longer get to the ECP page. I can get to the login page to enter my admin credentials but hten as soon as I hit enter I get a http 400 page not found page. So cannot get to the EAC ECP page.


    Jim

    Saturday, February 2, 2013 4:40 PM
  • Hi,

    Does anyone know how I can re-create the OWA virtual directory for exchange 2013 in the "exchange back end" site? The powershell command to recreate a the OWA only seems to work in the "default website" 

    When I use the command 

    My problems all bagun when I changed OWA permissions using IIS rather than ECP, I've since removed ECP and OWA VDs from both "default website" and "exchange back end" but the only one I can't recreate using powershell is the OWA in "exchange back end"

    I used this command: New-OwaVirtualDirectory -InternalUrl 'https://mail/owa' -WebSiteName 'Exchange Back End' but it throws an error and the exchange mamnagement event log says exception 0x800700b7 cannot create a file when that file exists. I trawled around and have tried all sorts of workarounds, deleting entries for the owa VD in some file in the system32 folder, deleting temp files in a folder within wwwroot, but I'm tearing my hair out! :( 

    Is it likely I need to re-install the CA role (same server has mailbox and client access)? Other than not being able to access ECP and OWA the server is running well receiving and sending mail to all who connect via Outlook and mobile devices.

    Thanks in advance!


    Dan.


    Monday, April 1, 2013 10:58 PM
  • Did you ever manage to recreate the Exchange Back End directories Dan? I'm in an identical pickle.
    Sunday, April 21, 2013 2:43 PM
  • Hi, try recreating them as in this guide.

    http://www.techieshelp.com/exchange-2013-eac-ecp-blank-screen/

    Sunday, April 21, 2013 2:59 PM
  • Hi, try recreating them as in this guide.

    http://www.techieshelp.com/exchange-2013-eac-ecp-blank-screen/

    This creates the Default Web Site entries, not the back end.

    Sunday, April 21, 2013 4:53 PM
  • I have managed to recreate the back end:


    New-WebApplication -Site "Exchange Back End" -Name owa -PhysicalPath "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa" -ApplicationPool MSExchangeOWAAppPool

     

    New-WebApplication -Site "Exchange Back End" -Name ecp -PhysicalPath "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp" -ApplicationPool MSExchangeECPAppPool

     

    …and then did an IIS reset. Doesn’t come up with the page error on port 444 any more, but simply returns me back to the login page. Does this for both admin & user mailboxes.

     

    I have also forced what I understand to be correct for the default authentication types on OWA & ECP backend directories, as they must match the front-end to work, according to what I’ve read:

     

    Set-owavirtualdirectory -identity "nos-exch2013\owa (Exchange Back End)" -FormsAuthentication:$true

     

    Set-ecpvirtualdirectory -identity "nos-exch2013\ecp (Exchange Back End)" -FormsAuthentication:$true

     

    …but to no avail.

    Any ideas?

    Sunday, April 21, 2013 4:58 PM
  • My original post here was not quite correct - in fact, if you followed it to the letter you would have broken your Exchange Back End beyond repair without deploying new roles to new servers.

    The topology of Exchange 2013 is akin to that of 2003 as in you now have a Front End/Back End relationship;

    Back End = Mailbox role = (Exchange Back End) virtual directories

    Front End = CAS role = (Default Web Site) virtual directories

    Recommended reading: http://blogs.technet.com/b/get-exchangehelp/archive/2013/02/07/managing-exchange-2013-iis-virtual-directories-amp-web-applications.aspx

    There is configuration in Active Directory (CN=Configuration, DC=domain, DC=local, CN=Services, CN=Microsoft Exchange, CN=Name, CN=Administrative Groups, CN=Servers, CN=ServerName, CN=Protocols, CN=HTTP) that is removed when you use the remove-owavirtualdirectory and remove-ecpvirtualdirectory commands. These are 'Front End' commands that shouldn't really work on 'Back End' virtual directories, but unfortunately the do. You cannot use the new-owavirtualdirectory and new-ecpvirtualdirectory commands to recreate the lost AD information of the 'Back End' virtual directories when they are gone.

    I repeat again for good measure: Do NOT use these commands on the Exchange Back End virtual directories or you will break Exchange and not be able to recreate this information using a powershell command. This is the voice of experience and hair loss talking!

    The correct procedure to return your virtual directories to a default state is as follows.



    Remove Default Web Site virtual directories & AD content for owa/ecp:

    remove-owavirtualdirectory -identity "servername\owa (Default Web Site)"

    remove-ecpvirtualdirectory -identity "servername\ecp (Default Web Site)"

    Remove Exchange Back End virtual directories for owa/ecp:

    remove-WebApplication -Site "Exchange Back End" -Name owa

    remove-WebApplication -Site "Exchange Back End" -Name ecp

    Create the new Default Web Site & AD content virtual directories for owa/ecp:

    new-owavirtualdirectory

    new-ecpvirtualdirectory

    Create the new Exchange Back End virtual directories:

    New-WebApplication -Site "Exchange Back End" -Name owa -PhysicalPath "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\owa" -ApplicationPool MSExchangeOWAAppPool

    New-WebApplication -Site "Exchange Back End" -Name ecp -PhysicalPath "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp" -ApplicationPool MSExchangeECPAppPool

    If anyone knows of a way to recreate the AD information for the Back End once lost, please let us know!

    • Edited by spoonwzd Monday, July 22, 2013 8:58 AM Corrected
    • Proposed as answer by spoonwzd Monday, July 22, 2013 8:58 AM
    Sunday, April 21, 2013 9:01 PM
  • It would seem that when in coexistence, you can't use the set-owa/ecp virtual directory commands on the Exchange Back End virtual directories. Instead, use IIS and ensure that Windows Authentication is enabled on both the ecp & owa virtual directories of the Exchange Back End site.

    Hi

    This may have been something related to your environment but that those commands work in 2010/2013 coexistence.

    Cheers, Steve

    Monday, April 22, 2013 7:22 AM
  • I have this exact issue at the moment, lost both ecp and owa.

    I tried what you did spoonwzd and I got my ecp back, owa still got some issues.

    If I do not go to ISS and set to Windows Auth on owa Exchange Back End -> owa login screen is there and when I type in username and password and click log in, the site just "refreshes" (both username and password input field gets blank again) If I type in the wrong password, I will get a message that UN or PW is wrong.

    If I set Windows Auth on owa in Exchange Back End I still get to see the login screen, however when I type in username and password and click log in, I get the "Something went wrong, unexpected error occured" and a sad face smiley. If I type in the wrong UN or PW, I will get a message that its wrong.

    Any Ideas? I did the exact the same as you did Spoonwzd, so I can not fathom why it does not work here!

    Edit: I have also tried this in PowerShell: Set-OwaVirtualDirectory -identity "nfl-dc02\owa" (Exchange Back End) -WindowsAuthentication $true -BasicAuthentication $false -FormsAuthentication $false

    I then get: "The operation couldnt be performed because object "nfl-dc02\owa (Exchange Back End)" couldnt be found on NFL-DC02"....

    • Edited by dqwdq Friday, April 26, 2013 9:33 AM
    Friday, April 26, 2013 9:27 AM
  • Hi did you fix this problem? I have a very similar problem where when I type the ECP admin user and password the page just refreshes. If I out the wrong password it fails as you would expect. Therefore I know its seeing the username and password but its just not logging in.
    Thursday, June 27, 2013 10:13 PM
  • Sadly no. I gave up in the end and reinstalled the whole(!) server.  

    - dqwdq

    Friday, June 28, 2013 7:47 AM
  • I had exactly the same problem, I messed up my certificates. when I try to access ecp I get a smiley face saying something went wrong. I managed to fix this, I know its a little too late for some ones but this reply is for any one who stumbles upon this post with a similar problem.


    on the server running the CAS role open power shell in administrative view and run the following two commands (it is important that you run the set-ecp... commands in power shell, other wise you would get the same error that some users are getting in earlier posts):

    Add-PSSnapin *exchange*

    Set-EcpVirtualDirectory -Identity "YourMailBoxServerName\ecp (Exchange Back End)" -WindowsAuthentication $true -FormsAuthentication $false

    Set-EcpVirtualDirectory -Identity "YourCASserverName\ecp (Default Web Site)" -WindowsAuthentication $true -FormsAuthentication $false

    then start in administrative view exchange management shell. and run the follow two commands (it is important that you run the set-owa.. comands in exchange management shell):

    set-Owavirtualdirectory -identity "YourMailBoxServerName\owa (Exchange Back End)" -WindowsAuthentication $True -Basicauthentication $false -Formsauthentication $false

    set-Owavirtualdirectory -identity "YourCASserverName\owa (Default Web Site)" -WindowsAuthentication $True -Basicauthentication $false -Formsauthentication $false

    run iisreset /noforce, clear the cache of internet explorer and open ecp, you should be able to access it.

    a little explanation:

    when you mess with certificates and authentication the site breaks down along with authentication. to fix this you have to set the windowsauthentication to true and the formsauthentication to false on the ecp on the mailbox server. the ecp virtual directory is on the Exchange back end website in IIS. also you have to make sure that you set the same parameters on the ecp on the CAS server, on the CAS server this virtual directory is found under the default web site website in IIS. 

    why you need to set up the same options on both ecp virtual directory, this is because the ecp virtual directory on the CAS server, which is under default web site is used as a front end and connects to the ecp virtual directory on the Mailbox server, which is under exchange back end website, so they must have the same authentication setup.

    when you run the later command it issues a warning that you have to do the same changes to owa virtual directory. again you have run the set-owa.. command to both CAS server on the Default web site website and to the MailBox server on the exchange back end website. 



    • Proposed as answer by Fayez Eltaha Tuesday, April 15, 2014 6:08 AM
    • Edited by Fayez Eltaha Monday, June 2, 2014 2:27 PM
    Tuesday, April 15, 2014 6:07 AM
  • I had exactly the same problem, I messed up my certificates. when I try to access ecp I get a smiley face saying something went wrong. I managed to fix this, I know its a little too late for some ones but this reply is for any one who stumbles upon this post with a similar problem.


    on the server running the CAS role open power shell in administrative view and run the following two commands (it is important that you run the set-ecp... commands in power shell, other wise you would get the same error that some users are getting in earlier posts):

    Add-PSSnapin *exchange*

    Set-EcpVirtualDirectory -Identity "YourMailBoxServerName\ecp (Exchange Back End)" -WindowsAuthentication $true -FormsAuthentication $false

    Set-EcpVirtualDirectory -Identity "YourCASserverName\ecp (Default Web Site)" -WindowsAuthentication $true -FormsAuthentication $false

    the start in administrative view exchange management shell. and run the follow two commands (it is important that you run the set-owa.. comands in exchange management shell):

    set-Owavirtualdirectory -identity "YourMailBoxServerName\owa (Exchange Back End)" -WindowsAuthentication $True -Basicauthentication $false -Formsauthentication $false

    set-Owavirtualdirectory -identity "YourCASserverName\owa (Default Web Site)" -WindowsAuthentication $True -Basicauthentication $false -Formsauthentication $false

    run iisreset /noforce, clear the cache of internet explorer and open ecp, you should be able to access it.

    a little explanation:

    when you mess with certificates and authentication the site breaks down along with authentication. to fix this you have to set the windowsauthentication to true and the formsauthentication to false on the ecp on the mailbox server. the ecp virtual directory is on the Exchange back end website in IIS. also you have to make sure that you set the same parameters on the ecp on the CAS server, on the CAS server this virtual directory is found under the default web site website in IIS. 

    why you need to set up the same options on both ecp virtual directory, this is because the ecp virtual directory on the CAS server, which is under default web site is used as a front end and connects to the ecp virtual directory on the Mailbox server, which is under exchange back end website, so they must have the same authentication setup.

    when you run the later command it issues a warning that you have to do the same changes to owa virtual directory. again you have run the set-owa.. command to both CAS server on the Default web site website and to the MailBox server on the exchange back end website. 


    Thank you so much. As many others, I changed my certificates via ECP and then I lost access to ECP and OWA locked me out as well. Much appeciate your efforts here.
    Friday, May 30, 2014 11:29 PM
  • hi superjamo,

    I am glad to hear that this post helped you solve your problem. Much appreciate your reply, as this proved that the fix worked for me as well as others. :)


    Monday, June 2, 2014 1:24 PM
  • I met same issue. My resolve steps like below:

    open EMS

    rundisable-mailbox administrator
    enable-mailbox administrator
    https://<exchange server FQDN>/ecp instead of http://localhost/ecp . Then EAC can access now.

    Tuesday, July 29, 2014 5:59 AM
  • The solution is quite simple, just check if the SSL certificate in the front end is the same selected in the backed.

    Step1: Check Certificate in Default Web Site

    IIS Admin/Open Server /Click Default Web site/  In the left panel options check "Bindings" open the binding 443 and Check the SSL Selected.

    Step 2: Make sure the SSL Certificate in the Exchange Back end site matches the certificate in the Default Web site

    Tuesday, January 13, 2015 1:39 AM
  • Go to application pools and  right click MSExchangeOWAAppPool and click Recycling.  Then restart all of the mailbox servers.  
    Thursday, July 23, 2015 1:00 PM
  • extremely thankful.... that work for me perfectly 
    Saturday, March 26, 2016 3:34 PM
  • to recreate back end ecp and owa virtual directories, just type this:

    New-EcpVirtualDirectory -WebSiteName "Exchange Back End" -Server MyServerName


    I did the same mistake, tried this and it also set authentication methods.

    Thanks,

    Eric

    Tuesday, October 3, 2017 11:59 PM