Public Certificates for Exchange 2010 Federation

I think that one of the coolest features of Exchange 2010 is the seamless free/busy and calendar federation between organizations. In order to get federation provisioned there are a number of steps you need to take which you can find detailed on Technet.

The first step of this setup involves creating a Federation Trust to the Microsoft Federation Gateway (MFG), but in order to create this trust you need to use a public certificate issued by one of the following Certificate Authorities (the haphazard thumbprint formatting is Technet’s, not mine):

CA certificate friendly name Thumbprint
Comodo NA
Digicert Global Root CA ‎083B:E056:9042:46B1:A175:6AC9:5991:C74A
Digicert High Assurance EV Root CA ‎91 8d a5 e4 99 c1 5f 7c 62 75 b1 24 fe de 53 35 7c 34 bd 36 CA (2048) 801D 62D0 7B44 9D5C 5C03 5C98 EA61 FA44 3C2A 58FE
Entrust Secure Server CA 99A6 9BE6 1AFE 886B 4D2B 8200 7CB8 54FC 317E 1539
Go Daddy Secure Certification Authority ‎7c46 56c3 061f 7f4c 0d67 b319 a855 f60e bc11 fc44

I recently was involved an Exchange deployment that involved purchasing a SAN certificate from Comodo. One of the certificate authorities Comodo uses to issue SAN certs is the USERTrust Legacy Secure Server CA, which has its own certificate issued by the Secure Server Certification Authority. Bottom line is the certificate you get verifies up to the Entrust certificate you can see below which the Federation Gateway supports.


After trying to create the Federation Trust we were seeing the following error:


An error occurred while attempting to provision Exchange to the Partner STS. Detailed information “An error occurred accessing Windows Live. Detailed information “The request failed with HTTP status 403: Forbidden.”.”

Basically this is the MFG’s way of saying “I don’t trust this certificate.” It turns out the MFG is geared to only accept certificates issued directly from one of the certificate authorities listed above which is not something I saw in the documentation. So if the Entrust Secure Server Certification Authority had issued our webmail certificate it would have been accepted. But like in our case, if your certificate is issued from a 3rd party intermediate certificate authority it won’t be accepted even if it technically verifies up to a support rooted authority.

The good news is a call to PSS resulted in Microsoft making a change on the MFG to accept certificates issued by this particular intermediate CA going forward for everyone. So if ran into this error previously you should be able to try again with the same certificate and see the trust succeed. As of this writing I’ve requested them to also add support for the AAA Certificate Services intermediate CA Comodo also issues certificates from.

Exchange 2010 SSL Offloading

One of the deployments I've been working on recently involved using F5 BigIP hardware load balancers to do SSL offloading for a two-node Exchange 2010 design. To give some background here usually you would just pass through port 443 (I'm skipping over the RPC Client Access piece since it's not relevant here) from your load balancer straight to the Exchange servers, letting the servers handle the SSL encryption like in this diagram:


The benefit of that approach is it's simple and a very common deployment method. On the flip side, you can benefit from offloading SSL encryption to the BigIPs and gain some more advanced forms of load balancing. In this case the improved load balancing was the goal along with some internal policies forcing this approach. What happens with SSL offloading is the HTTPS traffic ends at the BigIPs which turn around and pass port 80 clear-text traffic back to the Exchange servers so they have a bit less CPU work to do. That strategy looks more like this:


The problem with this configuration is Exchange is really designed to operate with SSL in mind and you have to go out of your way to allow it to operate in clear-text. What you'll need to configure on each CAS server is:

The issue I ran into is after following all of these steps Autodiscover was still not functional through the load balancing. I could enter https://<CAS Array FQDN>/Autodiscover/Autodiscover.xml into a browser and reach the XML file with no problem, but running the Autodiscover test within Outlook would return a 404 error. Every other service was working just fine:


This threw me for awhile and after a bit of searching I ran across KB 980048 where it's noted that Autodiscover cannot be used on port 80 with an HTTP POST request, which is what Outlook uses. My attempts at accessing the XML directly succeeded because I was only trying to download the file. Supposedly this is going to be fixed in Service Pack 1.

While the KB provides no immediate solution what I found that works is to use the same methodology Technet recommends for the Exchange Web Services web.config file. Go into your /Autodiscover folder and edit the web.config to replace all instances of httpsTransport with httpTransport (a simple search and replace should work). Be sure to save a copy before you make modifications, restart your server after making the change and you should be able to offload SSL for Autodiscover successfully. Since as far as I know this is undocumented today you can try this at your own risk, but it appears to be working.

Your OCS Front-End and DPM 2010 Part 3: Recovery

Now would normally be the time where everyone is running around like their head has been cut off because your Front-End server is totally hosed, but because you followed the backup procedures in Part 1 (you did run the backup, right?) restoring service to your OCS server is fairly simple.

Restore the Database

  1. Open up the DPM console.
  2. Click the Recovery tab at the top.
  3. We need to restore the SQL database and files separately, but let's start with the database. Expand the tree to <Forest Name>\<OCS Server>\All Protected SQL Instances\<OCS Server>\RTC\rtc
  4. Highlight a suitable recovery date in the calendar and select the RTC database below.
  5. Right-click and select Recover...
    10-9-2009 1-59-40 PM
  6. Press Next.
    10-9-2009 2-01-09 PM
  7. We've successfully screwed up the server to where we might as well recover to the original SQL server. Select that option and press Next.
    10-9-2009 2-01-12 PM
  8. Select Leave database operational and press Next.
    10-9-2009 2-01-16 PM
  9. No options needed. Just press Next.
    10-9-2009 2-01-21 PM
  10. Yup, those are the files we need. Press Recover.
    10-9-2009 2-01-43 PM
  11. Press Close while the recovery operation occurs.
  12. If you click the Monitoring tab you can view the jobs in process.

Restore the Files

  1. Now we need to restore files separately. Expand the tree to <Domain Name>\<OCS Server>\All Protected Protected Volumes\<OCS Installation Volume>
  2. Highlight a suitable recovery date in the calendar and select the Program Files folder below.
  3. Right-click Program Files and select Recover...
    10-9-2009 2-06-28 PM
  4. Press Next.
    10-9-2009 2-06-34 PM
  5. Select Recover to the original location and press Next.
  6. Select to Overwrite the existing versions (if any), and then select to Apply the security settings of the recovery point version. Press Next.
    10-9-2009 2-07-51 PM
  7. Now press Recover.
    10-9-2009 2-07-58 PM
  8. Press Close while the recovery operation occurs.
  9. If you click the Monitoring tab you can view the jobs in process.

Fix SQL Database Chaining

One thing DPM won't restore is an option within SQL. If you miss this step your Front-End services will fail to start.

  1. Open SQL Management Studio (Express).
  2. Press the New Query button.
  3. Enter the following text:
    sp_dboption 'rtc','db chaining',TRUE

  4. Press Execute.


Bounce the Server

If you check your OCS Front-End you'll find all the files you deleted previously have now returned. You could probably get away with restarting services as this point, but since the machine was completed hosed I'm just going to restart the server and cross my fingers.

Check Functionality

After the restart all of my OCS services started successfully and my errors have gone away. You can see now my Communicator list still has my contacts and access levels defined. Likewise, Device Updates and client auto updates should function normally now.

10-9-2009 2-26-18 PM