exchange 2013 owa error 400 Bad Request (Network Steve Forum)

exchange 2013 owa error 400 Bad Request

When I try to access OWA from any client I get an HTTP 400 Bad Request error.
Accessing ECP works fine.
I have recreated the virtual directories - still no good.
IE returns this error.
Firefox says "Firefox has detected that the server is redirecting the request for this address in a way that will never complete".

What is wrong?

March 30th, 2014 11:31pm

Is this purely new Exchange 2013 installation or is it coexistence with older Exchange version?

My guess is that you have both Exchange 2010 and 2013 in the same domain and your entering username/password for an Exchange 2010 account?

If so please run this command in new Exchange 2013 from Exchange powershell:

New-Mailbox name newadmin userPrincipalName newadmin@yourdomain.com Database "Your mailbox database

Grant this new user the following membership:

Domain Admins
Schema Admins
Enterprise Admins
Organization Management
Now try to login with this new user id in ECP

let us know the output so that we can proceed further

Please mark as helpful if you find my contribution useful or as an answer if it does answer your question.That will encourage me - and others - to take time out to help you.
Regards,

Free Windows Admin Tool Kit Click here and download it now

March 31st, 2014 4:07am

It is now a purely Exchange 2013 installation.

When it was first installed, there was an older Exchange installation.
All users have been migrated to Exchange 2013, and the older version of Exchange was completely uninstalled and the AD was cleaned up by a Microsoft tech.
There are no older Exchange accounts anymore.

March 31st, 2014 4:16am

Did you try to use another browser like IE? Will it get the same problem? You may also try to reinstall the certificate for OWA and try.

Proposed as answer by Jacky Yau Monday, March 31, 2014 4:46 AM
Marked as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, April 08, 2014 7:07 AM
Unmarked as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, April 08, 2014 7:08 AM

Free Windows Admin Tool Kit Click here and download it now

March 31st, 2014 4:45am

Did you try to use another browser like IE? Will it get the same problem? You may also try to reinstall the certificate for OWA and try.

Proposed as answer by Jacky Yau Monday, March 31, 2014 4:46 AM
Marked as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, April 08, 2014 7:07 AM
Unmarked as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, April 08, 2014 7:08 AM

March 31st, 2014 4:45am

Did you try to use another browser like IE? Will it get the same problem? You may also try to reinstall the certificate for OWA and try.

Proposed as answer by Jacky Yau Monday, March 31, 2014 4:46 AM
Marked as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, April 08, 2014 7:07 AM
Unmarked as answer by Simon_WuMicrosoft contingent staff, Moderator Tuesday, April 08, 2014 7:08 AM

Free Windows Admin Tool Kit Click here and download it now

March 31st, 2014 4:45am

I have tried both IE and Firefox - both fail.

I have tried re-installing the OWA certificate - no good

March 31st, 2014 4:48am

As a part of testing could you please create a new user in Exchange 2013 and try accessing owa and see the results

Free Windows Admin Tool Kit Click here and download it now

March 31st, 2014 4:50am

I have created a new user in Exchange 2013.
I get the same error when trying with that user.
ECP works fine with existing users and the new user.

March 31st, 2014 4:57am

Hey there

Can you brief me about the OS is used where Mailbox server role is hosted .

Thanks

~Dex

Free Windows Admin Tool Kit Click here and download it now

March 31st, 2014 5:23am

Windows Server 2012 R2 Standard

March 31st, 2014 5:59am

Hi Sathish,

I suggest clearing all cookies and history from the browser, and adding our OWA rul into the Compatibility View Settings for testing.

Please also check the detailed error code from IIS, some like 400.1, 400.2 etc.

More details in the following KB:

The HTTP status code in IIS 7.0, IIS 7.5, and IIS 8.0

http://support.microsoft.com/kb/943891

I recommend to use IE browser, even if the IE has the same issue in this case.

Thanks

Mavis

Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

Free Windows Admin Tool Kit Click here and download it now

March 31st, 2014 6:20am

The only codes in the logs are 200 and 302

March 31st, 2014 8:23am

Hey there

I found the solution to your problem, follow these steps properly:

Login to your Exchange 2013 CAS server
Start the Exchange Management Shell
Navigate to your Exchange 2013 binaries location, for example:
C:\Program Files\Microsoft\Exchange Server\V15\Bin\
Execute the UpdateCas.ps1 Windows PowerShell script and wait a few moments. This script will rebuild your OWA interface.
If you havent 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.

Feel free to revert back for further queries

Thanks

~Dex

Free Windows Admin Tool Kit Click here and download it now

March 31st, 2014 10:13am

I have done that but it does not fix the problem.

When I look in ECP at the Virtual Directories it shows in the list:
owa (Default Web Site) servername OWA Version 15.0 (Build 516.32)

but when I select it and see the details it shows:
Outlook Web App version: Exchange2010

March 31st, 2014 10:20pm

Hi,

About the IIS code that you provided, 200 (OK. The client request has succeeded) and 302 (Object moved). It seems the problem is, the object isn't existed in the right location.

According to your description in the last reply, I found that we still connect OWA 2010. It seems that the user mailbox still in Exchange 2010 server.

Since you said before, "it is now a purely Exchange 2013 installation" and "all users have been migrated to Exchange 2013, and the older version of Exchange was completely uninstalled and the AD was cleaned up by a Microsoft tech". It seems there still some Exchange 2010 object exists in our org. Please use ADSIEidt to verify whether there is any Exchange 2010 object. If has, please delete them.

Please make a full back up before deleting the objects.

If it is still not working after performing the deleting.

1. Please try to re-build the OWA Virtual Directory for testing.

2. Please try to move the user mailbox to another database for testing, some problems will solved by itself automatically.

Thanks

Mavis

Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

Free Windows Admin Tool Kit Click here and download it now

April 1st, 2014 3:42am

I have re-built the OWA directory.

I cannot find any Exchange 2010 objects.

April 1st, 2014 5:10am

Hi,

Before we go any further, I would like to clarify the issue:

Whats the entire error message when we access OWA? Please help to capture a screenshot and post the entire error message.
How many CAS servers do we have? All servers OWA cant login?
Is the issue occur on OWA internal URL or external URL?
Do we public OWA through TMG?
How did you recreate the OWA VDs? Did you recreate VDs both for the Default WEB Site and Exchange Back End?
Do we enable redirect on the OWA? If so, please remove the redirect and make sure the authentication method obly have WindowsAuthentication and BasicAuthentication enabled. Then check if we can login OWA.

To narrow down this issue, please try the following steps:

Remove redirect for OWA from IIS manager if enabled, then try to login OWA;

http://support.microsoft.com/kb/2020943

Run the updatecas.ps1 on all the CAS servers after recreate the VDs and perform IISrest; then try to login OWA again;
Add the below registry keys:

Domain Controllers:

1) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Value name: MaxTokenSize

Type: REG_DWORD

Value data: 65534

Radix: Decimal

Exchange Client Access Servers and Exchange Mailbox Servers (Exchange 2010 & Exchange 2013)

1) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

Value name: MaxTokenSize

Type: REG_DWORD

Value data: 65534

Radix: Decimal

2) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\w3svc\parameters

Value name: MaxClientRequestBuffer

Value type: REG_DWORD

Value data: 32768

Radix: Decimal

3) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

Value name: MaxFieldLength

Value type: REG_DWORD

