From the sheer depths of postings and questions and answers on the Internet one could be forgiven for assuming that Outlook Anywhere is almost the Holy Grail of Exchange 2007.

Let’s face it, the ability to point Outlook 2003 or 2007 at a given secure URL and then “bang” you are off with all of the functionality that the Outlook client provides is a really attractive idea, and indeed – when implemented correctly provides a much more rich environment than OWA (although one could argue that OWA presents a far easier solution to both configure and then access – but as this article progresses – I hope to change your minds).

Although this two part series is based around Outlook Anywhere – the one key element to understand – especially if you are using Outlook 2007 Clients, is the principle of the “Autodiscover” service and associated Web Services as it is a core element to all functionality being available in Outlook when OA in configured and in operation.

I will be honest – the whole “Autodiscover” idea and concept has bamboozled quite a lot of people (including me for a period) but, when you get to understand it, and indeed follow some basic pre-configuration rules – a simple setup is very easy accomplish.

The key aspects to a successful Autodiscover (vis-a-vie OA) implementation include the following:

  • Correct implementation of your Firewall Infrastructure to allow 443 access
  • Understanding your DNS infrastructure for both internal and external access
  • Correct DNS Naming on the SSL SAN Cert
  • Ensuring that your Mailbox Primary SMTP Address domain can be matched to the client access server and a domain registered on the SSL SAN Certificate
  • The configuration of the OAB
  • The Configuration of the Web Services Virtual Directory
  • The Configuration of the Autodiscover Virtual Directory
  • The Configuration of OWA Internal and External OWA URLS
  • The Configuration of the OA External URL

Bearing the above in mind, (hopefully) after reviewing this article all of your Exchange mobile services should function correctly – these include:

  • OWA
  • Active Sync
  • Outlook Anywhere
  • Outlook Offline Address Book Download

So before we begin – what is Outlook Anywhere?

Exchange 2003 introduced the concept of RPC over HTTP if you where using Outlook 2003 or Outlook 2007 – essentially the system worked by encapsulating RPC calls into HTTP. This was a fairly cool idea as it allowed for the normally port hungry, RPC calls of Outlook to be packaged up into port 443.

The net result is when you have a properly configured Outlook Anywhere configuration you can point either an Outlook 2003 or 2007 client at and access your email as if you were on your LAN over an encrypted channel without the need for a VPN solution.

Firewall Configuration:

This can be and often is a pretty subjective as many people use many types of Firewall / Security Access Appliance – therefore producing a “One Size Fits All” guide to getting connectivity to your internet facing Client Access Server can be tough. The general guidance is to ensure that all port 443 (SSL) traffic from your external Interface should be redirected to the internal interface of the Client Access Sever.

You should not place a Client Access Server within a DMZ – therefore if you are looking to optimise security you should look at using ISA Server or a reverse proxy to protect your Client Access Machine – for the purposes of the remainder of this article assume that the Client Access Server has been correctly setup from the Internet via the Firewall / ISA Server using port 443.

Good Rules to follow prior to your implementation:

Essential – Understand your Domain Namespace and SSL Requirements:

Most of the initial implementation problems that I have seen with OA are to do with the companies domain’s and the types of SSL configuration that they have implemented.

Most configurations that I have come across (admittedly not all – but most therefore the following will be the type of configuration that this article will focus on) have a domain configuration like so:

ExampleConfig-OA-TwoDNSNS

The diagram above depicts a company where the internal clients will access OWA, OA and other Exchange web related Servers via the URL https://owa.mycompany.local – whereas when using mobile clients or indeed home workers outside the network need to connect using the URL https://owa.mycompany.com.

From an Autodiscover point of view this means that it is logical to assume that the following domains will be in play:

  • mycompany.com (External)
  • mycompany.local (Internal)

Which means the following SMTP Domains will be used by default:

  • @mycompany.com (primary SMTP)
  • @mycompany.local (Secondary SMTP)

Additionally and in accordance with Microsoft best practices the following entries should be added to the SSL (SAN) Certificate:

  • mycompany.com
  • mycompany.local
  • autodiscover.mycompany.com
  • autodiscover.mycompany.local
  • NetBIOS Name of your Client Access Server
  • External Name of OWA (e.g. owa.mycompany.com)
  • Internal Name of OWA (e.g owa.mycompany.local)
  • Any other SMTP domain which might be the Primary SMTP Domain (more on this later)

What is a SAN SSL Certificate?

SAN stands for Subject Alternative Name – these are also known as “Unified Communication Certificates” which allow for up to 150 server names to be included on one SSL Instance. They are big news for Exchange 2007 and Office Communications Server as you can stipulate many names for one Exchange installation on one SSL certificate.

There are many vendors in the market whom provide such certificates – my personal preference for this article has been based around “GoDaddy” whom provide a really good trade off between security / cost / amount of SAN names.

Don’t get me wrong – I am not a share holder in “GoDaddy” nor is .:Enow affiliated with them in anyway – but when you look at their pricing schedule it does seems to beat the competition “hands down” for small to large enterprises.

