Outlook Anywhere - Connect to Exchange using HTTP

[b]Outlook via http - RPC/Proxy[/b]

This was supposed to be a straight forward "click to enable" job.  I was asked to look into this as an alternative to Outlook Web Access by a client and to be honest I wasn't expecting more than 10 minutes while I read the web links and Googled best practices etc.

There were (and still are) several factors that would see me struggle with this over 3 - 4 days from morning to morning.  This had become a challenge and I was also morbidly curious.

I will attempt to replicate my steps and include the fixes mentioned from what I read from other people's findings.  For each solution that I tried or implemented I used connectivity tests both on the local server and from remote client PCs to verify the fix or no fix.

1. Make sure server name and exchange proxy settings - "Use this URL to connect to my proxy server" address are the same.

No - the Microsoft connectivity checker made this quite clear to me.

https://www.testexchangeconnectivity.com/

When it asked for the Exchange server details the mini help window explains that it has to be the internal FQDN for the exchange server.  I even tried putting the external URL address and it would not take it.  So this was conclusive for me.   It did concur, however, that the username was in the format of [username@webaddress] e.g. user@microsoft.com.

2. Under the Proxy settings, use basic authentication

Yes - now that I have this working I can confirm that thus far you must have matching security options for both client and server.  It can be either NTLM or basic and I have tested both.

 


3.  Do you need open ports or forwards?

No – I did not know at the time but after reading up on this the RPC is encapsulated within the http session and  therefore doesn’t need any additional ports opened or forwarded.  You do need [https] enabled and for this you may need to have a port open or forwarded to your Exchange server.

4.  Need an SSL certificate and how to create it

Yes – As always, when I initially tried connecting the Outlook client I was fortunate to catch an error that popped up saying the principal name on the certificate did not match the name on the proxy URL address.  Microsoft explains the problem here:

http://technet.microsoft.com/en-us/library/aa998424%28v=exchg.80%29.aspx

And this Guy provided a very good guide to creating the certificate needed – but be very clear that while [Subject Alternate Names] is a good idea, some cheap SSL certificates/providers may not support multiple domains and you have to get a more flavoursome certificate to support more than just the external https URL:

 http://blogs.microsoft.co.il/blogs/roneng/archive/2008/03/20/create-certificate-for-exchange-2007-servers-using-windows-ca.aspx

This document talks about how to generate the certificate but I tried to get a certificate from www.123-reg.co.uk but they kept failing to parse the CSR [Certificate Request, Comodo free SSL certificate parsed the CSR and told me there was no country called “UK” did I mean “GB”.  But that’s not why 123-reg failed to parse…go figure.

The generated SSL certificate from Comodo did not have traceable Certificate Chains and therefore exchange did not trust the certificate.  I therefore ended up using a Geotrust certificate because it had an easier to implement Certificate Authority and certificate chain (Certificate Authority and Intermediate Authority).

http://www.geotrust.com/products/ssl_certificates/index.asp

Please note that some Exchange Shell commands may produce slightly different results between the different flavours and so do not be afraid to Google the commands and the syntax unless you know them all!  One command in particular was the “-path” command which was supposed to direct the output from the CSR generated to a file at your location.  But mine kept generating either a blank document or coming up with an error relating to the “-path” being too many parameters or such.  Without the –path command it simply output to the screen and I was able to copy it from there.

A note on certificates – if your certificate is not from one of the top dogs (Verisign for example) then make sure your SSL certificate is in “personal”, the root is in the “Trusted Root”, and the Intermediaries are in “Intermediate Certificate Authority”.  Or else exchange will kick out an error about “the certificate is not valid for use with exchange”.

5.  Install RPC over http proxy & Enable Outlook Anywhere – I was lucky, my RPC over http was already installed and my Outlook Anywhere already enabled and installed because I wanted my client to use Outlook Web Access.

But I came across a problem and the result of the fix I searched for suggested removing and re-installing Outlook Anywhere and RPC/Http.  This link from Microsoft tells you how to add these and has “more tasks” detailing enabling Outlook Anywhere:

http://technet.microsoft.com/en-us/library/dd776122.aspx

6.  Installing the latest updates

Yes – because it is generally good practice
No – because none of the updates I installed fixed the problem
However – while trying to install Exchange server, Service Pack 1, the prerequisite checks did warn that a number of updates needed to be installed first and CRUCIALLY that my IIS was in 32-bit mode and not 64-bit mode.  You can change this here:

 
Why is this so important?  The client kept failing to connect – even after everything above – you can imagine the frustration!  And all I kept getting was a “503 service unavailable” in the connectivity test after everything else passed.

Running tests against rpc/http proxy whilst in 32bit mode kills SExchangeServicesAppPool.  It is also terminated when the client tries to connect [remotely via http].

I tried testing this from both points:
1.      32-bit and MSExchangeServicesAppPool enabled and run connectivity and client against it, it dies
2.      64-bit enabled and MSExchangeServicesAppPool in stop state and ran connectivity and same errors came up
3.      Enable 64-bit mode, start MSExchangeServicesAppPool, and then try connectivity tests, all passed .  Please note that this “Pass” was from doing the test on the local server.

 
So then I thought to test the connectivity from a remote PC and it returned a final failure:
“unable to ping the port 6001 on remote server, information  store unavailable” or something very similar.  Luckily I had encountered the problem earlier and know how to fix this.  For security, the RPC endpoints have to have requests to specified available ports by name otherwise the call is ignored.  You must, therefore, also specify the web URL for your proxy address – mail.microsoft.com:6001 -6002.  All the other ones are already in there from enabling Outlook Anywhere.  Valid ports = mail.microsoft.com: 49152-65535 and validports_autoconfig_exchange = mail.microsoft.com:6001-6002

 
7. Enable Users for access – I cannot remember if it was “anonymous” by default but remove it and either put specific users or groups such as “Authenticated Users” or “Domain Users”:

 
8.  Authentication – running the connectivity tests from a remote client recently generated this error:

Testing HTTP Authentication Methods for URL https://mail.microsoft.com/rpc/rpcproxy.dll.  The HTTP authentication test failed. Not all the required authentication methods were found.
Methods Found: Basic
Methods Required: NTLM

The resultant help document suggests:  “Please note that these authentication methods should be managed through the Set-OutlookAnywhere cmdlet and not directly in IIS.”  Oops! Oh well I will remember that in the future.  If you are like me and are rubbish at command line then use this tab in the Exchange Management console.  I have tried both Basic and NTLM and they both seem to work so I stuck with NTLM for security reasons.

 
Which will lead you back to the following error, but as yet it only holds true for remote clients, but does not stop functionality:-

[b]"Attempting to ping RPC endpoint 6001 (Exchange Information Store) on server [FQDN].  The attempt to ping the endpoint failed."

Additional Details[/b]

The RPC_S_SERVER_UNAVAILABLE error (0x6ba) was thrown by the RPC Runtime process.
From what I can tell the “validports_autoconfig_exchange” registry entry keeps refreshing and dropping the entries that I had made and I had to use a script to have the registry entry put back in automatically.

Again, the client can still connect so…

I have added a batch file that loads the registry modifications by schedule, every 5 minutes.  This seems to work although I cannot quite work out what triggers the refresh and thus the deletion of the “validports_autoconfig_exchange”.

Thank you for reading, I hope this solves your problem.