G:\Exchange>Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms 

Welcome to Microsoft Exchange Server 2013 Cumulative Update 7 Unattended Setup

Copying Files...

File copy complete. Setup will now collect additional information needed for

installation.

Languages

Mailbox role: Transport service

Mailbox role: Client Access service

Mailbox role: Unified Messaging service

Mailbox role: Mailbox service

Management tools

Client Access role: Client Access Front End service

Client Access role: Front End Transport service

Performing Microsoft Exchange Server Prerequisite Check

    Configuring Prerequisites                             COMPLETED

    Prerequisite Analysis                                     FAILED

     The language pack bundle could not be found or is corrupt.

     For more information, visit: https://technet.microsoft.com/library(EXCHG.15

)/ms.exch.setupreadiness.LangPackBundleCheck.aspx

exchangesetup.log

Log sequence

[01/20/2015 01:08:36.0915] [1] Failed [Rule:LangPackBundleCheck] [Message:The language pack bundle could not be found or is corrupt.]

[01/20/2015 01:08:37.0008] [1] [REQUIRED] The language pack bundle could not be found or is corrupt.

[01/20/2015 01:08:37.0008] [1] Help URL: https://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.LangPackBundleCheck.aspx

[01/20/2015 01:08:37.0039] [1] Ending processing test-SetupPrerequisites

The Solution

I tried to repair the installation by reinstalling the server and client language packs but the error still persisted. After checking under the Exchange registry keys I found a key called "Language Packs". The exact location of the reg key was "HKEYLMACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\Language Packs" . Once I removed the "Language Packs" registry key, and ran the recovery setup again, the setup completed successfully.

Special thanks to Sainath Vijayaraghavan and Rob McCarthy for assisting with the article.

Exchange 2013 Mailbox

1. Outlook >>>>> 2013 CAS DWS:443

2. 2013 CAS >>>> 2013 MBX:444

3. 2013 CAS <<<< 2013 MBX:444

4. Outlook <<<<< 2013 CAS DWS:443  

Step by Step Connection Flow 

• IIS authenticates the request and Microsoft.Exchange.FrontEndHttpProxy.dll running in the MSExchangeRpcProxyAppPool.  HTTP Proxy determines the Mailbox Anchor, accessing Active Directory to look up the user, then maps to the user object that contains the mailbox GUID.  As soon as we obtain the GUID, HTTP Proxy refers to Active Manager to locate the database where the mailbox resides.  At this point, HTTP Proxy then builds the URL to the mailbox server that contains the user's mailbox GUID@Domain.com.

• HTTP Proxy takes the authenticated request and creates a serialized blob (that contains SID, user groups, and more. Then a new header is attached that contains the Client Access server name, in order to use CSC (serialized access token authentication, also known as server to server authentication) and sends this new http request URL to the Mailbox server over SSL on port 444.  The new URL contains the Mailbox server name so that the Mailbox server knows the request belongs to this server. 

• The request is sent to the Mailbox server's RPC Virtual Directory that is running in the MSExchangeRpcProxyAppPool by using by default, integrated authentication.

• RPCProxy.dll on the Mailbox server is responsible for extracting the RPC packet from the tunnel and forwarding it to the local RPC Client Access Service on Port 6001.  

Now that we went over the connection flow when a mailbox is located on an Exchange 2013 mailbox server, we can cover why this breaks and why is so important of not changing or having a third party certificate bound to port 444 on the Exchange Back End Web Site. When the client connects to the CAS, and HTTP Proxy determines where the mailbox is located, it builds an URL to the destination mailbox server on port 444. The URL is built using the hostname. Once we have the URL we try to connect on secure port 444 using SSL. In the process of the SSL handshake there is several validation task that have to take place before the connection is allowed. If the name being used on the URL is not in the certificate the request will fail and your client can’t connect.

But I see 200 status codes in the IIS logs…

The reason you ‘ll see the 200 status codes on IIS is due to the initial communication that is occurring on port 443 and on the Default website. Where the process breaks is during the second part of connecting to the mailbox server on port 444. If you look closely at the HTTP proxy logs, you will have two columns one for HTTP status and one for backend status. In that log you can see the 200 on the first hop but when passing it to the mailbox server on port 444 it fails with the 500 error. Another log that you can check is the IIS log for W3SVC2. In this folder you have the logs for all traffic going thru the Exchange Back End web site.

Screenshot 1 shows wrong binding configuration

Screen Shot 2 of Exchange Shell Error when certificate is misconfigured

 Screenshot 3 after editing (corrected) the Exchange Back End Certificate Binding

Screenshot 4

Screenshot 5 and 6 of OWA behavior when certificate binding incorrect on the Exchange Back End Web Site

After logging in you get a blank page

Conclusion

The main point of this article is that if you have incorrect certificate bindings on the Exchange Back End web site, it can cause the web services on Exchange 2013 server not to work properly. This incorrect certificate binding will break the connection flow, causing clients to have a bad experience. Always make sure the Exchange Back End certificate bindings for 444 always is configured to use the self-signed certificate.