Value data: 65534

Radix: Decimal

4) HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters

Value name: MaxRequestBytes

Value type: REG_DWORD

Value data: 16777216

Radix: Decimal

For more inforamtion about the registry changes, we can refer to this article:

Title: "HTTP 400 - Bad Request (Request Header too long)" error in Internet Information Services (IIS)

Link: http://support.microsoft.com/kb/2020943

If issue persist, please also read this article and let me know the whole error code we encountered: http://support.microsoft.com/kb/943891.

Please refer to above infromation and if anything is uncelar, feel free to let me know.

Free Windows Admin Tool Kit Click here and download it now

April 2nd, 2014 7:37am

I have tried all that and still no good.

The error is "HTTP 400 Bad Request" https://servername/owa/auth.owa

This error comes after the username and password are entered in the login page. The login page for OWA shows perfectly.

Edited by lt8x7 Thursday, April 03, 2014 3:01 AM

April 3rd, 2014 3:00am

I have tried all that and still no good.

The error is "HTTP 400 Bad Request" https://servername/owa/auth.owa

This error comes after the username and password are entered in the login page. The login page for OWA shows perfectly.

Edited by lt8x7 Thursday, April 03, 2014 3:01 AM

Free Windows Admin Tool Kit Click here and download it now

April 3rd, 2014 3:00am

I have tried all that and still no good.

The error is "HTTP 400 Bad Request" https://servername/owa/auth.owa

This error comes after the username and password are entered in the login page. The login page for OWA shows perfectly.

Edited by lt8x7 Thursday, April 03, 2014 3:01 AM

April 3rd, 2014 3:00am

Hi,

I understand the issue persists after perform above steps. Could you please take a few miniutes to answer the questions, thanks.

How many CAS servers do we have? All servers OWA cant login?
How many user affected? All users cant login OWA or some/single user?
Is the issue occur on OWA internal URL or external URL?
How did you recreate the OWA VDs(please make sure redirect is disabled for both web site)? Did you recreate VDs both for the Default WEB Site and Exchange Back End?

Meanwhile, to know the detailed error code like:

400.1 - Invalid Destination Header.
400.2 - Invalid Depth Header.
400.3 - Invalid If Header.

Please reproduce this issue first, then check the IIS log file under the following path. By default, IIS log file locates at %windir%\inetpub\logs\LogFiles\W3SVC1. Please notice:

The affected user account we use to login OWA but failed with HTTP 400 Bad Request;
The approximate time the issue happened.

Then from the IIS log file location, we can find IIS logs named with daily base like U_ex140403, we can open the file when we repro the issue, search in the log for the affected user accounts login entry and notice the time which meet the time we repro the issue, then copy affected users login information, it will contains the error code and other information.

Free Windows Admin Tool Kit Click here and download it now

April 3rd, 2014 8:43am

1. Only 1 CAS server. OWA cannot login.
2. All users cannot login.
3. Both internal and external URL
4. Recreated both VD with Exchange Shell commands.

The error page shows "The webpage cannot be found".

Logs entry below.

04-03 09:24:20 10.2.2.12 POST /owa/auth.owa - 443 domain\user 10.2.2.109 Mozilla/5.0+(Windows+NT+6.3;+ARM;+Trident/7.0;+Touch;+rv:11.0)+like+Gecko https://mydomain.com.au/owa/auth/logon.aspx?url=https%3a%2f%2fmydomain.com.au%2fowa%2f&reason=0 302 0 64 15
2014-04-03 09:24:20 10.2.2.12 POST /owa/auth.owa - 443 domain\user 10.2.2.109 Mozilla/5.0+(Windows+NT+6.3;+ARM;+Trident/7.0;+Touch;+rv:11.0)+like+Gecko https://mydomain.com.au/owa/auth/logon.aspx?url=https%3a%2f%2fmydomain.com.au%2fowa%2f&reason=0 302 0 0 15
2014-04-03 09:24:20 10.2.2.12 GET /owa/ - 443 domain\user 10.2.2.109 Mozilla/5.0+(Windows+NT+6.3;+ARM;+Trident/7.0;+Touch;+rv:11.0)+like+Gecko https://mydomain.com.au/owa/auth/logon.aspx?url=https%3a%2f%2fmydomain.com.au%2fowa%2f&reason=0 302 0 0 906
2014-04-03 09:24:23 10.2.2.12 POST /Microsoft-Server-ActiveSync/default.eas User=user&DeviceId=5FABC1850D9C53F1DF151E2F44C54D73&DeviceType=WindowsMail&Cmd=Ping 443 domain\user 10.2.2.193 WindowsMail/17.5.9600.20413 - 200 0 64 180024

April 3rd, 2014 9:35am

Hi,

From the IIS log, I only find 302 code but didnt find error code include 400 like before, could you please check the IIS log and post the OWA(not ActiveSync login entry) related login entry with error code shows 400? Thanks for your time and patience.

Meanwhile, is Exchange Back End virtual directory binding on port 443 or 444? The Default Web Site should use 443 and Back End use web site us 444. Also check the OWA authentication method, please list the authentication by command:

Get-OWAVirtualDirectory Server Ex2013_CAS_server | fl *authentication*

We should set the authentication as the below:

Get-OWAvirtualdirectory -Server Ex2013_CAS_server | set-OWAvirtualdirectory -windowsAuthentication $False -BasicAuthentication $True -FormsAuthentication $True

Then perform iisreset and try to access OWA again.

Free Windows Admin Tool Kit Click here and download it now

April 4th, 2014 8:11am

The bindings are 443 for default web and 444 for backend.

Authentication is as you say.

I found the correct errors in the log:
2014-04-04 08:53:16 10.2.2.13 HEAD /OAB/547821c7-f990-4143-b6f8-08876c04acad/oab.xml - 443 - 10.2.2.193 Microsoft+BITS/7.7 - 401 2 5 60
2014-04-04 08:53:19 10.2.2.13 HEAD /OAB/547821c7-f990-4143-b6f8-08876c04acad/oab.xml - 443 - 10.2.2.193 Microsoft+BITS/7.7 - 401 2 5 46
2014-04-04 08:53:21 10.2.2.13 HEAD /OAB/547821c7-f990-4143-b6f8-08876c04acad/oab.xml - 443 - 10.2.2.193 Microsoft+BITS/7.7 - 401 2 5 62
2014-04-04 08:53:23 10.2.2.13 HEAD /OAB/547821c7-f990-4143-b6f8-08876c04acad/oab.xml - 443 - 10.2.2.193 Microsoft+BITS/7.7 - 401 2 5 0
2014-04-04 08:53:23 10.2.2.13 HEAD /OAB/547821c7-f990-4143-b6f8-08876c04acad/oab.xml - 443 DOMAIN\user 10.2.2.193 Microsoft+BITS/7.7 - 404 0 0 125
2014-04-04 08:53:25 10.2.2.12 HEAD /OAB/547821c7-f990-4143-b6f8-08876c04acad/oab.xml - 443 - 10.2.2.193 Microsoft+BITS/7.7 - 401 2 5 78
2014-04-04 08:53:28 10.2.2.12 HEAD /OAB/547821c7-f990-4143-b6f8-08876c04acad/oab.xml - 443 - 10.2.2.193 Microsoft+BITS/7.7 - 401 2 5 62
2014-04-04 08:53:30 10.2.2.12 HEAD /OAB/547821c7-f990-4143-b6f8-08876c04acad/oab.xml - 443 - 10.2.2.193 Microsoft+BITS/7.7 - 401 2 5 62

