A while ago I had to publish Exchange 2010 services across TMG 2010. All what’s below is more or less from the TMG administrator point of view. All of the tests are done externally (across TMG).
Also, important to note: my customer had an e-mail domain which was different from the Active Directory UPN. E.g.
I believe this information will be important as a lot of the autodiscover GUI pieces only ask for an e-mail address and a password. There’s no room to provide the username. Before diving into Autodiscover & Outlook Anywhere I’m going to go into the basics of publishing Exchange Services across TMG.
For starters, in a typical scenario where all Exchange Services are published there are 3 publishing rules. Each are listed with the defaults paths published as the TMG wizards configure them.
1. Outlook Web Access (OWA)
2. Outlook Anywhere (with support for Outlook 2007 clients):
3. Active Sync
Each of these paths points to a vdir on the Exchange CAS server. Here’s a screenshot of all available vdir’s:
TMG Concepts: The Listener
Now obviously when you are publishing applications there’s got to come some authentication in play. On the internet side of things there’s one or more listeners. A listener determines which kind of authentication method the user on the internet is challenged with. For instance we have Form Based Authentication. In form based authentication the user is present with a nice TMG logo’d form and is asked to provide credentials. So to summarize, as listener is a way for TMG to capture the end user his credentials in a given form.
TMG Concepts: The Publishing Rule
On the other hand we got our applications on the intranet which require credentials to be presented in each request in order to show the appropriate content. This kind of behavior is determined in the publishing rule of each service. One of the items we configure in the publishing rule is the authentication delegation. We have to specify the way TMG can use the credentials it gathered on the listener to authenticate to the service in the backend.
And this is where troubles can begin. You always have to match the authentication delegation settings with the authentication protocols enabled on the vdirs. For instance if you configure the OWA website in Exchange to be available with basic authentication, there’s no point in configuring TMG to publish it with NTLM or Kerberos. The “Test Rule” button in TMG will show you this right away. I often encounter the missmatch where the Exchange Admin configured forms-based authentication on Exchange for OWA. TMG can’t handle this, unless you allow unauthenticated traffic to the Exchange server…. Now if you are an IIS savvy admin you could start tweaking IIS right away from the IIS management console. I would advise against this. All of the IIS configuration for Exchange related web services can be performed to the Exchange Management Shell or Exchange Management Console. Here’s a screenshot for OWA from withing the EMC.
Authentication Protocols for OWA
And finally I get to the subject of this post, how to test if your Autodiscover configuration is running ok. I myself see 4 possibilities:
1. Microsoft Remote Connectivity Analyzer (recommended)
This tool will test the Autodiscover functionality and will provide you the returned XML information. Very complete. It also allows you to disable the SSL verification check which can be convenient if you are messing with non-commercial certificates. And it allows you to specify the user account in the Domain\Username format, which is convenient if your email domain differs from your AD UPN.
2. New Mail Profile using the control panel
Make sure Outlook is closed and then go the control panel.
You can easily add a new profile and configure an Exchange Account:
The great part of this wizard is that it’s able to prompt for additional credentials. You can only provide the e-mail address and the password. But TMG will not accept this. TMG is not able to find a user which matches this e-mail address as a user with this UPN in it’s domain. So to be more precise, the passwords entered over there don’t matter. You will be prompted anyway.
3. New Mail Profile from within Outlook
You’ll be presented with the same wizard of option 2. Disadvantage is that you’ll have to close Outlook before the mailbox can actually be accessed.
4. Test E-mail Autoconfiguration
You can launch the Test E-mail Autoconfiguration wizard by pressing ctrl and right-click the Outlook icon in the tray.
If you launch the wizard you’ll be presented with the following screen:
Now again you’re only asked for the e-mail address and the password. But unlike the configure new profile wizards presented above, this will NOT prompt for your account name in an other format. Somehow it seems to use the same sessions Outlook has established as an application.
So for instance:
- Start outlook
- Add new account from within outlook
- Be prompted for credentials
- Do NOT close outlook when prompted
- Start the e-mail auto configuration wizard
- E-mail auto configuration wizard succeeds
On the other hand:
- Start outlook, don’t configure a profile or connect to an Exchange organization
- Start the e-mail auto configuration wizard
- E-mail auto configuration wizard will not succeed as there are no credentials to be-reused and no prompt appears!
In step 3 this is the error you will receive:
And on the log tab:
The error in words: Autodiscover to https://…/autodiscover/autodiscover.xml Failed (0x800C8203) or (0X80070057)
Test E-mail Auto Configuration Fact #1: it does not prompt for authentication
Besides that, suppose you got a connection using RPC over HTTPS to your mailbox. Try the E-mail Auto Configuration Test and provide the e-mail address of a colleague, fill in a dummy password. Yup, you do receive the information.
Test E-mail Auto Configuration Fact #2: you don’t have to provide the credentials of the mailbox you are querying for, as long as you are authenticated.
I just though I’d share this with the error code as it might lead you to think there are problems with your configuration whilst in fact everything is tip top.