Exchange ecp error 400

The issue

Last week our IT deparment had a big problem with Outlook Web App (OWA) on Microsoft Exchange 2013. It was not working anymore and it was inaccessible for all our 500+ employees. However, all other services kept on working normally (ActiveSync, Outlook Anywhere, etc.).

Since I’m not managing this Microsoft Exchange 2013 environment anymore, I wasn’t fully aware of this problem, until the IT Department asked me to take a look at it, in the hope that I could fix it.

In the end, we managed to fix this problem without too many complications. I have to thank my colleague and partner in crime, Chris Petit (@christiaanpetit) for his insights and tips. He was a great help during this ordeal at work. 

The problem

Our IT department changed the authentication option on the ECP virtual directory and suddenly Outlook web access was not working anymore. All our employees working in the field use Outlook Web App to communicate. You can just imagine how frustrating this can be for customers. 

On smartphone devices, colleagues could see the nice Outlook Web App login page of Microsoft Exchange 2013, only to find out that it doesn’t work. After providing their (correct) credentials, they received this error:

“Outlook web app didn’t initialize. If the problem continues please contact your helpdesk.

Couldn’t find a base theme (folder name=base)”

In the eventviewer we saw a lot of these error messages:

With this informationin mind, we concluded that some web technology and perhaps some webservice was at fault.

The solution

The solution to this problem is a neat one.

On the internet we read blogposts telling us that we needed to recreate the Outlook Web App (OWA) and Exchange Control Panel (ECP) virtual directories. 

We did do this, following the instructions from this blogpost:

But… recreating the virtual directories did not solve anything for us.

Then, my colleague Chris Petit (@christiaanpetit), pointed me to this blogpost:

At first, I was sceptical about this solution because it was tested for Microsoft Exchange 2010 only. Since there is little known about Exchange 2013, I gave this solution a shot and, luckily, it worked flawlessly.

If you encounter this problem (bad request, http 400 error) on your Exchange 2013 infrastructure, these are the steps that you can follow to fix it.

Note:The powershell scripts are not mentioned anywhere in the official Technet documentation.
The powershell scripts are only mentioned on several blogposts regarding Microsoft Exchange 2010.
    

1. Login to your Exchange 2013 CAS server
2. Start the Exchange Management Shell
       
3. Navigate to your Exchange 2013 binaries location, for example:

            C:Program FilesMicrosoftExchange ServerV15Bin

4. Execute the UpdateCas.ps1 Windows PowerShell script and wait a few moments.
   This script will rebuild your OWA interface.
       
5. If you haven’t executed UpdateConfigFiles.ps1 , now is a good time. Execute it.
   It looks like you need to execute this Windows PowerShell script, after each cumulative update of Microsoft Exchange 2013 to keep everything working smooth.

Conclusion 

After each installation of a cumulative update for Exchange 2013, remember to execute both the UpdateCas.ps1 and UpdateConfigFiles.ps1 Windows PowerShell scripts.

It will save you a lot of trouble, troubleshooting errors with OWA and ECP. 

Special thanks goes to my colleague and partner in crime, Chris Petit (@christiaanpetit) for his insights and tips. He was a great help during this ordeal at work.

Источник: http://blogs.dirteam.com/blogs/sergio/archive/2014/01/21/7370.aspx

Introduction

I have managed our Exchange 2013 environment for 6 months in 2013. This Highly Available (HA) Microsoft Exchange 2013 setup was designed and installed by Dave Stork.

I have installed various cumulative updates on this setup and almost everything went without a hitch.

Since then, I moved on.

The issue

Last week our IT deparment had a big problem with Outlook Web App (OWA) on Microsoft Exchange 2013. It was not working anymore and it was inaccessible for all our 500+ employees. However, all other services kept on working normally (ActiveSync, Outlook Anywhere, etc.).

Since I’m not managing this Microsoft Exchange 2013 environment anymore, I wasn’t fully aware of this problem, until the IT Department asked me to take a look at it, in the hope that I could fix it.

In the end, we managed to fix this problem without too many complications. I have to thank my colleague and partner in crime, Chris Petit (@christiaanpetit) for his insights and tips. He was a great help during this ordeal at work.

The problem

Our IT department changed the authentication option on the ECP virtual directory and suddenly Outlook web access was not working anymore. All our employees working in the field use Outlook Web App to communicate. You can just imagine how frustrating this can be for customers.

On smartphone devices, colleagues could see the nice Outlook Web App login page of Microsoft Exchange 2013, only to find out that it doesn’t work. After providing their (correct) credentials, they received this error:

“Outlook web app didn’t initialize. If the problem continues please contact your helpdesk.

Couldn’t find a base theme (folder name=base)”

In the eventviewer we saw a lot of these error messages:

With this informationin mind, we concluded that some web technology and perhaps some webservice was at fault.

The solution

The solution to this problem is a neat one.

On the internet we read blogposts telling us that we needed to recreate the Outlook Web App (OWA) and Exchange Control Panel (ECP) virtual directories.

We did do this, following the instructions from this blogpost:

Re-create OWA virtual Directories in Exchange 2013

But… recreating the virtual directories did not solve anything for us.

Then, my colleague Chris Petit (@christiaanpetit), pointed me to this blogpost:

http://www.faultserver.com/q/answers-exchange-server-2010-owa-couldnt-find-a-base-theme-268697.html

At first, I was sceptical about this solution because it was tested for Microsoft Exchange 2010 only. Since there is little known about Exchange 2013, I gave this solution a shot and, luckily, it worked flawlessly.

If you encounter this problem (bad request, http 400 error) on your Exchange 2013 infrastructure, these are the steps that you can follow to fix it.

Note:
The powershell scripts are not mentioned anywhere in the official Technet documentation.
The powershell scripts are only mentioned on several blogposts regarding Microsoft Exchange 2010.

1. Login to your Exchange 2013 CAS server
2. Start the Exchange Management Shell
3. Navigate to your Exchange 2013 binaries location, for example:C:Program FilesMicrosoftExchange ServerV15Bin
4. Execute the UpdateCas.ps1 Windows PowerShell script and wait a few moments.
   This script will rebuild your OWA interface.
5. If you haven’t executed UpdateConfigFiles.ps1 , now is a good time. Execute it.
   It looks like you need to execute this Windows PowerShell script, after each cumulative update of Microsoft Exchange 2013 to keep everything working smooth.

Conclusion

After each installation of a cumulative update for Exchange 2013, remember to execute both the UpdateCas.ps1 and UpdateConfigFiles.ps1 Windows PowerShell scripts.

It will save you a lot of trouble, troubleshooting errors with OWA and ECP.

Special thanks goes to my colleague and partner in crime, Chris Petit (@christiaanpetit) for his insights and tips. He was a great help during this ordeal at work.