April 4th, 2014 8:59am

Hi,

The login entry is OAB related not OWA, please double confirm and then repro the issue, collect the IIS log about the OWA related log entry with 400 error code to clarify. Thanks for your time.

Free Windows Admin Tool Kit Click here and download it now

April 5th, 2014 7:02am

There are no entries in the log files for this attempt to login.

An incorrect password will result in a log entry.
A correct login will not result in a log entry. The login is successful, but the destination page is somehow incorrect/missing. After a successful login (with an error 400), if I then go to the ECP page it shows successfully without asking again for a login.

Edited by lt8x7 Monday, April 07, 2014 12:16 AM

April 5th, 2014 7:35am

There are no entries in the log files for this attempt to login.

Edited by lt8x7 Monday, April 07, 2014 12:16 AM

Free Windows Admin Tool Kit Click here and download it now

April 5th, 2014 7:35am

There are no entries in the log files for this attempt to login.

Edited by lt8x7 Monday, April 07, 2014 12:16 AM

April 5th, 2014 7:35am

Hi,

In my experience, whether we login OWA successful or not, it will be recorded in IIS log(IIS log should be enabled on the CAS server). Please double confirm and use another user account to login OWA to check.

Moreover, since you mentioned that the OWA login is successful, but the destination page is somehow incorrect/missing. After a successful login with an error 400(please double confirm error 400 is occured when we successful login or before or after), we can go to ECP page. So please take some screenshots of the detailed steps when we login OWA, for example, we open OWA login page, enter the credential, click sign in, login successful but error 400 occurred, and the destination page which is incorrect/missing, then we go to ECP page. Please let me know detailed information about above steps.

Thanks for your time.

Free Windows Admin Tool Kit Click here and download it now

April 8th, 2014 8:07am

I have tried 3 different users and all fail to show in the logs.

I get the standard OWA login page when I go to https://myserverowa
I enter the username and password and get the 400 error - the URL showing for the error page is https://myserver/owa/auth.owa
if I then go to the address bar in IE and type https://myserver/ecp it takes me straight to the ECP page without needing to login.

April 8th, 2014 8:18am

Hi,

Since the issue persists, please help to verify the following steps have been done strictly:

Redirect have been removed on OWA virtual directory;
Updatecas.ps1 script have been run;
The registries have been configured on all the DCs, Exchange 2010&2013 Client Access Servers and Exchange Mailbox Servers;

Title: Bad Request (Request Header too long)" error in Internet Information Services (IIS)

Link: http://support.microsoft.com/kb/2020943

4. The authentication of OWA and ECP match.

After all above steps, please schedule a property time to reboot all the servers, then check the issue again. also, please let me know the OWA and ECP VDs configuration:

1) Get-ECPVirtualDirectory | fl

2) Get-OWAVirtualDirectory | fl

Free Windows Admin Tool Kit Click here and download it now

April 9th, 2014 8:12am

Again I can confirm that Steps 1-4 have completed correctly.

VD configurations:

[PS] C:\Windows\system32>Get-ECPVirtualDirectory | fl

RunspaceId                      : e35f5cca-d591-4a35-ad3a-495b59a521be
AdminEnabled                    : True
OwaOptionsEnabled               : True
Name                            : ecp (Default Web Site)
InternalAuthenticationMethods   : {Basic, Fba}
MetabasePath                    : IIS://OtterEx64-3/W3SVC/1/ROOT/ecp
BasicAuthentication             : True
WindowsAuthentication           : False
DigestAuthentication            : False
FormsAuthentication             : True
LiveIdAuthentication            : False
AdfsAuthentication              : False
DefaultDomain                   :
GzipLevel                       : High
WebSite                         : Default Web Site
DisplayName                     : ecp
Path                            : C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\ecp
ExtendedProtectionTokenChecking : None
ExtendedProtectionFlags         : {}
ExtendedProtectionSPNList       : {}
AdminDisplayVersion             : Version 15.0 (Build 516.32)
Server                          : OTTEREX64-3
InternalUrl                     : https://xxx/ecp
ExternalUrl                     : https://xxx/ecp
ExternalAuthenticationMethods   : {Fba}
AdminDisplayName                :
ExchangeVersion                 : 0.10 (14.0.100.0)
DistinguishedName               : CN=ecp (Default Web Site),CN=HTTP,CN=Protocols,CN=OTTEREX64-3,CN=Servers,CN=Exchange
                                  Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Otterson
                                  Associates,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=sydney,DC=otterson
Identity                        : OTTEREX64-3\ecp (Default Web Site)
Guid                            : 96c71884-a85c-455f-a61b-b9b1c7f87187
ObjectCategory                  : sydney.otterson/Configuration/Schema/ms-Exch-ECP-Virtual-Directory
ObjectClass                     : {top, msExchVirtualDirectory, msExchECPVirtualDirectory}
WhenChanged                     : 26/01/2014 16:52:25
WhenCreated                     : 24/01/2014 11:17:32
WhenChangedUTC                  : 26/01/2014 5:52:25
WhenCreatedUTC                  : 24/01/2014 0:17:32
OrganizationId                  :
OriginatingServer               : OTTEREX64-3
IsValid                         : True
ObjectState                     : Changed

[PS] C:\Windows\system32>Get-OWAVirtualDirectory | fl

RunspaceId                                          : e35f5cca-d591-4a35-ad3a-495b59a521be
DirectFileAccessOnPublicComputersEnabled            : True
DirectFileAccessOnPrivateComputersEnabled           : True
WebReadyDocumentViewingOnPublicComputersEnabled     : True
WebReadyDocumentViewingOnPrivateComputersEnabled    : True
ForceWebReadyDocumentViewingFirstOnPublicComputers : False
ForceWebReadyDocumentViewingFirstOnPrivateComputers : False
WacViewingOnPublicComputersEnabled                  : True
WacViewingOnPrivateComputersEnabled                 : True
ForceWacViewingFirstOnPublicComputers               : False
ForceWacViewingFirstOnPrivateComputers              : False
RemoteDocumentsActionForUnknownServers              : Block
ActionForUnknownFileAndMIMETypes                    : ForceSave
WebReadyFileTypes                                   : {.xlsx, .pptx, .docx, .xls, .rtf, .ppt, .pps, .pdf, .dot, .doc}
WebReadyMimeTypes                                   : {application/vnd.openxmlformats-officedocument.presentationml.pre
                                                      sentation, application/vnd.openxmlformats-officedocument.wordproc
                                                      essingml.document, application/vnd.openxmlformats-officedocument.
                                                      spreadsheetml.sheet, application/vnd.ms-powerpoint,
                                                      application/x-mspowerpoint, application/vnd.ms-excel,
                                                      application/x-msexcel, application/msword, application/pdf}
WebReadyDocumentViewingForAllSupportedTypes         : True
WebReadyDocumentViewingSupportedMimeTypes           : {application/msword, application/vnd.ms-excel,
                                                      application/x-msexcel, application/vnd.ms-powerpoint,
                                                      application/x-mspowerpoint, application/pdf, application/vnd.open
                                                      xmlformats-officedocument.wordprocessingml.document, application/
                                                      vnd.openxmlformats-officedocument.spreadsheetml.sheet, applicatio
                                                      n/vnd.openxmlformats-officedocument.presentationml.presentation}
