Redirecting Exchange 2010 OWA from http to https

In Exchange 2007, http can be redirected to https using the URL Redirect method

In Exchange 2010 this doesn't work in most situations because port 80 is required to be open on the localhost address in order for the Exchange Management Console to work properly. In fact if you try to use the URL Redirect method, both Exchange PowerShell and the EMC will start throwing an initialization error. So the solution is to use custom error pages to redirect requests.

Brien M. Posey's article gives a really good explanation of how to create the custom error page for error 403.4 to perform the redirection from port 80 to port 443.

Having port 80 open to the internet is still not very good or secure for Exchange servers and I would encourage moving away from that practice. But if you have an absolute requirement for OWA to be accessible via an http URL, this is a quick and easy way to redirect traffic.

Lync 2010 - Upgrading to RTM and Web Components failing to install.

We accidentally waited too long to update our RC to RTM, and our Front End service was failing to start this morning.

Thankfully, I found this blog entry that Mike Stacy wrote on how to migrate fro m RC to RTM fairly painlessly.
http://mikestacy.typepad.com/mike-stacys-blog/2010/11/upgrading-from-the-release-candidate-of-lync-to-rtm-completely-unsupported.html

And everything worked as expected until I got the below error:
Error: Error returned while installing WebComponents.msi(Feature_WebComponents_CommonFiles,Feature_WebComponent_AddressBook,Feature_WebComponent_AuthFramework,Feature_WebComponent_AdminUI,Feature_WebComponent_CertProv,Feature_WebComponent_DataMCUWeb,Feature_WebComponent_DevUpdate,Feature_WebComponent_DialinPage,Feature_WebComponent_GroupExpansion,Feature_WebComponent_JoinLauncher,Feature_WebComponent_LocationInfo,Feature_WebComponent_MeetingMCUWeb,Feature_WebComponent_OcsPowershell,Feature_WebComponent_Rgs,Feature_WebComponent_ReachWeb,Feature_WebComponent_WebTicket), code 1603. Please consult log at C:\Users\clehradmin\AppData\Local\Temp\Add-WebComponents.msi-Feature_WebComponents_CommonFiles,Feature_WebComponent_Addres~-[2011_02_28][10_26_37].log

Checking in that Web Components log file, I found:
MSI (s) (4C!74) [10:32:06:364]: Product: Microsoft Lync Server 2010, Web Components Server -- Error 29024. Error 0x80004005 (Unspecified error) occurred while executing command 'C:\Windows\system32\inetsrv\appcmd.exe'. For more details, check log file 'C:\Users\CLEHRA~1\AppData\Local\Temp\LCSSetup_Commands.log'.

Checking the LCSSetup_Commands.log, I found this:
Filename: \\?\C:\Windows\system32\inetsrv\config\applicationHost.config
Line Number: 428
Description: Cannot add duplicate collection entry of type 'add' with unique key attribute 'name' set to 'OCSAuthHelperModule'

I edited the ApplicationHost.config, removing the below line for that Module, and was able to then reinstall!

This got me past that issue. Hope this helps someone else.

Unknown 500 Autodiscover and RPC errors when publishing Exchange 2010 on a non-default web site

Typically, when I am implementing Exchange for a customer, I try to make the configuration as simple as possible.  Sometimes this is not always possible, unfortunately.   This particular customer had an AD FQDN that was a three letter domain name, ending in .com, that they did not own on the Internet, therefor the chances of getting a 3rd party trusted SSL certificate issued for that domain name was not possible.

