Autodiscover is a standard feature in Exchange Server 2007 and higher that’s being used by Outlook 2007 and higher. Looking at the number of questions I get regarding autodiscover I’ve written a number of blogposts that will look into Autodiscover in depth:
- Autodiscover Part I – Introduction Autodiscover and Outlook on a domain joined client
- Autodiscover Part II – Outlook on a non-domain client (this post)
- Autodiscover Part III – 3rd party certificates and your own PKI solution
- Autodiscover Part IV – Using different SMTP domain names
In Part I I’ve explained how domain joined clients work with autodiscover information that’s stored in Active Directory. This is easy for domain joined clients that have access to the internal network, but it’s a bit different for domain clients that have no access (i.e. working from home or a hotel) and for non-domain joined clients. The latter don’t have access to Active Directory and there cannot query AD for the Service Connection Point of course.
In this post I’ll discuss the same client as in Part I, but this time when there’s no access to the internal network (and thus no access to Active Directory).
Outlook on a domain client without (AD) connectivity
In the previous post there was a domain joined client that connected to the Exchange Server using RPC. When the self-signed certificate is added in the client’s certificate trusted root then Outlook Anywhere will work as well on the internal network, including all Autodiscover functionality.
It is possible that this particular client has no access to the internal network, for example when it’s a laptop that’s not in the office. In this scenario Outlook has to communicate with the Client Access Server across the Internet, and that’s only possible using Outlook Anywhere.
Please note: in these blog posts I’m working with a default installation without any additional configuration changes like the –internalURL and –externalURL. Just Exchange 2010 ‘out of the box’. Only the external facing domainname is set during installation to ‘webmail.contoso.com’. Outlook Anywhere is using the samen FQDN!
The Client Access Server has only the self-signed certificate installed with the NetBIOS name and the (local) FQDN ams-exch01.contoso.com. Therefore the Client Access Server can only be contacted using this FQDN. So, in this scenario the FQDN ams-exch01.contoso.com needs to be externally resolvable (in the public DNS). Quite a lot of times this step is forgotten, just like the FQDN autodiscover.contoso.com which needs to be externally resolvable.
Figure 1. Then Exchange environment needs to be externally accessible.
At this point OWA will not cause any problems of course. Just use the browser and navigate to https://ams-exch01.contoso.com/owa and the logon page will be shown without any issues.
When Outlook 2010 is started it will try to setup a connection using HTTPS. Outlook will setup the connection because the name of certificate matches the external FQDN (i.e. ams-exch01.contoso.com). But here’s the issue: since Outlook cannot query for the Service Connection Point (SCP) is will query public DNS for the FQDN autodiscover.contoso.com. The accompanying IP address points to the Client Access Server. But when Outlook contact the CAS Server using this FQDN a warning message will be shown “The name on the security certificate is invalid or does not match the name of the site”. This makes sense since the autodiscover FQDN is not available in the self-signed certificate!
Why does Outlook query for this particular autodiscover.contoso.com FQDN? It is based on the right part of the primary SMTP address, in this case contoso.com. If the e-mail address would be for example john@woodgrovebank.com Outlook would query for autodiscover.woodgrovebank.com.
Figure 2. The well-known certificate warning.
Click on “Yes” in the pop-up window and despite the certificate mismatch Outlook will setup a connection.
If a Test e-mail autoconfiguration is performed (uncheck the Guesssmart and Secure Guesssmart Authentication) and we’ll see that a connection is setup with https://autodiscover/contoso.com/autodiscover/autodiscover.xml:
Figure 3. Despite the certificate warning a connection is successfully setup.
If you select the Results tab the information sent from the Client Access Server to the Outlook client (the XML tab shows the actual XML package).
Figure 4. This is the information retrieved via Autodiscover from the CAS Server
As long as the Outlook profile already exists it will work with the self-signed certificate, but you cannot suppress the certificate warning. Also the additional services like free/busy, OAB downloading and setting the Out-of-Office are just working.
The question at this point is, is Autodiscover able to retrieve information and construct a new Outlook profile via het Internet? Outlook is not able to query Active Directory for an SCP record (just like the previous step) and will therefore try to access the autodiscover.contoso.com (based on the e-mail address) FQDN.
Starting Outlook looks familiar; enter Name, E-mail Address and password:
Figure 5. Start Outlook and create a new Outlook profile
Outlook will now setup a connection with autodiscover.contoso.com and a certificate warning is shown:
Figure 6. Certificate warning because the autodiscover FQDN is not in the certificate.
To continue just click Yes and autodiscover will show another logon pop-up, again enter the credentials and finish the wizard. The Outlook profile will be created successfully and notice we have achieved this using the original self-signed certificate that was created during the Exchange installation!
Now start Outlook and enter the username and password. Again a certificate warning is shown “The name on the security certificate is invalid or does not match the name of the site”, but now with the webmail.contoso.com. Again this makes sense, it is the externalURL we’ve set during installation of Exchange 2010 on the Client Access Server. And this FQDN does not exist on the self-signed certificate.
Figure 7. A certificate warning is shown due to the externalURL value not available on the certificate.
Again click Yes and Outlook will start. Because we force Outlook to use the wrong certificate Outlook will continue normally and the Test E-mail Autoconfiguration will just work and show the proper results:
Figure 8. Autodiscover values of the domain joined client on an external network.
You will also see that the options like Free/Busy, the OAB download and setting the Out-of-Office will continue to work, even with the self-signed certificate:
Figure 9. Even Out-of-Office works with the self-signed certificate
Summary
As we’ve seen in Autodiscover Part I Outlook 2010, Exchange 2010 and Autodiscover will just work with the self-signed certificate on the internal network (ok, with some tweaking of the client). The same domain joined client will also work on an external network (i.e. the Internet) including functionality like Out-of-Office, OAB downloads and the Availability Services.
The issue is the certificate warning that will be shown (too) often, but you can force Outlook through these certificate warning and continue working. The certificate warnings are caused by the fact that only the internal FQDN of the Client Access Server is on the self-signed certificate, while the webmail.contoso.com (set during initial installation of the CAS Server) and the autodiscover.contoso.com FQDN’s are not available on the certificate.
But despite the error message, at least it’s working
And again: this is nice for testing purposes, but for a production environment it’s better to use a real UC certificate, whether it’s from an external PKI or from a 3rd party certificate vendor. And that’s the topic for my next blog 🙂
Jaap Wesselius 
2 thoughts on “Exchange 2010 and Autodiscover Part II”