Hi All,

Getting extremely frustrated now with a new Exchange 2013 installation on a Windows Server 2012 VM...

After having a lot of problems with the installation (didn't uninstall visual c++ which caused failure, then needed to delete the AD Microsoft Exchange System Objects group due to permission failures, etc) I've now got a fully installed Exchange server. Still, now I cannot figure out how to fix my next problem - Accessing the EAC/ECP.

I've searched every possible web guide/forum thread and the only one which is the same issue I'm having is this one: http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/89c42771-78c9-4d94-88e5-557320eccc71 

Unfortunately, as you can see in that thread, it is still unresolved. 

Current Issue: trying to access https://localhost/ecp (or any other variation) returns a 404 Not Found.

The error page points the physical path to c:\inetpub\wwwroot\ecp however that folder does not exist. I have tried manually changing the IIS site (Exchange Back End) to point its physical path to C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp which seems to be valid, however it doesn't work...

Not sure what else to do... HELP!

Oli

Hello,

Can you access other VDirs, such as autodiscover and EWS?

Thanks,

Nope. None of them work.

After testing both of those VD's I noticed that like with ecp it all points to c:\inetpub\wwwroot\ecp,autodiscover,EWS,etc so I tried copying the HttpProxy folder for ecp into c:\inetpub\wwwroot\ and tested again and got the following rather than the 404 error:

Server Error in '/' Application.
--------------------------------------------------------------------------------


Configuration Error 
  Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately. 

 Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level.  This error can be caused by a virtual directory not being configured as an application in IIS.

Source Error: 



Line 30:     </system.webServer>
Line 31:     <system.web>
Line 32:         <machineKey validationKey="AutoGenerate,IsolateApps" />
Line 33:         <httpRuntime maxRequestLength="2097151" requestValidationType="Microsoft.Exchange.Management.Security.AdfsRequestValidator" />
Line 34:         <compilation defaultLanguage="c#" debug="false">
  

 Source File:  C:\inetpub\wwwroot\ecp\web.config    Line:  32 

Any ideas?

i suggest to check if you can connect to your exchange server from Exchange powershell toolbox.

I am facing EXACTLY the same problem with a new install of Exchange 2013 on Server 2012. Anyone know of a solution? c:\intepub\wwwroot\ecp folder is missing. I tried copying the contents of the c:\microsoft\exchange...\ecp folder over to it but I get the "Server Error in '/' Application" now.

I can connect via powershell fine, ECP access still not working... (getting to the point of saying fuck Server 2012 and Exchange 2013... Typical buggy MS release will take a year before they fix half the bugs...)

Copy Paste from Powershell (with names edited):

VERBOSE: Connecting to CXX-XX-XXXX2012.CXX-XXXXXE.local.
VERBOSE: Connected to CXX-XX-XXXX2012.CXX-XXXXXE.local.
[PS] C:\Windows\system32>

Thanks for the input so far, anyone experienced this and fixed it? Seems a few people are having the exact same issue I'm having and there is no solution?

Oli

Anyone?

• Proposed as answer by STEPFORDinc Saturday, February 16, 2013 12:26 AM
• Unproposed as answer by STEPFORDinc Saturday, February 16, 2013 12:26 AM

Anyone?

• Proposed as answer by STEPFORDinc Saturday, February 16, 2013 12:26 AM
• Unproposed as answer by STEPFORDinc Saturday, February 16, 2013 12:26 AM

Anyone?

Anyone?

• Proposed as answer by STEPFORDinc Saturday, February 16, 2013 12:26 AM
• Unproposed as answer by STEPFORDinc Saturday, February 16, 2013 12:26 AM

Please try this:

https://%computername%/ecp/?ExchClientVer=15

I ran into the same issue and found http://technet.microsoft.com/en-us/library/jj150562.aspx

• Proposed as answer by Simon_WuMicrosoft contingent staff, Moderator Thursday, February 21, 2013 6:03 AM
• Unproposed as answer by CTSOLI Thursday, February 21, 2013 10:10 AM
• Proposed as answer by AlpineJoe Friday, March 08, 2013 1:06 AM

Please try this:

https://%computername%/ecp/?ExchClientVer=15

I ran into the same issue and found http://technet.microsoft.com/en-us/library/jj150562.aspx

• Proposed as answer by Simon_WuMicrosoft contingent staff, Moderator Thursday, February 21, 2013 6:03 AM
• Unproposed as answer by CTSOLI Thursday, February 21, 2013 10:10 AM
• Proposed as answer by AlpineJoe Friday, March 08, 2013 1:06 AM

Please try this:

https://%computername%/ecp/?ExchClientVer=15

I ran into the same issue and found http://technet.microsoft.com/en-us/library/jj150562.aspx

Please try this:

https://%computername%/ecp/?ExchClientVer=15

I ran into the same issue and found http://technet.microsoft.com/en-us/library/jj150562.aspx

• Proposed as answer by Simon_WuMicrosoft contingent staff, Moderator Thursday, February 21, 2013 6:03 AM
• Unproposed as answer by CTSOLI Thursday, February 21, 2013 10:10 AM
• Proposed as answer by AlpineJoe Friday, March 08, 2013 1:06 AM

Not the answer unfortunately, and reading through that link, doesn't apply to my situation (Separate domain, network and virtual machine to anything else I have).

Unfortunately, due to no solution I have reinstalled and followed a 3rd party step by step to install the joke that is server 2012 and exchange 2013... Really Microsoft, your software has dependencies which your OS doesn't come pre-installed with, and when you install them, installs other software which is incompatible with exchange 2013? This whole build is a joke.

• Marked as answer by CTSOLI Thursday, February 21, 2013 10:13 AM

Not the answer unfortunately, and reading through that link, doesn't apply to my situation (Separate domain, network and virtual machine to anything else I have).

Unfortunately, due to no solution I have reinstalled and followed a 3rd party step by step to install the joke that is server 2012 and exchange 2013... Really Microsoft, your software has dependencies which your OS doesn't come pre-installed with, and when you install them, installs other software which is incompatible with exchange 2013? This whole build is a joke.

• Marked as answer by CTSOLI Thursday, February 21, 2013 10:13 AM

Not the answer unfortunately, and reading through that link, doesn't apply to my situation (Separate domain, network and virtual machine to anything else I have).

Unfortunately, due to no solution I have reinstalled and followed a 3rd party step by step to install the joke that is server 2012 and exchange 2013... Really Microsoft, your software has dependencies which your OS doesn't come pre-installed with, and when you install them, installs other software which is incompatible with exchange 2013? This whole build is a joke.

Not the answer unfortunately, and reading through that link, doesn't apply to my situation (Separate domain, network and virtual machine to anything else I have).

Unfortunately, due to no solution I have reinstalled and followed a 3rd party step by step to install the joke that is server 2012 and exchange 2013... Really Microsoft, your software has dependencies which your OS doesn't come pre-installed with, and when you install them, installs other software which is incompatible with exchange 2013? This whole build is a joke.

• Marked as answer by CTSOLI Thursday, February 21, 2013 10:13 AM

Can you please advise us which link to follow to that 3rd party?

Have a similar case, brand new install of exchange 2013 and as soon as install completed no access to ECP or OWA.

Have tried deleting / creating the virtual directories, still no luck.  Can get web page login for Exchange admin Center, when i login the screen refreshes and displayes login screen again.  If i intentionally put incorrect password it will say invalid username / password.

This solved it for me - Thanks!

• Proposed as answer by Karamosov Wednesday, July 23, 2014 10:18 AM
• Unproposed as answer by Karamosov Wednesday, July 23, 2014 10:18 AM

This solved it for me - Thanks!

• Proposed as answer by Karamosov Wednesday, July 23, 2014 10:18 AM
• Unproposed as answer by Karamosov Wednesday, July 23, 2014 10:18 AM

This solved it for me - Thanks!

This solved it for me - Thanks!

• Proposed as answer by Karamosov Wednesday, July 23, 2014 10:18 AM
• Unproposed as answer by Karamosov Wednesday, July 23, 2014 10:18 AM

Ephaney - Reinstall from scratch and follow step by step to the letter on either of these sites:

http://judeperera.wordpress.com/2012/07/19/step-by-step-guide-for-installing-exchange-server-2013-preview/

http://www.testlabs.se/blog/2012/07/17/exchange-server-2013-preview-complete-guide-of-how-to-perform-the-installation/

Enjoy, I'm still having problems with this piece of crap exchange, outlook refuses to connect haha, worst ever software release (http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/2b000499-d8c5-4415-9dea-7ac67f9cf9d7/)

I had the same problem and if you install the Client Access Role you will be fine. Rerun the install and check the Clinet Access Role. Its stupid that it's not checked but I supposed the idea is that you could point it to another server running it for access but I'm not sure how this would be done.

Love you MS. With out you the would would have alot more Linux and Apple computers and I'd not have a job. 

• Proposed as answer by Aaron Paul Rykhus Sunday, May 05, 2013 10:55 AM

I had the same problem and if you install the Client Access Role you will be fine. Rerun the install and check the Clinet Access Role. Its stupid that it's not checked but I supposed the idea is that you could point it to another server running it for access but I'm not sure how this would be done.

Love you MS. With out you the would would have alot more Linux and Apple computers and I'd not have a job. 

• Proposed as answer by Aaron Paul Rykhus Sunday, May 05, 2013 10:55 AM

I had the same problem and if you install the Client Access Role you will be fine. Rerun the install and check the Clinet Access Role. Its stupid that it's not checked but I supposed the idea is that you could point it to another server running it for access but I'm not sure how this would be done.

Love you MS. With out you the would would have alot more Linux and Apple computers and I'd not have a job. 

I had the same problem and if you install the Client Access Role you will be fine. Rerun the install and check the Clinet Access Role. Its stupid that it's not checked but I supposed the idea is that you could point it to another server running it for access but I'm not sure how this would be done.

Love you MS. With out you the would would have alot more Linux and Apple computers and I'd not have a job. 

• Proposed as answer by Aaron Paul Rykhus Sunday, May 05, 2013 10:55 AM

Something you might try if you haven't fixed it yet.......  The "default web site" ecp virtual folder should point to , in my case, C:\Program Files\Microsoft\Exchange Server\v15\FrontEnd\HttpProxy\ecp".  Once you are sure it points there, check the security of the virtual directory.  It should have SSL enabled, if not, you'll get the "page can't be found error".  Also check the bindings of the default web site port 443.  Make sure it has your 3rd party certificate associated with it.  On the Backend site, check the bindings and make sure it's port 444 is associated with your 3rd party certificate also with the correct names in it.

If that still doesn't work, drop to the Exchange Command Prompt and type get-ecpvirtualdirectory to check and make sure it's recognized and correct.  If it's okay and you still can't access it, remove it and recreate it.  remove-ecpvirtualdirectory -Identity "yourservername\ecp (default web site)" (don't forget the quotes).  If you copy and paste, check my spelling.......  Then recreate it, new-ecpvirtualdirectory , no switches on this one.  It automatically creates it in the default web site.

You can do the OWA directory the same way.

Hope this helps.

I forgot to mention but the Backend site is the one that points to "C:\inetpub\wwwroot"

• Edited by Kimberlain Tuesday, April 16, 2013 5:19 PM
• Proposed as answer by Kimberlain Tuesday, April 16, 2013 5:20 PM
• Unproposed as answer by Kimberlain Tuesday, April 16, 2013 5:20 PM
• Proposed as answer by Kimberlain Tuesday, April 16, 2013 5:22 PM

Something you might try if you haven't fixed it yet.......  The "default web site" ecp virtual folder should point to , in my case, C:\Program Files\Microsoft\Exchange Server\v15\FrontEnd\HttpProxy\ecp".  Once you are sure it points there, check the security of the virtual directory.  It should have SSL enabled, if not, you'll get the "page can't be found error".  Also check the bindings of the default web site port 443.  Make sure it has your 3rd party certificate associated with it.  On the Backend site, check the bindings and make sure it's port 444 is associated with your 3rd party certificate also with the correct names in it.

If that still doesn't work, drop to the Exchange Command Prompt and type get-ecpvirtualdirectory to check and make sure it's recognized and correct.  If it's okay and you still can't access it, remove it and recreate it.  remove-ecpvirtualdirectory -Identity "yourservername\ecp (default web site)" (don't forget the quotes).  If you copy and paste, check my spelling.......  Then recreate it, new-ecpvirtualdirectory , no switches on this one.  It automatically creates it in the default web site.

You can do the OWA directory the same way.

Hope this helps.

I forgot to mention but the Backend site is the one that points to "C:\inetpub\wwwroot"

• Edited by Kimberlain Tuesday, April 16, 2013 5:19 PM
• Proposed as answer by Kimberlain Tuesday, April 16, 2013 5:20 PM
• Unproposed as answer by Kimberlain Tuesday, April 16, 2013 5:20 PM
• Proposed as answer by Kimberlain Tuesday, April 16, 2013 5:22 PM

Something you might try if you haven't fixed it yet.......  The "default web site" ecp virtual folder should point to , in my case, C:\Program Files\Microsoft\Exchange Server\v15\FrontEnd\HttpProxy\ecp".  Once you are sure it points there, check the security of the virtual directory.  It should have SSL enabled, if not, you'll get the "page can't be found error".  Also check the bindings of the default web site port 443.  Make sure it has your 3rd party certificate associated with it.  On the Backend site, check the bindings and make sure it's port 444 is associated with your 3rd party certificate also with the correct names in it.

If that still doesn't work, drop to the Exchange Command Prompt and type get-ecpvirtualdirectory to check and make sure it's recognized and correct.  If it's okay and you still can't access it, remove it and recreate it.  remove-ecpvirtualdirectory -Identity "yourservername\ecp (default web site)" (don't forget the quotes).  If you copy and paste, check my spelling.......  Then recreate it, new-ecpvirtualdirectory , no switches on this one.  It automatically creates it in the default web site.

You can do the OWA directory the same way.

Hope this helps.

I forgot to mention but the Backend site is the one that points to "C:\inetpub\wwwroot"

Something you might try if you haven't fixed it yet.......  The "default web site" ecp virtual folder should point to , in my case, C:\Program Files\Microsoft\Exchange Server\v15\FrontEnd\HttpProxy\ecp".  Once you are sure it points there, check the security of the virtual directory.  It should have SSL enabled, if not, you'll get the "page can't be found error".  Also check the bindings of the default web site port 443.  Make sure it has your 3rd party certificate associated with it.  On the Backend site, check the bindings and make sure it's port 444 is associated with your 3rd party certificate also with the correct names in it.

If that still doesn't work, drop to the Exchange Command Prompt and type get-ecpvirtualdirectory to check and make sure it's recognized and correct.  If it's okay and you still can't access it, remove it and recreate it.  remove-ecpvirtualdirectory -Identity "yourservername\ecp (default web site)" (don't forget the quotes).  If you copy and paste, check my spelling.......  Then recreate it, new-ecpvirtualdirectory , no switches on this one.  It automatically creates it in the default web site.

You can do the OWA directory the same way.

Hope this helps.

I forgot to mention but the Backend site is the one that points to "C:\inetpub\wwwroot"

• Edited by Kimberlain Tuesday, April 16, 2013 5:19 PM
• Proposed as answer by Kimberlain Tuesday, April 16, 2013 5:20 PM
• Unproposed as answer by Kimberlain Tuesday, April 16, 2013 5:20 PM
• Proposed as answer by Kimberlain Tuesday, April 16, 2013 5:22 PM

My test server has been up for about a month since install. Seems to have worked fine for a while, one day come to use imap application, I realize that half of Ex2013 services aren't running. Long story short after some troubleshooting I have realized all of my virtual directories have gone. As no Virtual directories - no powershell either !! Shocking, and all of this without anything being done to the server, not even a reboot... I would be very worried installing this on customer's network following this experience... 

Just trying to use some setup switches to see if I can recover it, nothing important there, but would like to know in case this happens in production environment...

Running setup.exe on the Exchange 2013 media (ISO), checking the Client Access Role check box, and clicking install resolved it for me. Never installed the CAS role. So that's all it was for me.

Related threads:

http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/a07fa978-81cf-4722-b222-eaa981e680d2

http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/5728970c-d885-4763-bde9-7176ada414b5

http://social.technet.microsoft.com/Forums/en-US/exchangesvradminlegacy/thread/34ed5347-90f9-4ab7-91c3-9665f8ace432

http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/89c42771-78c9-4d94-88e5-557320eccc71

No funciona ojo no hacerlo

Something you might try if you haven't fixed it yet.......  The "default web site" ecp virtual folder should point to , in my case, C:\Program Files\Microsoft\Exchange Server\v15\FrontEnd\HttpProxy\ecp".  Once you are sure it points there, check the security of the virtual directory.  It should have SSL enabled, if not, you'll get the "page can't be found error".  Also check the bindings of the default web site port 443.  Make sure it has your 3rd party certificate associated with it.  On the Backend site, check the bindings and make sure it's port 444 is associated with your 3rd party certificate also with the correct names in it.

If that still doesn't work, drop to the Exchange Command Prompt and type get-ecpvirtualdirectory to check and make sure it's recognized and correct.  If it's okay and you still can't access it, remove it and recreate it.  remove-ecpvirtualdirectory -Identity "yourservername\ecp (default web site)" (don't forget the quotes).  If you copy and paste, check my spelling.......  Then recreate it, new-ecpvirtualdirectory , no switches on this one.  It automatically creates it in the default web site.

You can do the OWA directory the same way.

Hope this helps.

I forgot to mention but the Backend site is the one that points to "C:\inetpub\wwwroot"

I "sort of" solved the access to admin page problem with this URL: https://%computername%/ecp/?ExchClientVer=15 ... at least I got to the correct sign-in page ... then it 404'd on me.

The Fun Part:

You can use the Get-EcpVirtualDirectory command to find the URL for your ECP site ... (if you are someone other than me) ... my version of Exchange Powershell apparently doesn't come with this cmdlet (even  after I run update) ... so I just get reds.

And a huge "BRAVO" to Microsoft for finally getting rid of the GUI in favor of powershell! Thank God! Really - it used to take me a week or two to figure out a new version of Exchange ... now it will only take 6 or 7 months! 

Seriously ... I like powershell for scripting ... but everything has it's place ... I don't want to be forced to learn it in order to confidently run Exchange on our network. I am afraid to know which parts of powershell I'll need to learn in an emergency situation, and how long that will delay a solution to whatever problems may arise ... and it's killing my desire for the product fast.

This URL worked for me thank you https://%computername%/ecp/?ExchClientVer=15

I also found that https://{Servername}/ecp/default.aspx also give me access to the EAC. 

• Edited by Richard Emmanuel Wednesday, August 21, 2013 1:12 PM spelling correction
• Proposed as answer by EwenW Wednesday, August 20, 2014 10:07 AM

This URL worked for me thank you https://%computername%/ecp/?ExchClientVer=15

I also found that https://{Servername}/ecp/default.aspx also give me access to the EAC. 

• Edited by Richard Emmanuel Wednesday, August 21, 2013 1:12 PM spelling correction
• Proposed as answer by EwenW Wednesday, August 20, 2014 10:07 AM

This URL worked for me thank you https://%computername%/ecp/?ExchClientVer=15

I also found that https://{Servername}/ecp/default.aspx also give me access to the EAC. 

• Edited by Richard Emmanuel Wednesday, August 21, 2013 1:12 PM spelling correction
• Proposed as answer by EwenW Wednesday, August 20, 2014 10:07 AM

Mine had been working, then suddenly just stopped working on one of my Client Access servers. After searching around for an answer with nothing really working, I tried running the iisreset command. It worked, and now I can login to EAC again from this server. So if you haven't already tried, and if Exchange 2013 isn't really screwed up, iisreset may do the trick.

The solution for me was the following:

Make a Backup from C:\Windows\System32\inetsrv\config\applicationHost.config

Copy the latest applicationHost.config backup file from 

C:\inetpub\history\...  

to

C:\Windows\System32\inetsrv\config

restart or start the www and was service

(World Wide Web Publishing Service, Windows Process Activation Service)

Check in IIS the running state from the Exchange Back End website

• Edited by Oliver Rother Tuesday, October 08, 2013 7:51 AM

The solution for me was the following:

Make a Backup from C:\Windows\System32\inetsrv\config\applicationHost.config

Copy the latest applicationHost.config backup file from 

C:\inetpub\history\...  

to

C:\Windows\System32\inetsrv\config

restart or start the www and was service

(World Wide Web Publishing Service, Windows Process Activation Service)

Check in IIS the running state from the Exchange Back End website

• Edited by Oliver Rother Tuesday, October 08, 2013 7:51 AM

The solution for me was the following:

Make a Backup from C:\Windows\System32\inetsrv\config\applicationHost.config

Copy the latest applicationHost.config backup file from 

C:\inetpub\history\...  

to

C:\Windows\System32\inetsrv\config

restart or start the www and was service

(World Wide Web Publishing Service, Windows Process Activation Service)

Check in IIS the running state from the Exchange Back End website

• Edited by Oliver Rother Tuesday, October 08, 2013 7:51 AM

Not actually solution but I installed my Exchange 2013 to Windows Server 2012 and all worked fine untill I installed RDP Gateway to the same server. After that none of the vDirs work and cant Access Exchange management console either. Services are running thou.

Please try this:

https: // %computername% /ecp/?ExchClientVer=15

This solved it for my testinstallation:

W2012R2 RTM Test VM Server

W2012 Datacenter Virtual Machine - ISS Webserver, FTP-Server, Exchange Server

I reinstalled the server twice and Exchange about 5 times...

Thank you :)

I had a similar issue, it turned out to be sub-folder permissions on the Exchange directory. I was able to use AccessEnum from SysInternals to compare with a working server. Bit tedious, but fixed the issue.

The reason https://%computername%/ecp/?ExchClientVer=15 is required is because the account you are using the mailbox is still on previous version of Exchange.

Secondly if you still get 404 after that - it means that you do not have any mailbox server role on Exchange 2013 and you need to have that for you to be able to successfully access EAC

You should never install RDP Gateway on the same box as Exchange.  This is not recomended you will have CERT issues for sure as well as traffic confilcts

CKS

I came across this page because I was having this issue on my deployment as well. Everything worked initially, but I noticed when I was trying to later deploy the CA Role to the same server Exchange and IIS are running on that I couldn't start the Default Website because it said that another process was using the port.

I ran netstat -aon | find ":443" to determine the process using it and saw it was PID 4 "SYSTEM". So going back to IIS I examined the bindings on Default Website. I discovered there were 3 different bindings to both port 80 and 443. I removed the other bindings and left the binding to 80 and 443 that was to '*'.

Clicked Start on Default Website and everything is back up and running again. I figured I would post this in case someone else runs into this problem and my scenario matches theirs.

Same.

I installed Exchange 2013 on a Server 2012 VM.  This was a fresh environment meant as a testing ground for development - so new AD DC, etc, with no previous version of Exchange on the machine.

Seems crazy that Client Access Role would not be auto-checked.

Had the same issue in  2013. Unable to connect to /ECP, however, I have separate CAS and Mailbox servers. Initially, I was trying to connect to the Mailbox server since this was the first server that I configured.

I can, however, connect to /ECP  when I specify https://casservername/ecp.

Another idea, which did work for me before I installed the CAS server, is specify the secure port number like this

https://2013mailboxserver:444/ecp.

You got the port number if you go to IIS and look up the configuration for the ECP web folder .

We've had similar issue with logging into /ecp and /owa but remotely - access ECP or OWA by going through a hostname pointing to another server as well as locally. Resolution in our case was to remove Exchange servers from the Domain Admins group. I don't remember why they've had to be added there in the first place, something to do with E2013 installation.

Also make sure that on IIS level Default Virtual Directory has Basic Authentication and Windows Authentication enabled for local access of ecp and owa.

And/Or try to run a cmdlet

set-owavirtualdirectory - id "blahblah" -FormsBased(checksmpelling):$true -BasicAuthentication:$false

In our case ECP uses OWA FormsBased Authentication - UserName - domain typed out.

We have CAS and MB roles installed on each server though.

• Edited by reanor Friday, January 10, 2014 3:02 PM

We've had similar issue with logging into /ecp and /owa but remotely - access ECP or OWA by going through a hostname pointing to another server as well as locally. Resolution in our case was to remove Exchange servers from the Domain Admins group. I don't remember why they've had to be added there in the first place, something to do with E2013 installation.

Also make sure that on IIS level Default Virtual Directory has Basic Authentication and Windows Authentication enabled for local access of ecp and owa.

And/Or try to run a cmdlet

set-owavirtualdirectory - id "blahblah" -FormsBased(checksmpelling):$true -BasicAuthentication:$false

In our case ECP uses OWA FormsBased Authentication - UserName - domain typed out.

We have CAS and MB roles installed on each server though.

• Edited by reanor Friday, January 10, 2014 3:02 PM

We've had similar issue with logging into /ecp and /owa but remotely - access ECP or OWA by going through a hostname pointing to another server as well as locally. Resolution in our case was to remove Exchange servers from the Domain Admins group. I don't remember why they've had to be added there in the first place, something to do with E2013 installation.

Also make sure that on IIS level Default Virtual Directory has Basic Authentication and Windows Authentication enabled for local access of ecp and owa.

And/Or try to run a cmdlet

set-owavirtualdirectory - id "blahblah" -FormsBased(checksmpelling):$true -BasicAuthentication:$false

In our case ECP uses OWA FormsBased Authentication - UserName - domain typed out.

We have CAS and MB roles installed on each server though.

• Edited by reanor Friday, January 10, 2014 3:02 PM

I was able to both produce install failure, and also, after tweaking, an install success but with subsequent EAC failure.

Run your server with reduced physical memory and paging file size and you will see these symptoms.  Even in this condition I was able to use the URL for the EAC that has the subfolder info: hxxps://serverfqdn/ecp/?ExchClientVer=15 to get to the EAP, but it didn't function well.

The solution was to install and run the product on a node with sufficient resources.

Hello, I found the solution by going to:
IIS Manager->yourserver->sites->Exchange Back End->ecp...
When you click on ecp, you can see the actions side panel where browse application two links are given, click on Browse * :444(https) and you have the exchange admin center open.

Thanks

@ QasimAzam,

This is only access to to same user just! Its not showing the correct ecp which manage other configurations.

Its really embarrassing the stuff to work like this.

 

No always.. I have run into that problem, but currently my mailbox is on 2013 and still have the issue..

Yep - of COURSE you need to install Client Access (smacks self in forehead) for this to work.

I ran setup again and now all is well.  Thanks Aaron!

@CTSOLI:  I think that your frustration level will go WAY DOWN on the day that you learn that the right way to fix a Microsoft server is NEVER to start hacking and moving stuff.  If it doesn't work, you/ve missed something simple.  Maybe it was dumb of MS to not put in that little hint "You won't be able to use your ECP until Client Access Role is installed", but it was a necessary step - and obvious in retrospect.

Before I hired my MCSE Exchange admins, my guys fought with MS servers like this all the time.  In the end, the Pros never even try these hacks.  Just a word of mentor-ship from someone who recognizes this level of frustration and knows the answer.

In my case, the virtual directory/default website had no certificate bindings because I had deleted them through the 2013 Exchange Administrative Center.  The certificate that I installed did not support multiple SANs which was causing client connect issues with internal Outlook 2013 clients.  I purchased a different cert to support my two domains mail.domain.com and autodiscover.domain.com (external domains).  When I deleted the original mail.domain.com cert, it broke the ecp VD.   Doh!   Interestingly, it didn't break anything else that wasn't already "broken". 

Good call and thanks.   I'm back in the  EAC.   One note, it now throws a Cert warning when entering via "localhost" (the default link).   Ignore it and all is good.

Off to fixing my original problem...

Thanks...

Hello,

What you need to run Exchange Administrative Center is to install CAS which's the proxy to MBX and everything will work fine .

Hello there!

i don't normally post in these sort's of Forums for i feel like i'm still a newbie! but i had the EXACT same issue's as you where experiencing. (missing ecp folder, 404 error etc etc)

After reading about the "Client Access Role" i assumed this was not installed as part of the initial Exchange 2013 setup, so i decided to re-run the installer file (Didnt uninstall my original install, just ran the setup.exe file for exchange 2013 again)

This prompted me to install the "Client Access Role" as an additional server role, once i selected this and let the installer run, i logged straight onto the ECP page without the error of 404.0 and all is working!.

I thought i would post this in case if anyone else has the same issues! all i did was an original install of Exchange 2013 on a virtual server (Server 2012r2) and found the 404.0 error when loading the admin center. Re-run the setup file and it had the option of "Client Access Role" once this was installed this resolved my issue for me.

Hope this helps!

Regards

Michael Bacon 

In my Case CAS was installed, but got the same issue due to my mailbox being on an 2010 exchange server. 

Only way around it that worked was this:

Here's what i did that fixed this.

set-ecpvirtualdirectory -Identity "ecp (default web site)" -windowsauthentication $true -formsauthentication $false

do an IISreset

log in to your ecp with https://servername/ecp/?exchclientver=15

• Proposed as answer by JJBotha Thursday, December 11, 2014 7:27 AM

In my Case CAS was installed, but got the same issue due to my mailbox being on an 2010 exchange server. 

Only way around it that worked was this:

Here's what i did that fixed this.

set-ecpvirtualdirectory -Identity "ecp (default web site)" -windowsauthentication $true -formsauthentication $false

do an IISreset

log in to your ecp with https://servername/ecp/?exchclientver=15

• Proposed as answer by JJBotha Thursday, December 11, 2014 7:27 AM

In my Case CAS was installed, but got the same issue due to my mailbox being on an 2010 exchange server. 

Only way around it that worked was this:

Here's what i did that fixed this.

set-ecpvirtualdirectory -Identity "ecp (default web site)" -windowsauthentication $true -formsauthentication $false

do an IISreset

log in to your ecp with https://servername/ecp/?exchclientver=15

• Proposed as answer by JJBotha Thursday, December 11, 2014 7:27 AM

In my Case CAS was installed, but got the same issue due to my mailbox being on an 2010 exchange server. 

Only way around it that worked was this:

Here's what i did that fixed this.

set-ecpvirtualdirectory -Identity "ecp (default web site)" -windowsauthentication $true -formsauthentication $false

do an IISreset

log in to your ecp with https://servername/ecp/?exchclientver=15

This was my issue as well. Thanks for posting this. I'd tried nearly ever other suggestion and this was the kicker. Must be a an issue with exchange 2010 co-existence.

I was wondering if you ever got this resolved? I'm on CU7 and just ran into this problem.  If I login the frontend page, it will just refresh.  If I intentionally log in incorrectly it will error out; however, the next time typing in the correct credential brings up EAC.

Unfreaking believable.  You don't specify roles so instead of installing all of them, they secretly don't install one that lets you configure it.  Beyond belief, thanks for the answer.

Hi There Oli

I had the exact same issue as you, my powershell would not run and i could not load the ECP, throwing up an http 404 error.

After looking around i found that quite a few people had the same issue, but i found (for me) it really was quite a simple fix. 

It seems Exchange Pre Req didn't install a few features or even let you know about them! the two required are the following.

Add Feaures & Roles

Server Roles --> Web Server (IIS) --> Web Server --> Application Development --> .NET Extensibility 4.5 & ASP.NET 4.5

Once i installed both features my admin page loaded and my Powershell worked fine :)

Was scratching my head for a while on this but really a simple fix! hope this helps anyone else who has the same issue.

Regards

Mike

Even I am facing the same issue.
Did you got the solution for it?

Adding .net feature and default SSL, if removed is useful. Mine was causing an issue due back end binding removal. created a new SSL from ISS and binding for 444

https://support.microsoft.com/en-us/kb/2779694?wa=wsignin1.0

HI,

Did you check that on IIS--> backend--> bindings

on there, https on port 444 should be exist & the ssl cert ( If available) should be attached on this.