An example being for 10 domains (SAN) over 3 years you can pay $131.94 a year which is very reasonable.

Putting together your SSL SAN Domain Requirements:

As an example – if my company’s External domain was called “flangemanifold.com” with the internal AD DNS Namespace being “flangemanifold.local” with a Client Access Server with a NetBIOS name of FM-EXCAS-01 where the External OWA name wasowa.flangemanifold.com and an internal OWA name of OWA.flangemanifold.local and my primary SMTP address for my recipients was<firstname.surname>@flangemanifold.com – I would add the following Names to the SSL certificate:

  • Common Name: owa.flangemanifold.com
  • SANS: flangemanifold.local, autodiscover.flangemanifold.local, owa.flangemanifold.local, flangemanifold.com, autodiscover.flangemanifold.com, FM-EXCAS-01

If you use a Primary SMTP address (this is your “Reply To address”) which is different to both the internal and external domains (for example flangemanifold-trading.com) you should also add this to the SAN Certificate (for example autodiscover.flangemanifold-trading.com) as in the default configuration of Outlook it will begin the “Autodiscover” from the domain which is provided as the Primary SMTP address.

Therefore if my SMTP address is andy@flangemanifold-trading.com the Autodiscover lookup will start at flangemanifold-trading.com – then move ontoautodiscover.flangemanifold-trading.com and so forth.

Tips on getting your SSL Certificate:

You should ensure that all domains that are being used for the autodiscover and the External / Internal names must point at your Client Access Server.

Additionally when you apply for your SSL certificate – you must make sure that you are the REGISTERED admin contact or OWNER, as referenced in the WHOIS database for you external domains  – most SSL certificate issuers (such as “GoDaddy” and “Thwate”) will send an email confirmation to registered OWNER or ADMIN address as provided within the WHOIS database prior to it being issued – therefore if your email address is not down as the contact, you will not get your SSL certificate issued.

For internal (mycompany.local) domains being placed on the SAN Certificate you can provide your own personal email address which will result in the SSL issuer sending the confirmation to your personal address.

Now that we have been through making sure that you have all of the information that you will need during the issuing process – we need to generate the CSR (Certificate Signing Request) that you send to your chosen SSL provider. The CSR is generated on your Client Access Server using the Exchange Management Shell Cmdlet “New-ExchangeCertificate” – however the command syntax can be a little tricky – therefore DigiCert have provided a Web Based interface which allows you to crate the New-ExchangeCertificate Syntax for a SAN SSL certificate here: https://www.digicert.com/easy-csr/exchange2007.htm

Open this site on your Client Access Server and fill in the form then click on the “Generate” button – an example of a completed form looks like the following:

CSR-Digi

When you have clicked on the “Generate” button – open an Exchange Management Shell Windows (this is on your Client Access Server) then copy and past the text which is located in the “Information” window into the Exchange Management Shell and press<Enter>  – this will look like the following if successful:

CSR-Cmdlet

You will now have a CSR file in the root of the Client Access server’s C:\ drive – this needs to be sent to your SSL issuer.

Before we continue some – Pre-Requisites:

Remember that this article explains the configuration for a vanilla out of the box installation of Exchange 2007 for a single Organization which has two DNS namespaces internally and externally.

The LAB Machine that I have used is based around Exchange 2007 SP1 with Rollup 8 running on Windows Server 2008 Service Pack 2.

The following assumes that you have already installed the required files for an Exchange 2007 installation and indeed have the Exchange Client Access Server role installed.

Windows 2003 – RPC-HTTP Component:

In order for OA to function you will need to install the RPC over HTTP Proxy component on your Exchange 2007 Client Access Server. If you are using Windows 2003 this need to be done via:

[ Add Remove Programs –> Windows Components –> Networking Services ]

Choose the “RPC over HTTP Proxy” and then OK out to install.

Windows 2008 – RPC Over HTTP:

Open a Windows 2008 command prompt with Admin Rights and type in the following command:

serverManagerCMD –i RPC-over-HTTP-Proxy

Back to the Film – Installing your SSL Certificate:

At this point your issuer should have sent you your completed SSL certificate in CRT format.

You will need to copy this to a location of you Client Access Server – when you have done this execute the following command:

Import-ExchangeCertificate –Path <path and name to CRT file>

So if you copied the certificate to the CAS Server’s C: drive the CMDLet would look like the following:

ImportCRT

When the certificate has been imported you will be presented with the a completion message (see above) – in order to enable the SSL certificate for use with Exchange copy the value which is presented under the “Thumbprint” heading and then from within the Exchange Management Shell type in the following command:

Enable-ExchangeCertificate –Thumbprint <paste the thumbprint> –Services IIS

See below:

EnableSSLCert

Summary for this part:

By now we should have our SSL certificate installed on the Client Access Server and be getting ready to enter into the main configuration of Outlook Anywhere and Autodiscover – in the next part we will over all the required configuration, setting up Outlook 2007 for connection and some hint on troubleshooting should you run into any problems.