The last pain point of our Exchange 2003 to Exchange 2010 upgrade was getting Outlook Anywhere working with our XP clients, the cause of which was due to my inexperience with security certificates.
When we originally reviewed our requirements for Exchange 2010 we decided to go with a 20 slot Subject Alternative Name (SAN) Security Certificate. The reason we needed so many slots was due to the various outgoing domains we wanted to support. Also I was under the wrong assumption that I could use this certificate for other non-Exchange purposes, which you can’t.
When picking the Common name (CN) we decided to go with the root domain of our main company. So the final outcome of our SAN certificate was:
Common Name: MainCompany.com
Subject Alterative Names
- Mail.MainCompany.com
- Webmail.MainCompany.com
- Autodiscover.MainCompany.com
- Legacy.MainCompany.com
- Mail.SecondCompany.edu
- Webmail.SecondCompany.edu
- AutoDiscover.SecondCompany.edu
- Legacy.SecondCompany.edu
- Mail.ThirdCompay.net
- Webmail.ThirdCompay.net
- AutoDiscover.ThirdCompay.net
- Legacy.ThirdCompay.net
- SecondCompay.edu
- ThirdCompany.com
- Maseradedomain1.com
- Maseradedomain2.com
- Maseradedomain3.com
This certificate functioned as needed until we decided to roll out Outlook Anywhere a few months into our upgrade. What we noticed is that our XP PCs running Outlook 2007 & 2010 couldn’t connect to our Exchange 2010 server using Outlook Anywhere. Our Vista PCs running Outlook 2007 and Windows 7 PCs running Outlook 2010 had no problem using Outlook Anywhere. When we checked the Exchange Remote Connectivity Analyzer we didn’t see any glaring issues. After playing with various Outlook Anywhere settings and failing we found was that XP, and Vista clients below SP1, can only read the CN on the and not the Alternative names on a SAN Cert. This normally wouldn’t be a problem if our CN could point to an Exchange server hosting the Client Access Server (CAS) role. This can be done be specifying the CN in the MSSTD, but since we used our root domain of our main common as the common name that wouldn’t help us.
Our only option would be to change the CN on our SAN cert. In order to do so the certificate needed to be revoked and then create a new certificate with the proper CN. Most Certificate Authorities will let you change the CN up to 30 days after the purchase date. But since we didn’t roll out Outlook Anywhere until a few months into out Exchange 2010 Upgrade we had to buy a new SAN certificate all together. So this time we made sure the CN was the external address of our CAS server, which in our case was also our Mailbox and Hub Transport as well. Since our company mailboxes are now fully migrated off Exchange 2003 we no longer need the legacy domains, so a 15 slot SAN cert was purchased this time
Common Name: mail.MainCompany.com
Subject Alterative Names
- Webmail.MainCompany.com
- Autodiscover.MainCompany.com
- Mail.SecondCompany.edu
- Webmail.SecondCompany.edu
- AutoDiscover.SecondCompany.edu
- Mail.ThirdCompay.net
- Webmail.ThirdCompay.net
- AutoDiscover.ThirdCompay.net
- MainCompany.com
- SecondCompay.edu
- ThirdCompany.com
- Maseradedomain1.com
- Maseradedomain2.com
- Maseradedomain3.com
We did the certificate swap over the weekend since we weren’t 100% sure if it would cause issues with Webmail, Activesync, etc. Luckily no major service disruptions happened once we assigned services to the new certificate. The only noticeable effect was an informational pop up on our Macs running Outlook 2011. The pop-up asked to confirm that Outlook 2011 was going to accept the new configuration information from out Exchange Server. Once assigned our XP PC’s running Outlook 2007 or 2010 could successfully access Outlook Anywhere.
We has exactly the same problems. But I fixed it with this command in Powershell:
Set-OutlookProvider EXPR -CertPrincipalName:”msstd:contoso.com”
That works only if your CAS will respond to being referenced by the root domain, more often then not the root domain will be associated with the company website. Technically it can be done, but it’s easier (and might be a best practice) to point it to the actual DNS of the CAS server instead of worrying about forwarding those request from the server hosting your company website to your CAS. http://mellositmusings.com/wp-admin/edit-comments.php?paged=1&spammed=10&ids=665,664,662,661,660,659,658,657,656,655#comments-form