WebReadyDocumentViewingSupportedFileTypes           : {.doc, .dot, .rtf, .xls, .ppt, .pps, .pdf, .docx, .xlsx, .pptx}
AllowedFileTypes                                    : {.rpmsg, .xlsx, .xlsm, .xlsb, .vstx, .vstm, .vssx, .vssm, .vsdx,
                                                      .vsdm, .tiff, .pptx, .pptm, .ppsx, .ppsm, .docx...}
AllowedMimeTypes                                    : {image/jpeg, image/png, image/gif, image/bmp}
ForceSaveFileTypes                                  : {.swf, .spl, .dir, .dcr}
ForceSaveMimeTypes                                  : {Application/x-shockwave-flash, Application/octet-stream,
                                                      Application/futuresplash, Application/x-director}
BlockedFileTypes                                    : {.vsmacros, .msh2xml, .msh1xml, .ps2xml, .ps1xml, .mshxml,
                                                      .gadget, .mhtml, .psc2, .psc1, .msh2, .msh1, .aspx, .xml, .wsh,
                                                      .wsf...}
BlockedMimeTypes                                    : {application/x-javascript, application/javascript,
                                                      application/msaccess, x-internet-signup, text/javascript,
                                                      application/xml, application/prg, application/hta,
                                                      text/scriplet, text/xml}
RemoteDocumentsAllowedServers                       : {}
RemoteDocumentsBlockedServers                       : {}
RemoteDocumentsInternalDomainSuffixList             : {}
FolderPathname                                      :
Url                                                 : {}
LogonFormat                                         : FullDomain
ClientAuthCleanupLevel                              : High
LogonPagePublicPrivateSelectionEnabled              : False
LogonPageLightSelectionEnabled                      : False
FilterWebBeaconsAndHtmlForms                        : UserFilterChoice
NotificationInterval                                : 120
DefaultTheme                                        :
UserContextTimeout                                  : 60
ExchwebProxyDestination                             :
VirtualDirectoryType                                :
OwaVersion                                          : Exchange2010
ServerName                                          : OTTEREX64-3
InstantMessagingCertificateThumbprint               :
InstantMessagingServerName                          :
RedirectToOptimalOWAServer                          : True
DefaultClientLanguage                               : 0
LogonAndErrorLanguage                               : 0
UseGB18030                                          : False
UseISO885915                                        : False
OutboundCharset                                     : AutoDetect
GlobalAddressListEnabled                            : True
OrganizationEnabled                                 : True
ExplicitLogonEnabled                                : True
OWALightEnabled                                     : True
DelegateAccessEnabled                               : True
IRMEnabled                                          : True
CalendarEnabled                                     : True
ContactsEnabled                                     : True
TasksEnabled                                        : True
JournalEnabled                                      : True
NotesEnabled                                        : True
RemindersAndNotificationsEnabled                    : True
PremiumClientEnabled                                : True
SpellCheckerEnabled                                 : True
SearchFoldersEnabled                                : True
SignaturesEnabled                                   : True
ThemeSelectionEnabled                               : True
JunkEmailEnabled                                    : True
UMIntegrationEnabled                                : True
WSSAccessOnPublicComputersEnabled                   : True
WSSAccessOnPrivateComputersEnabled                  : True
ChangePasswordEnabled                               : True
UNCAccessOnPublicComputersEnabled                   : True
UNCAccessOnPrivateComputersEnabled                  : True
ActiveSyncIntegrationEnabled                        : True
AllAddressListsEnabled                              : True
RulesEnabled                                        : True
PublicFoldersEnabled                                : True
SMimeEnabled                                        : True
RecoverDeletedItemsEnabled                          : True
InstantMessagingEnabled                             : True
TextMessagingEnabled                                : True
ForceSaveAttachmentFilteringEnabled                 : False
SilverlightEnabled                                  : True
PlacesEnabled                                       : False
AnonymousFeaturesEnabled                            : True
IntegratedFeaturesEnabled                           : True
DisplayPhotosEnabled                                : True
SetPhotoEnabled                                     : True
PredictedActionsEnabled                             : False
UserDiagnosticEnabled                               : False
AllowOfflineOn                                      : AllComputers
SetPhotoURL                                         :
InstantMessagingType                                : None
Exchange2003Url                                     :
FailbackUrl                                         :
LegacyRedirectType                                  : Silent
Name                                                : owa (Default Web Site)
InternalAuthenticationMethods                       : {Basic, Fba}
MetabasePath                                        : IIS://OtterEx64-3/W3SVC/1/ROOT/owa
BasicAuthentication                                 : True
WindowsAuthentication                               : False
DigestAuthentication                                : False
FormsAuthentication                                 : True
LiveIdAuthentication                                : False
AdfsAuthentication                                  : False
DefaultDomain                                       :
GzipLevel                                           : High
WebSite                                             : Default Web Site
DisplayName                                         : owa
Path                                                : C:\Program Files\Microsoft\Exchange
                                                      Server\V15\FrontEnd\HttpProxy\owa
ExtendedProtectionTokenChecking                     : None
ExtendedProtectionFlags                             : {}
ExtendedProtectionSPNList                           : {}
AdminDisplayVersion                                 : Version 15.0 (Build 516.32)
Server                                              : OTTEREX64-3
InternalUrl                                         : https://xxx/owa
ExternalUrl                                         : https://xxx/owa
ExternalAuthenticationMethods                       : {Fba}
AdminDisplayName                                    :
ExchangeVersion                                     : 0.10 (14.0.100.0)
DistinguishedName                                   : CN=owa (Default Web
                                                      Site),CN=HTTP,CN=Protocols,CN=OTTEREX64-3,CN=Servers,CN=Exchange
                                                      Administrative Group (FYDIBOHF23SPDLT),CN=Administrative
                                                      Groups,CN=Otterson Associates,CN=Microsoft
                                                      Exchange,CN=Services,CN=Configuration,DC=sydney,DC=otterson
Identity                                            : OTTEREX64-3\owa (Default Web Site)
Guid                                                : d2239696-109d-470b-86a2-b3a55f82a524
ObjectCategory                                      : sydney.otterson/Configuration/Schema/ms-Exch-OWA-Virtual-Director
                                                      y
ObjectClass                                         : {top, msExchVirtualDirectory, msExchOWAVirtualDirectory}
WhenChanged                                         : 5/02/2014 10:01:19
WhenCreated                                         : 5/02/2014 9:46:39
WhenChangedUTC                                      : 4/02/2014 23:01:19
WhenCreatedUTC                                      : 4/02/2014 22:46:39
OrganizationId                                      :
OriginatingServer                                   : OTTEREX64-3
IsValid                                             : True
ObjectState                                         : Changed

[PS] C:\Windows\system32>

Edited by lt8x7 Wednesday, April 09, 2014 9:32 AM

April 9th, 2014 9:18am

Again I can confirm that Steps 1-4 have completed correctly.

VD configurations:

[PS] C:\Windows\system32>Get-ECPVirtualDirectory | fl

[PS] C:\Windows\system32>Get-OWAVirtualDirectory | fl

[PS] C:\Windows\system32>

Edited by lt8x7 Wednesday, April 09, 2014 9:32 AM

Free Windows Admin Tool Kit Click here and download it now

