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.

• thomas@customer.local (AD UPN)
• thomas@customer.com (E-mail domain)

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:

1. Start outlook
2. Add new account from within outlook
3. Be prompted for credentials
4. Do NOT close outlook when prompted
5. Start the e-mail auto configuration wizard
6. E-mail auto configuration wizard succeeds

On the other hand:

1. Start outlook, don’t configure a profile or connect to an Exchange organization
2. Start the e-mail auto configuration wizard
3. 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.

Happy Discovering!

One of my colleagues had a project where they though it would be a good idea to restrict the amount of cached logons to 1. This would ensure only the last logged on user (the owner) would be able to use the computer off the network. This way the credentials of privileged users such as helpdesk employees wouldn’t be cached.

However when they set the setting to 1 it seemed like even the user itself couldn’t log on any more. Well here is some explanation: http://blogs.technet.com/b/instan/archive/2011/12/06/cached-logons-and-cachedlogonscount.aspx

Basically there’s also other processes filling up slots of the cached logons, and it’s hard to take these into account. So I’d say it was never meant to be set THAT restrictive.

Ever modified something in IIS and then wanted to revert but forgot what setting it actually was? Or ever been in a lot of trouble, you know somebody changed something, but not what? Well seems IIS keeps backups of the configuration files for you!

You can find them in c:\inetpub\history

I don’t think they’ll be created when you manually modify those xml configuration files. Might be interesting to check if performing modifications through appcmd make it here. I would guess so.

I’m currently setting up a new ADFS infrastructure, and one of the things I’m still struggling with is the Token Signing/Decryption Certificates. From TechNet I read (Certificate Requirements for Federation Servers) it’s recommended to use certificates from your own CA. You can go to a third party, but this would cost you more. You could use the same certificate as used for the ADFS web services, but then that’s against best practices. You could also stick with self signed certificates and thus benefit the automatic certificate rollover feature ADFS offers (TechNet Wiki: AD FS 2.0: How to Replace the SSL, Service Communications, Token-Signing, and Token-Decrypting Certificates) , but if I’m correct when rollover occurs you still have some work updating the Relying Party trusts if these don’t support automated Federation Metadata updates through the ADFS metadata URL. As this probably remains a manual task for certain RPs, I‘d rather stick to proper certificates then anyway. So here comes the customer Certificate Authority to the rescue!

When installing ADFS using a SQL database to store the configuration, you have to use the fsconfig.exe command line tool. Paul Williams made a nice write-up regarding the parameters for this utility: Deploying a federation server with a SQL database.

This command actually seems pretty easy:

fsconfig createsqlfarm /serviceaccount DOMAIN\S_ADFS /sqlconnectionstring "database=ADFSConfiguration;server=SQLSRV\SQLInstance;integrated security=sspi"   /cleanconfig /signingcertthumbprint "fd fd fd 10 55 0b df 63 3b 56 65 2b e1 c7 97 bf 6e 83 fc 1b" /decryptcertthumbprint "77 77 77 c3 8b cb bd bc 5b a0 3a 9d 5d af 8c 57 08 f9 ce 91"

Now this command is supposed to check the default website in IIS for the certificate bound to port 443 and it should extract the subject of the certificate (sts.customer.com) and use that for the ADFS Server URL. So obviously IIS has to be properly configured for HTTPS first. Here’s the error I received:

In words: The following error occurred: The Federation Service name that was determined from the Subject field of the specified certificate is not a valid DNS name. Specify a certificate with a valid Subject name for the Federation Service DNS name, and then try again.

Some remarks:

• My certificate was based upon a web server template, and was requested from within IIS 7.5 MMC, specifying sts.customer.com as subject
• Changing the thumbprints to a format without spaces didn’t help for this issue
• Originally I specified another name for the database, e.g. ADFS_Test_Configuration, the utility happily ignores this and created ADFSConfiguration & ADFSArtifactStore nevertheless…
• I tried adding a SAN attribute to the ADFS Web certificate, with the subject (sts.customer.com) as value, didn’t help for the issue
• I tried specifying the certificate thumbprint for the ADFS Web Certificate, I tried specifying the name to be used for the ADFS Service URL, and I tried combining both parameters in the command. All failed…

At some point in time, and after googling a bit, I found this similar case: TechNet FSConfig Errors. No answer though… So I decided to leave out the /signingcertthumbprint and the /decryptcertthumbprint and just use the /autocertrolloverenabled instead. This would configure to use SQL and it would still extract the subject from the ADFS Web Certificate. Guess what, now it was able to do that…. So I ended up using the ADFS PowerShell cmdlets to get my custom certificates in place as I tried to do with the fsconfig utility. Here’s what I did:

1. Disable automatic certificate rollover
2. Add my custom Token Signing\Decryption certificates
3. Set them as primary
4. Remove the self singed ones

It would be great if anyone could provide me feedback as to whether I’m doing something wrong, missing a prerequisite, or if this is just a bug.

Just a quick tip: often after an IIS or TMG project security audits are performed. One of the remarks we often get is that SSL 2.0 is enabled on the web server. To disable this you can simply set the required reg key as explained in KB187498

A customer of mine wanted to use the built-in windows update of Windows Server 2008 R2 to apply the latest security patches. When they clicked check for updates they received the following error:

In words: An error occurred while checking for new updates for your computer. Error Code 80072EE2

I’ve came across this in the past and I know google would lead me to a solution in 1-2-3: http://tmgblog.richardhicks.com/2010/08/07/running-windows-update-on-a-tmg-firewall-fails-with-result-code-80072ee2/ The solution mentioned over there is to point the SYSTEM to the TMG for http requests. This can be done by executing the following command from an elevated command prompt:

• netsh winhttp set proxy localhost:8080 [when 8080 is your proxy port]

Thinking all would by fine I clicked try again.  And guess what, it failed again, but now with a slightly different error: 80072F8F. I googled and googled, tried some workaround for which I doubted they would work, but finally I came across this page: http://bent-blog.de/wsus-fehler-bei-der-synchronisierung-fehler-0x80072f8f-bei-windows-update/ I only read it diagonally as I can manage to understand German, but not that great. But I saw some screenshots which resembled a lot to my case.

The reason seems to be the absence of a root certificate in the trusted root certificate store. You can easily verify this by opening https://www.update.microsoft.com on the TMG server. If you receive a certificate error, you might be suffering the same problem. I just took the missing root certificate (GTE CyberTrust Global Root) and added it to the trusted root certificates of the computer certificate store. And voila!