Below is a diagram of the intended design and configuration of the environment (for simplicity in this post, this is a single server environment, running MBX, CAS, and HT roles on a Windows 2008 R2 Enterprise OS with Exchange 2010 Standard SP1 RU2.

So in IIS, I configured the "External Web Site" to listen explicitly on .14, and the Default listens on .13.
The default web site is protected with an internal CA, and the external with a Digicert UCC certificate.


Once this was configured, I then essentially got Exchange to use it, recreating each vDir:

• New-AutodiscoverVirtualDirectory  -Website "External" -externalURL "https://mail.company.com/Autodiscover/autodiscover.xml
  
• New-EcpVirtualDirectory  -Website "External" -externalURL "https://mail.company.com/ecp"
  
• New-WebServicesVirtualDirectory  -Website "External" -externalURL "https://mail.company.com/ews/Exchange.asmx"
  
• New-OWAVirtualDirectory -Website "External" -externalURL "https://mail.company.com/owa"
  
• New-OABVirtualDirectory  -Website "External" -externalURL "https://mail.company.com/OAB"
  
• New-ActivesyncVirtualDirectory  -Website "External" -externalURL "https://mail.company.com/Microsoft-Server-Activesync/"
  

Finally - the trickiest one is the RPC and RPCWithCert vdir's - I have blogged on that before here and the process still works. So at this point, your IIS console should look like this:


If you notice I removed the Autodiscover vdir on the default web site, it was because LAN users will use SCP and AD to autodiscover.  But otherwise, I have all Exchange vdir's duplicated.

Once this was complete, I had a network engineer create a NAT for me, and an ACL for TCP/443 to my Exchange 2010 CAS server.  I tied the mail.company.com DNS name to the IP of that NAT entry.  Of course, a CNAME for autodiscover.company.com was also created, and my Digicert SSL cert has this name on it as a Subject Alternate Name (SAN)

Then, it was time to head over to the ExRCA tool for some CAS testing!

Unfortunately, I was immediately confronted with odd errors while autodiscovering:
ExRCA is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.company.com/AutoDiscover/AutoDiscover.xml for user test@company.com.  ExRCA failed to obtain an Autodiscover XML response.
An HTTP 500 response was returned from Unknown.

From Outlook 2010: 
Autodiscover to https://autodiscover.company.com/autodiscover/autodiscover.xmI Failed (0x80004005)

Running test-OutlookConnectivity against the External Site got this clue: 
Test-OutlookConnectivity:  An unexpected exception occurred while pinging RpcProxy. The most common reason for this occurring is that the IIS DefaultAppPool isn't running. Exception: The remote server returned an error: (500) Internal Server Error.

From the W3SVC2 IIS logs (specific to External site) 

2011-02-15 20:32:57 191.168.1.14 POST /AutoDiscover/AutoDiscover.xml - 443 - xx.xxx.xx.xx Microsoft+Office/12.0+(TestExchangeConnectivity.com) 500 0 0 281 

2011-02-15 20:32:57 191.168.1.14 POST /AutoDiscover/AutoDiscover.xml - 443 - xx.xxx.xx.xx Microsoft+Office/12.0+(TestExchangeConnectivity.com) 500 0 0 78 

Checking the application event log, I found this: 
Log Name:      Application
Source:        System.ServiceModel 3.0.0.0
Date:          2/15/2011 2:38:14 PM
Event ID:      3
Task Category: WebHost
Level:         Error
Keywords:      Classic
User:          SYSTEM
Computer:      Exchange.corp.tld.com
Description: WebHost failed to process a request.  Sender Information: System.ServiceModel.ServiceHostingEnvironment+HostingManager/35104124  Exception: System.ServiceModel.ServiceActivationException: The service '/Autodiscover/AutoDiscover.xml' cannot be activated due to an exception during compilation.  The exception message is: Could not find a base address that matches scheme http for the endpoint with binding CustomBinding. Registered base address schemes are [https].. --->
System.InvalidOperationException: Could not find a base address that matches scheme http for the endpoint with binding CustomBinding. Registered base address schemes are [https].

Process Name: w3wp
Process ID: 5828

 Very Weird.  But the application event log gave the biggest hint with this:
Could not find a base address that matches scheme http for the endpoint with binding CustomBinding. Registered base address schemes are [https]."  

The fix, after a long time researching and trying different things…
Add an http listener for port 80 to the "External" Site. 

I have no idea why this works.  But it does.  That IP does not have port 80 open on the firewall, and while it is working, the IIS logs do NOT show any port 80 traffic coming into it, but without port 80 listening on the site, there are 500 unknown errors on the ExRCA for autodiscover as well the the RPC virtual directories if performing a manually configured test (bypassing autodiscover)


I am not sure if this is a bug, or a known configuration requirement, but I was unable to find any documentation from MSFT on this.

Server Service - Error 2: The system cannot find the file specified

Had a customer with a brand new Windows 2008 R2 server VM that started representing the error shown below.

Error 2: The system cannot find the file specified

I spent some time trying different authentication methods for the service, and trying to confirm versions of srv.sys, all seemed to be correct and OK with the server, and it was patched and up to date as well.

I stumbled upon this thread talking about solving a similar issue:

http://social.technet.microsoft.com/Forums/en-US/winserverfiles/thread/3316a5e0-fc2f-4300-917d-66e1527b4aa7

User m_a_tt's post is what lead me to resolve this issue. 

I checked the "dependencies" of the service on my server:

Compared to another server with the same patch level:

So I browsed into the registry to get the multi-string data that represents these two dependencies:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer

And then added them to my "broken" server's registry.

Rebooted, and all was working again.  After some further digging, I found out that this was indeed manually configured this way by a co-worker who was following instructions from an HP Lefthand SAN installation.  The exact line in their documentation was:

sc lanmanserver depend= MSiSCSI

Future note if you implement storage - this seems to replace existing entries entirely.  The command below would be more appropriate:

sc lanmanserver depend=SamSS/Srv/MSiSCSI

Hope this helps some people searching.  I will post this article in the thread previously mentioned as well.