April 9th, 2014 9:18am

Again I can confirm that Steps 1-4 have completed correctly.

VD configurations:

[PS] C:\Windows\system32>Get-ECPVirtualDirectory | fl

[PS] C:\Windows\system32>Get-OWAVirtualDirectory | fl

[PS] C:\Windows\system32>

Edited by lt8x7 Wednesday, April 09, 2014 9:32 AM

April 9th, 2014 9:18am

Hi,

Please modify the OWA URL to check the issue:

Set-OWAVirtualDirectory -Identity OTTEREX64-3\owa (Default Web Site) InternalUrl https://OTTEREX64-3.domain.com/owa ExternalUrl $null

Note: Please replace The "OTTEREX64-3.domain.com" to your CAS server "OTTEREX64-3" FQDN, like OTTEREX64-3.contoso.com.

Then use the internal Url to access OWA from internal machine.

Free Windows Admin Tool Kit Click here and download it now

April 10th, 2014 9:04am

I edited the URLs in my post for security reasons.
Both Internal and External URLs are correct and both work for ECP.

The problem is NOT the URLs.

If you look at the post you will see that it says
OWA version: Exchange2010
but also says
AdminDisplayVersion : Version 15.0 (Build 516.32)

How do I fix this?

April 10th, 2014 10:07am

Hi,

The OWA version displays Exchange 2010 but AdminDisplayVersion displays Exchange 2013 issue is a bug in Exchange 2013, the issue is under investigation currently.

Free Windows Admin Tool Kit Click here and download it now

April 11th, 2014 9:12am

Is a result of the bug that OWA doesn't work?

April 11th, 2014 9:59am

This sometimes happens if the request goes to the wrong site on a multi-site server.

When you go to

https://servername/owa

and see the logon page, look at the browser address bar. Has the 'servername' part changed to something else? If you try to login, and see the 400 error, look again at the address bar - has the 'servername' part changed now?

Free Windows Admin Tool Kit Click here and download it now

April 11th, 2014 11:39am

No, the server name does not change.

The page which returns the error is https://servername/owa/auth.owa

April 11th, 2014 1:09pm

Hi,

The bug is not related to our issue, thanks for your understanding.

Free Windows Admin Tool Kit Click here and download it now

April 12th, 2014 7:13am

Have you found the IIS logs that show the 400 response yet? I can't see them in the above posts, but they must be somewhere. If they're not in any log file in the W3SVC1 folder, can they be found in any other W3SVCx folder? If the server's returned it, it must have logged it.

April 14th, 2014 11:00am

No, I cannot find the 400 error in any log. I have checked them all and this event is not logged!

Free Windows Admin Tool Kit Click here and download it now

April 14th, 2014 12:24pm

You use the word 'event'. You probably know this, but you shouldn't be looking in the event logs for this. I just thought I ought to mention it.

If the 400 response definitely isn't in your IIS logs, then something else may be returning it, like your router's internal administration web site. It's quite common for requests to be sent (because of incomplete internal DNS configuration) to the public Ip address from an internal location, which often means that your router ends up trying to deal with it, instead of an internal server.

The usual culprit, though, is a different web site on the same server. The host header name sent by the client makes the server direct it to a different site at the same host.

April 14th, 2014 1:54pm

Hi,

Please also check if IIS log is enabled on the CAS server, if not, please enable it. Then reproducet the issue, from the IIS log file location at %windir%\inetpub\logs\LogFiles\W3SVC1, chcek the latest IIS log about the 400 error code for OWA login.

Free Windows Admin Tool Kit Click here and download it now

April 15th, 2014 10:28am

IIS logging is enabled.

I have reproduced the error many times and the 400 error is not in the IIS logs.

April 16th, 2014 6:58am

The ECP website works perfectly.

The OWA website does not.

The name resolution / routing is the same for both.

Free Windows Admin Tool Kit Click here and download it now

April 16th, 2014 7:01am

Hi,

ECP and OWA is not the same, so ECP works fine don't mean OWA will work normal. since we can't find the 400 error for OWA login from the IIS log, it's a little hard for our troubleshooting since we don't know the exact error code. In previous posts, we have tried many steps however issue persists, I will do more further research to see if any addtional steps can be done.

April 16th, 2014 10:56am

And if we can't see the 400 entries from the logs, we can't even be sure that they're coming from the correct server. I can't imagine any configuration where a web site would record successful requests, but not record 400's. There is no option in the logging configuration section to turn off logging for specific codes.

Free Windows Admin Tool Kit Click here and download it now

April 16th, 2014 11:15am

There is only one server in the network.

April 16th, 2014 11:36am

But you will probably have more web servers than you realise. Nearly everything connected to the LAN nowadays can be administered by HTTP. Now, it's unlikely (but not impossible) that your logon requests are being POSTed to (for example) the administration web site of one of your printers. But having it POSTed to your router, firewall, or proxy server, is actually quite common. And the 400 status is exactly how they would react.

Free Windows Admin Tool Kit Click here and download it now

April 16th, 2014 11:43am

But ......
The OWA login page is correctly presented. Something goes wrong with the login, the credentials are accepted, but the post login functions fail.

It is https://servername/owa/auth.owa that fails

April 16th, 2014 12:09pm

Yes, it's the destination that the login page is posting the credentials to that is returning the 400 error. And due to name/IP address resolution issues, it's quite possible for it to be a different address that the logon page is coming from. It's quite a puzzle, and it really is important to find out where the 400 is coming from. It's only the fact that the 400's don't appear in your IIS log file that makes it look like they may be coming from something else. There really is no reason why they shouldn't appear in the same log as everything else. The 400 doesn't mean that IIS has crashed, or anything like that. It just means that whatever is receiving the data thinks it looks so strange that it refuses to do anything with it.

In the case of OWA, it nearly always means that due to a host-header name configuration, or a conflict in the TCP listening addresses for the various sites (perhaps you have an http->https redirect on the OWA site, but have HTTPS listening on a different IP address to HTTP), it is getting posted to a different site on the same server. The ECP site, for example, or some other site that may have been added. But if this were the case, you'd see the 400 in THEIR logs (e.g. in the W3SVC2 or W3SVC3 folder), but you haven't found them there. Of course, you may have logging turned off for the other sites, which would be an unfortunate coincidence.

Free Windows Admin Tool Kit Click here and download it now

April 16th, 2014 12:32pm

Hi,

Since we don't know other OWA related configuration and error code 400 not exist in the IIS log, it's a little hard for our troubleshooting. Also, as this is the only one server in the network, it's a product environment or just for test? If it's just for test, I recommend to reinstall the Exchange server.

April 17th, 2014 10:21am

Hi,

Do we have any further updates on this issue?

Free Windows Admin Tool Kit Click here and download it now

April 22nd, 2014 9:18am

It is a production server. It is the only server n the domain.

The fault still exists.

Nothing you have suggested has made any difference.

April 22nd, 2014 9:44am

Hi,

I know this is the only server in your production environment, thus we can reinstall the server. Since we have tried many steps but the issue persists, and we can't find IIS log about the OWA login failure entry, please use the following methods:

1. open ADUC, click "View->Advanced Feature", navigate to one affected user account(All user affected and both internal and external?), check its properties.

2. On Security tab, click Advanced, make sure the "Inherited permission" is enabled; if not enable it;

3. Then navigate to System->AdminADHolder, use above method to make the "inherited permission" is enabled.

