Help! My Exchange 2010 Outlook Anywhere Proxy Address is being set incorrectly.

After spending a couple of hours trying to get to the bottom of why our Outlook Anywhere proxy settings were incorrect set I finally solved the issue and thought it best to document on the web as this information seemed scarce to say the least and there didn’t seem to be a definitive answer to this issue.

Outlook Anywhere has 2 sets of parameters within the auto discovery service that require modifying for Outlook Anywhere to function correctly in our solution, before I start to delve in to my solution I will give you some background information on our Client Access Role server architecture. The solution I architected for our company consists of 2 x Exchange 2010 CAS servers (excas1 and excas2) which are load balanced and 1 pre-existing Exchange 2007 CAS server (atlantis).

For obfuscation our old Exchange 2007 infrastructure was sat behind a different set of DNS records than our live domain (as well as our internal network) the name of which was relatively unrelated to the company’s real name. I thought it was a great idea at the time when I was designing the solution but over the last couple of years it has proven to be more of a burden than a help, so as part of our migration we are decommissioning this domain.

For the rest of this article please assume the following domain information …

Our live domain is ContosoA.com
Our obfuscation domain is ContosoB.com

For some reason our Exchange Server had randomly picked an Outlook Anywhere proxy and SSL principal name of mail.contosob.com which was completely wrong as our previous external address was webmail.contosob.com so I have no idea where this address came from! We now needed to get this changed to mail.contosoa.com so that auto discovery would deploy the correct settings to our Outlook Clients.

Solving the SSL Principal Certificate error.

After a bit of digging through our Outlook Web Services as well as running a couple of diagnostics I could see the issue, part of the fix for this issue can be found on Technet.

http://technet.microsoft.com/en-us/library/aa998424(EXCHG.80).aspx

After running get-outlookprovider I could see that our EXCH variable was set incorrectly, as shown below

[PS] C:\Windows\system32>get-outlookprovider

Name                          Server                        CertPrincipalName                   TTL
EXCH                                                                                                                                        1
EXPR                                                                     msstd:mail.contosob.com              1
WEB                                                                                                                                           1

Resolving this issue was the easy bit, simply running the command below will set our Certificates Principal Name to the correct address mail.contosoa.com.t

Set-OutlookProvider EXPR -CertPrincipalName:”msstd:mail.contosoa.com”

So problem A was now fixed and a quick forced update of my Outlook Settings now showed that the Certificate Principal is now set to mail.contosoa.com so on to problem B.

Setting the Outlook Anywhere Proxy Address

The fix to this was relatively simple but it took some tracking down to find where this was being set and information on this was scarce and hard to come by!

To diagnose the problem I ran the command

test-outlookwebservices -clientaccessserver “excas1.contosoa.com” which came back with a lot of information about what the auto discovery service was sending out to my clients. In particular a few things appeared in this as strange and were all related to our rogue URL mail.contosob.com.

I then inspected the RPC web service configuration using the command:

get-outlookanywhere |fl externalhostname

This returned the following very useful information

ExternalHostname : webmail.contosob.com
ExternalHostname : mail.contosob.com
ExternalHostname : mail.contosoa.com

After doing a bit more digging I found that the first entry was our 2007 server and so was correctly set, the 2nd rogue entry appeared to be the first of our CAS servers and the 2nd correct entry appeared to be the second CAS server that we have. Having 1 server set correctly and the other not probably explains some of the erratic behaviour we have seen with the configuration of our clients, as depending on which CAS server Outlook picked up would have influenced the configuration returned by the auto discovery service.

Fixing the issue is now a relatively small change as follows:

set-outlookanywhere –identity “excas1\rpc (Default Web Site) “ -externalhostname “mail.contosoa.com”

Note that the server’s identity must be in the form of <server name>\<web site> (i.e. rpc (Default Web Site)) for this command to work correctly.

Forcing a refresh of the Outlook Client

Normally Outlook refreshes client settings every 60 minutes, obviously when you are testing a fix this would be a long time to wait! To test your fix a little bit quicker go to Tools | Accounts | Select your account | Repair. This will force a refresh from the auto discovery web services and allow you to see if a fix has worked.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s