Nexus: News

1. On a domain-joined workstation Outlook (2007 or later) sends a query to Active Directory for the Autodiscover information. The directory returns a list of Service Connection Point (‘SCP’) objects. If you have lots of CASs then you’ll have lots of SCPs but Outlook will just select the first one in the list. The SCP should have all of the information needed to configure the Outlook client.
   Now we don’t have any domain-joined clients so an AD query can’t happen: our clients must get the information another way. Autodiscovery for these clients relies upon finding a fully qualified domain name based on the user-supplied SMTP address. In our case it’s therefore a variation on the theme of https://autodiscover.<unit>.ox.ac.uk.
   Incidentally, the same internet-facing CAS must host the normal OWA URL as well as the Autodiscover one so a Unified Communications or Subject Alternate Name certificate is needed for a secure connection. Microsoft’s KB 929395 has a limited list of officially supported suppliers… 
   Behind the scenes autodiscover also takes care of Out-Of-Facility (‘OOF’) messages, availability, offline address book downloads and a few more besides.
   Where were we? Oh yes, how it’s supposed to work.
2. We only have one site as far as AD is concerned (yes, in reality it’s not,  but our 10GB inter-site link means we don’t need to tell the servers)  but if we did SCP would also deliver appropriate site information back to the client. For ‘in site’ users there would be autodiscoversitescope data (an attribute set via the set-clientaccessserver cmdlet) which identifies the site for which it’s authoritative. For ‘out of site’ clients they’ll just get a list of the oldest SCP objects. That’s us, so our users ought to see the oldest Exchange 2007 CAS first.
3. Outlook will use the first SCP in its list to contact Autodiscover. Even someone logging into their Exchange 2010 mailbox or a brand-new user will begin with the Exchange 2007 SCP as it is usually the first record in the list.
4. At this stage all of our users are still on Exchange 2007 so it’ll be a 2007 CAS that receives the Autodiscover request. Later on, once we’re migrating users, there’ll be a time when the the user’s mailbox is on Exchange 2010. At that point the 2007 CAS must redirect the request to an Exchange 2010 CAS.
5. The client will receive an HTTPS response from the autodiscover service containing an XML file. This file includes the connection settings but also the URLs for all of the configured Exchange services.
6. Outlook can use this information to configure (new users) or connect (existing users) to our Exchange servers.

Now to get a better indication of what’s going on there are useful tools, such as TestExchangeConnectivity.com, and for test purposes only it’s very useful. But as it requires you to provide your password of course it should NEVER be used for production account testing. In our case, the multi-domain element of our service, with different email domains for different colleges and units, makes for an added challenge. Microsoft’s White Paper on this subject suggests options including allowing Outlook to give up on a secure session and drop back to HTTP or, as we’ve done, rely on redirection. With this method users do get prompted to ask if they’re happy for our server to configure their connection but that’s a small price to pay to ensure a secure session. To minimise certificate errors one option is to configure both the internalURL and externalURL to point to the CAS’ external name on its’ certificate (this will need split DNS to make it work).

So, that’s the theory.

In practice what we seemed to see today is clients apparently being directed to – and searching for – configuration data via our ‘legacy’ certificate freshly installed on our not-yet-in-production Exchange 2010 CASs. Of course the conventional approach is to use the ‘legacy’ certificate for the Exchange 2007 CASs during the coexistence phase, with the normal certificate on the Exchange 2010 CASs. Our approach at this stage differed from this because we had been hoping that, prior to transferring our clients to the Exchange 2010 CASs, we’d be able to use that certificate for client testing. This testing requirement was largely borne out of our experience that, for example, different implementations of Android behave in very different ways when CAS redirection takes place.

Now the behaviour that we actually saw was a few desktop Outlook clients picking up the legacy certificate data from the Exchange 2010 CASs, without being prompted to look there. This wouldn’t have been so much of an issue if we’d had external DNS entries, certificates also installed on the ISA servers and CAS/ISA rules in place. But we’d deliberately avoided that: only the clients we were specifically testing at that time were supposed to see that address, via manual configuration. So the address that Outlook was finding was an unresolvable one – in the short term this necessitated a quick bit of fixing work and in the longer term it’s prompted a re-think on our approach to testing.

Further diagnostics are under way.