4. Reset IIS, then try to login OWA again.

Also, could you please let me know the OWA URL and create a test account(account name and password) for me? I can test from my side as well. Thanks for your understanding.

Edited by Eric ZouZouMicrosoft contingent staff, Moderator Wednesday, April 23, 2014 10:02 AM

Free Windows Admin Tool Kit Click here and download it now

April 23rd, 2014 9:43am

Hi,

1. open ADUC, click "View->Advanced Feature", navigate to one affected user account(All user affected and both internal and external?), check its properties.

2. On Security tab, click Advanced, make sure the "Inherited permission" is enabled; if not enable it;

3. Then navigate to System->AdminADHolder, use above method to make the "inherited permission" is enabled.

4. Reset IIS, then try to login OWA again.

Also, could you please let me know the OWA URL and create a test account(account name and password) for me? I can test from my side as well. Thanks for your understanding.

Edited by Eric ZouZouMicrosoft contingent staff, Moderator Wednesday, April 23, 2014 10:02 AM

April 23rd, 2014 9:43am

Hi,

1. open ADUC, click "View->Advanced Feature", navigate to one affected user account(All user affected and both internal and external?), check its properties.

2. On Security tab, click Advanced, make sure the "Inherited permission" is enabled; if not enable it;

3. Then navigate to System->AdminADHolder, use above method to make the "inherited permission" is enabled.

4. Reset IIS, then try to login OWA again.

Also, could you please let me know the OWA URL and create a test account(account name and password) for me? I can test from my side as well. Thanks for your understanding.

Edited by Eric ZouZouMicrosoft contingent staff, Moderator Wednesday, April 23, 2014 10:02 AM

Free Windows Admin Tool Kit Click here and download it now

April 23rd, 2014 9:43am

I quickly looked thru this post and I did not see any attempt at failed request tracing. You can enable this on the default web site (CAS server) and make note of where the files are saved. Then go to the OWA virtual directory under the default web site and create a rule for 400 status codes (you may want to do 200-400 since at one point it looked like a redirect loop).

Reproduce the issue and review the resulting XML files to determine the cause of your error.

April 23rd, 2014 12:21pm

----------------------------------

1. open ADUC, click "View->Advanced Feature", navigate to one affected user account(All user affected and both internal and external?), check its properties.

2. On Security tab, click Advanced, make sure the "Inherited permission" is enabled; if not enable it;

3. Then navigate to System->AdminADHolder, use above method to make the "inherited permission" is enabled.

4. Reset IIS, then try to login OWA again.

-----------------------------------

This does not fix the problem.

Edited by lt8x7 Thursday, April 24, 2014 12:02 AM

Free Windows Admin Tool Kit Click here and download it now

April 23rd, 2014 11:36pm

----------------------------------

1. open ADUC, click "View->Advanced Feature", navigate to one affected user account(All user affected and both internal and external?), check its properties.

2. On Security tab, click Advanced, make sure the "Inherited permission" is enabled; if not enable it;

3. Then navigate to System->AdminADHolder, use above method to make the "inherited permission" is enabled.

4. Reset IIS, then try to login OWA again.

-----------------------------------

This does not fix the problem.

Edited by lt8x7 Thursday, April 24, 2014 12:02 AM

April 23rd, 2014 11:36pm

----------------------------------

1. open ADUC, click "View->Advanced Feature", navigate to one affected user account(All user affected and both internal and external?), check its properties.

2. On Security tab, click Advanced, make sure the "Inherited permission" is enabled; if not enable it;

3. Then navigate to System->AdminADHolder, use above method to make the "inherited permission" is enabled.

4. Reset IIS, then try to login OWA again.

-----------------------------------

This does not fix the problem.

Edited by lt8x7 Thursday, April 24, 2014 12:02 AM

Free Windows Admin Tool Kit Click here and download it now

April 23rd, 2014 11:36pm

I have looked through the trace files and the final error is that a required file cannot be found.
The missing file is:
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth.owa

April 24th, 2014 12:01am

Hi,

What if we brower to the location, can we find the file? In my lab, it shows like below:

Free Windows Admin Tool Kit Click here and download it now

April 24th, 2014 9:48am

Mine looks exactly the same as yours.

April 24th, 2014 11:05am

Hi,

Could you please post the entire error message for further research? Also, what's the current server's version? with CU or SP1?

Edited by Eric ZouZouMicrosoft contingent staff, Moderator Friday, April 25, 2014 10:08 AM

Free Windows Admin Tool Kit Click here and download it now

April 25th, 2014 10:06am

Hi,

Could you please post the entire error message for further research? Also, what's the current server's version? with CU or SP1?

Edited by Eric ZouZouMicrosoft contingent staff, Moderator Friday, April 25, 2014 10:08 AM

April 25th, 2014 10:06am

Hi,

Could you please post the entire error message for further research? Also, what's the current server's version? with CU or SP1?

Edited by Eric ZouZouMicrosoft contingent staff, Moderator Friday, April 25, 2014 10:08 AM

Free Windows Admin Tool Kit Click here and download it now

April 25th, 2014 10:06am

Server version is Server 2012 R2 Standard Version 6.3.9600 Build 9600

75. -FILE_CACHE_ACCESS_START

FileName	C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth.owa
UserName	SM_496fc34a4dc543db8
DomainName	SYDOTT

<fieldset class="no-border" id="section_detail_76"> 0 ms Informational 76. -FILE_CACHE_ACCESS_END

LastModifiedTime
Successful	false
FileFromCache	false
FileAddedToCache	false
FileDirmoned	true
LastModCheckErrorIgnored	true
ErrorCode	The system cannot find the file specified. (0x80070002)

</fieldset>

April 27th, 2014 11:49pm

Does the auth.owa file actually exist at the location

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth.owa

If so, check the NTFS permissions on it, and make sure that Everyone can Execute it.

Free Windows Admin Tool Kit Click here and download it now

April 28th, 2014 9:40am

There is no such file auth.owa

In Eric ZouZou's post (4posts up) where he shows a screenshot of the directory on his lab server, also the file does not exist.

Is this a file that should be there?
If so, where can I get it from.

April 28th, 2014 9:55am

Ah, no. I forgot - .owa extensions are handled by some odd OWA/IIS trickery. I don't have E2013 in front of me right now, but I'd guess it's similar to E2010, which I do have in front of me.

I'm going to guess that the trickery is performed by an ISAPI filter. Have a look at the properties of your Default Web Site in IIS Manager, and look at the ISAPI filters. Is there one called Exchange OWA Cookie Autherntication ISAPI Filter? If so, is it configured to point to owaauth.dll ? Does the owaauth.dll file exist?

Free Windows Admin Tool Kit Click here and download it now

April 28th, 2014 11:23am

The ISAPI filter is there.
It points to the owaauth.dll which exists in the correct place.

April 29th, 2014 1:13am

Hi,

Please also check the authnetication on IIS MAnager -OWA VD.

As you only have one exchange server, it seems both Mailbox role and CAS role are installed on this server. In light of this, please set the authentication as below and see if it is working:

Default web Site->OWA VD->Authentication-please only enable basic authentication

Exchange Backend ->OWA VD-Authentication->Enable both Anonymous Authentication and Windows authentication

Then right click on the Windows authentication and choose "Providers" and make sure "Negotiate" and "NTLM" providers are existing.

Please check on this, if above setting is not the same as above, please change it and schedule a non-business time to do iisreset to make it take effect.

Sent By

Silver

Free Windows Admin Tool Kit Click here and download it now

April 29th, 2014 8:55am

Okay, thanks for checking. It might be worth checking (since it is the auth.owa resource that seems to generate the error) that the handler mapping for *.owa is configured and enabled. Click on the owa vdir in IIS Manager. Look in the Features view for the Handler Mappings module, and make sure that *.owa appears in the list, and that it is enabled. Double-click it to view the properties, and click Request Restrictions to make sure that POST is listed as an allowed verb.

Having said all that, the following IIS log entry

makes me think that everything will be as it should, since there is no error in the log entry. The response is 302, which I'm sure you know means that your browser is being redirected elsewhere. Since there is no more trace of the logon attempt in the log, we don't even know where you are being redirected to.

It might also be worth just trying to go to https://mydomain.com.au/owa after it has shown the 400 error. There's a chance that the credentials have been accepted, and you will not need to go through the login process

April 29th, 2014 10:52am

Hi,

Please also check the authnetication on IIS MAnager -OWA VD.

As you only have one exchange server, it seems both Mailbox role and CAS role are installed on this server. In light of this, please set the authentication as below and see if it is working:

Default web Site->OWA VD->Authentication-please only enable basic authentication

Exchange Backend ->OWA VD-Authentication->Enable both Anonymous Authentication and Windows authentication

Then right click on the Windows authentication and choose "Providers" and make sure "Negotiate" and "NTLM" providers are existing.

Please check on this, if above setting is not the same as above, please change it and schedule a non-business time to do iisreset to make it take effect.

Sent By

Silver

I made these changes and it does not fix the problem.

Free Windows Admin Tool Kit Click here and download it now

April 30th, 2014 2:08am

Okay, thanks for checking. It might be worth checking (since it is the auth.owa resource that seems to generate the error) that the handler mapping for *.owa is configured and enabled. Click on the owa vdir in IIS Manager. Look in the Features view for the Handler Mappings module, and make sure that *.owa appears in the list, and that it is enabled. Double-click it to view the properties, and click Request Restrictions to make sure that POST is listed as an allowed verb.

Having said all that, the following IIS log entry

04-03 09:24:20 10.2.2.12 POST /owa/auth.owa - 443 domain\user 10.2.2.109 Mozilla/5.0+(Windows+NT+6.3;+ARM;+Trident/7.0;+Touch;+rv:11.0)+like+Geckohttps://mydomain.com.au/owa/auth/logon.aspx?url=https%3a%2f%2fmydomain.com.au%2fowa%2f&reason=0 302 0 64 15

makes me think that everything will be as it should, since there is no error in the log entry. The response is 302, which I'm sure you know means that your browser is being redirected elsewhere. Since there is no more trace of the logon attempt in the log, we don't even know where you are being redirected to.

It might also be worth just trying to go to https://mydomain.com.au/owa after it has shown the 400 error. There's a chance that the credentials have been accepted, and you will not need to go through the login process

April 30th, 2014 2:09am

Hi,

Please also check if the files under location <system driver>/inetpub/wwwroot are as below. If there's some other files existing, please let me know

CAS server:

MBX server:

Thanks!

Sent By

Silver

Free Windows Admin Tool Kit Click here and download it now

April 30th, 2014 6:50am

It's worth bearing in mind that this is from my OWA 2010 setup. Exchange 2013 is very similar, but it's possible that you're not supposed to have an *.owa handler mapping, especially since it didn't get added when you recreated the vdir. Having said that, how is your IIS supposed to serve auth.owa if you don't have a handler mapping for it?

Anyway, if you want to try adding it, and see if it helps, look again at your owa vdir in IIS Manager, and open the Handler Mappings module. Select 'Add Managed Handler' and supply the following:

Request Path: *.owa

Type: Microsoft.Exchange.Clients.Owa.Core.OwaEventHandlerFactory

Name: OwaEventHandler

Request Restrictions (verbs): POST,GET

April 30th, 2014 10:37am

Hi,

Please also check if the files under location <system driver>/inetpub/wwwroot are as below. If there's some other files existing, please let me know

CAS server:

MBX server:

Thanks!

Sent By

Silver

I only have one server for both roles.

It has directories:
aspnet_client
insideout

and files:
iis-85.png
iisstart.htm

Free Windows Admin Tool Kit Click here and download it now

April 30th, 2014 10:52pm

It's worth bearing in mind that this is from my OWA 2010 setup. Exchange 2013 is very similar, but it's possible that you're not supposed to have an *.owa handler mapping, especially since it didn't get added when you recreated the vdir. Having said that, how is your IIS supposed to serve auth.owa if you don't have a handler mapping for it?

Anyway, if you want to try adding it, and see if it helps, look again at your owa vdir in IIS Manager, and open the Handler Mappings module. Select 'Add Managed Handler' and supply the following:

Request Path: *.owa

Type: Microsoft.Exchange.Clients.Owa.Core.OwaEventHandlerFactory

Name: OwaEventHandler

Request Restrictions (verbs): POST,GET

April 30th, 2014 10:52pm

I had a chance to look at my own E2013 server tonight, and I didn't find an *.owa handle, either. So, it is different to E2010 in this respect, and I don't understand how it is supposed to handle the auth.owa request.

Anyway, OWA 2013 seems to act as a proxy for itself. I've no idea why it gets so much more unnecessarily complicated with each version, but it does.

It looks like when you log into OWA 2013, the server sends internal requests, and redirects the client, to its own 'Exchange Backend' web site (maybe it's different if the MBX server is a different one) on port 444. The Exchange Backend looks like an identical site to the default web site (but probably only contains Exchange-related resources), except in that it listens on port 444. When the Backend requests are all complete, the success is finally logged as if it was handled by the default web site.

One interesting thing I found is that you can go direct to the backend site, and it appears to work like owa in the default web site. So it would be interesting to see what happens for you if you go to https:yourservername:444/owa

And you should definitely be seeing log entries in a W3SVC2 folder at the same level as your W3SVC1 folder. When I use OWA here, all the 'interesting' entries are generated in W3SVC2. If you see nothing there, then either you have logging turned off for the backend site, or it isn't actually working at all.

Free Windows Admin Tool Kit Click here and download it now

April 30th, 2014 11:16pm

If I go direct to the Backend on port 444, I get the 400 error straight away.

Trace logs for the 400 error:

Trace log

April 30th, 2014 11:50pm

I think the Backend owa vdir is where the problem is. I don't know if anyone has suggested it yet, but I think the next thing to try would be to delete and recreate the owa vdir on the Backend site, rather than the Default Web Site.

Edit.

Just had a thought - it seems to use the EWS VDir as much as the owa vdir, so if recreating the Backed owa vdir makes no difference, try recreating the backend EWS vdir, too.

See if you can find the 400 iis log entries in the logs in the W3SVC2 folder, instead of the W3SVC1 f

Free Windows Admin Tool Kit Click here and download it now

May 1st, 2014 10:20am

I think the Backend owa vdir is where the problem is. I don't know if anyone has suggested it yet, but I think the next thing to try would be to delete and recreate the owa vdir on the Backend site, rather than the Default Web Site.

Edit.

Just had a thought - it seems to use the EWS VDir as much as the owa vdir, so if recreating the Backed owa vdir makes no difference, try recreating the backend EWS vdir, too.

See if you can find the 400 iis log entries in the logs in the W3SVC2 folder, instead of the W3SVC1 f

May 2nd, 2014 6:49am

Okay, sorry we couldn't find the answer. If MS fix it for you, I'd love to hear what the cause was. If not, come back and we'll carry on.

Free Windows Admin Tool Kit Click here and download it now

May 2nd, 2014 9:40am

Did you ever get this resolved? I'm suffering the same issue!

December 11th, 2014 5:57pm

Greetings,

I am in phase of Upgrading my existing Exchange 2007 Infra to Exchange 2013.

The environment is as mentioned below:

4 Mailbox Server (DAG)

4 CAS Servers (NLB)

I am experiencing the same issue. Only one CAS server is able to pass the login request https://servername/owa

Rest of all the servers are failing with error "HTTPS 400"

Its happening only while accessing OWA, ECP works fine.

Please let me know the fix to counter this strange issue.

Thanks in advance.

Regards

Edited by K 2 Monday, December 22, 2014 8:22 AM

Free Windows Admin Tool Kit Click here and download it now

December 22nd, 2014 8:19am

Greetings,

I am in phase of Upgrading my existing Exchange 2007 Infra to Exchange 2013.

The environment is as mentioned below:

4 Mailbox Server (DAG)

4 CAS Servers (NLB)

I am experiencing the same issue. Only one CAS server is able to pass the login request https://servername/owa

Rest of all the servers are failing with error "HTTPS 400"

Its happening only while accessing OWA, ECP works fine.

Please let me know the fix to counter this strange issue.

Thanks in advance.

Regards

Edited by K 2 Monday, December 22, 2014 8:22 AM

December 22nd, 2014 8:19am

Greetings,

I am in phase of Upgrading my existing Exchange 2007 Infra to Exchange 2013.

The environment is as mentioned below:

4 Mailbox Server (DAG)

4 CAS Servers (NLB)

I am experiencing the same issue. Only one CAS server is able to pass the login request https://servername/owa

Rest of all the servers are failing with error "HTTPS 400"

Its happening only while accessing OWA, ECP works fine.

Please let me know the fix to counter this strange issue.

Thanks in advance.

Regards

Edited by K 2 Monday, December 22, 2014 8:22 AM

Free Windows Admin Tool Kit Click here and download it now

December 22nd, 2014 8:19am

Hi CHris,

I am also experiencing the same issue. Did you find the fix for this issue.

Thanks

Edited by K 2 Monday, December 22, 2014 8:49 AM

December 22nd, 2014 8:49am

Hi CHris,

I am also experiencing the same issue. Did you find the fix for this issue.

Thanks

Edited by K 2 Monday, December 22, 2014 8:49 AM

Free Windows Admin Tool Kit Click here and download it now

December 22nd, 2014 8:49am

Hi CHris,

I am also experiencing the same issue. Did you find the fix for this issue.

Thanks

Edited by K 2 Monday, December 22, 2014 8:49 AM

December 22nd, 2014 8:49am

Unfortunately, I haven't found a fix yet.

I will be calling Microsoft about this and hope to have it resolved before the end of the year.

If you find a solution before I get a chance to post the fix, please share with the group.

Thanks!

Free Windows Admin Tool Kit Click here and download it now

December 22nd, 2014 2:03pm

Greetings,

After spinning my head...I was able to resolve it with a little fix.

First i moved the mailbox database to the databases hosted on other servers to check if the same error is coming. It was working fine for other mailbox servers.

So i restarted the IIS service, MS Exchange RPC Client access service. And moved the user mailbox back to the same Mailbox database.

And its working now.

December 25th, 2014 10:39am

For those using custom themes, this may help.

I was having the same issue: HTTP 400 Bad Request page after logging into OWA. Mobile and Lite versions of OWA worked fine. This was after updating Exchange 2013 from CU6 to CU8. Multi-role server environment.

Installed CU8 on one of the multi-role DAG members. Created a new database on the updated server and moved a test mailbox over to it. I do this because we skin the OWA login pages and use a custom OWA theme.

In my case, I believe the issue was due to the changes in the new theming structure. Themes now use css for styling which can be found at \\mbserver\c$\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\<version>\resources\styles\fabric.color.theme.YourThemeName.css. Previously your theme folder would be stored in \\mbserver\c$\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\<version>\resources\themes. This allows the OWA client to add your theme to the list.

My theory is that the mailbox is requesting the theme and since the server has the same theme name in the theme folder, that passes a check and attempts to the mailbox in OWA with the theme. Since the CSS is not present for this theme, it gives the HTTP 400 Bad Request error page. I'm not an ASP.NET guy, and this is probably over simplified, but it makes sense to me.

Proposed as answer by Geary Epperson 12 hours 1 minutes ago

Free Windows Admin Tool Kit Click here and download it now

March 27th, 2015 3:27pm

For those using custom themes, this may help.

Proposed as answer by Geary Epperson Friday, March 27, 2015 7:25 PM

March 27th, 2015 7:25pm

For those using custom themes, this may help.

Proposed as answer by Geary Epperson Friday, March 27, 2015 7:25 PM

Free Windows Admin Tool Kit Click here and download it now

March 27th, 2015 7:25pm

For those using custom themes, this may help.

Proposed as answer by Geary Epperson Friday, March 27, 2015 7:25 PM

March 27th, 2015 7:25pm

Sorry to bump such an old post but if you got it resolved can you share it please as i suffer the same issue.

Free Windows Admin Tool Kit Click here and download it now

June 7th, 2015 3:55pm

After working with mulitple Microsoft tech's, the proposed solution was to backup the server DBs, format the box and start fresh, then restore the DBs. Since we do not have many users of OWA, I did not want to do this. I am also very hesitant to apply any HFs or roll-ups now. I'm not sure what else is going to break.

June 8th, 2015 9:01am

For those using custom themes, this may help.

I was having the same issue: HTTP 400 Bad Request page after logging into OWA. Mobile and Lite versions of OWA worked fine. This was after updating Exchange 2013 from CU6 to CU8. Multi-role server environment.

Installed CU8 on one of the multi-role DAG members. Created a new database on the updated server and moved a test mailbox over to it. I do this because we skin the OWA login pages and use a custom OWA theme.

In my case, I believe the issue was due to the changes in the new theming structure. Themes now use css for styling which can be found at \\mbserver\c$\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\<version>\resources\styles\fabric.color.theme.YourThemeName.css. Previously your theme folder would be stored in \\mbserver\c$\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\<version>\resources\themes. This allows the OWA client to add your theme to the list.

My theory is that the mailbox is requesting the theme and since the server has the same theme name in the theme folder, that passes a check and attempts to the mailbox in OWA with the theme. Since the CSS is not present for this theme, it gives the HTTP 400 Bad Request error page. I'm not an ASP.NET guy, and this is probably over simplified, but it makes sense to me.

Good call. We had a copy of the old grape theme we'd used, new themes caused 400s.

Free Windows Admin Tool Kit Click here and download it now

June 13th, 2015 12:35pm

I think you ought to repost your question as a new topic - only people who have taken part in this one will see your message. 400 errors are hard to track down, and you need as many people reading it as possible.

Unless you already have done?

June 17th, 2015 4:59am

This topic is archived. No further replies will be accepted.