Publishing Exchange Server 2013 using TMG

Published Nov 21 2012 01:40 PM 124K Views

Update 11/28/12: we wanted to let you know that the Forefront Unified Access Gateway (UAG) Product Team team has published a blog post around availability of UAG 2010 SP3 which will include support for publishing Exchange 2013.
Update 5/21/13: The article has been updated to include information regarding Exchange 2013 RTM CU1.

Now that Exchange Server 2013 is available, some of you may well be wondering how to publish it to the Internet using Microsoft Threat Management Gateway (TMG) or perhaps the Microsoft Unified Access Gateway (UAG) 2010.

This post will help you configure TMG, for sure, but not UAG – as for the time being, you can’t effectively publish Exchange 2013 using UAG without turning off many of the security features in UAG. Why’s that? Well, as you’ll have gathered from other posts on this fine blog, we re-wrote Outlook Web App for Exchange 2013. And when an application like UAG inspects Outlook Web App traffic, it gets a little confused when you change everything without telling it. So, the UAG team is busy beavering away re-writing their rule sets to work properly with Exchange 2013, so the advice for now if you have UAG, is to wait for a future UAG update, where it is currently expected that Exchange 2013 support will be added.

So back to TMG. TMG can be configured to work with Exchange 2013, and that’s what I’m going to walk through in this post.

I’m going to make an assumption here (risky perhaps, but if you are reading this post it is highly probable you already have TMG publishing either Exchange 2007 or Exchange 2010) that you're familiar with the existing guidance we have published. It covers the basic configuration of things like certificates, authentication, publishing rules and more – so rather than repeat all that here, we’re just going to focus on the Exchange 2013-specific changes you need to make. If you want to go refresh yourself and re-read that whitepaper, go ahead, this page will wait patiently for your return.

Welcome back. And off we go.

The first thing to know is that there is no Exchange 2013 publishing wizard, but do not panic as you can instead use the Exchange 2010 publishing wizard, and then make some changes described here.

The first thing you will want to actually do is create a new web farm (and I hope you use web farms rather than publish load balancer VIPs or single servers as it makes life much easier in the long run) and put your Exchnge 2013 Client Access servers into it. It’s the same procedure as for Exchange 2007 and Exchange 2010, including the connectivity verifiers; so just go ahead and create a web farm. Here’s mine. It’s a small farm. More of a gentleman’s farm than a real farm, but it will work nonetheless.

Figure 1: Publishing Exchange 2013 Client Access Servers using a web farm in ForeFront TMG

Now you have a web farm, let’s create some rules. But before we get into that, we’re not going to cover the actual cutover here, that’s perhaps another post, we’re just going to run through the rules you need. When it comes to the actual cutover, just to briefly mention it as I’ve started now, and it’s hard to stop typing once you get the flow going, if you have both 2007/2010 web farms and 2013 web farms all you really need to do is change the web farm being used on the To: tab for each publishing rule, and assuming the rest of your Exchange configuration is correct, you just did a cutover. Is that an oversimplification? Sure, but frankly the cutover is as it was for previous versions and if I don’t get to actually writing about the TMG rules for 2013 and instead keep rambling on about things like this then I’ll never get this post finished and you will have given up reading.

Oh, I’m sidetracked again.  Squirrel.  Oh sorry, back again.  Before we can cover the rules we also have to talk about delegation. Delegation is the method by which TMG authenticates, proxies, re-uses (depending on how you see it) or delegates the credentials, of the authenticated user to the Exchange Server it is publishing. At this time, Exchange 2013 only supports Basic or NTLM delegation, it does not support Kerberos Constrained Delegation (KCD) for now, so all delegation must be Basic, or NTLM. If you have no idea what KCD is, welcome to the majority, just make sure you don’t select it ok? So with that last piece of housekeeping out the way, onto the publishing….

Note: The release of Exchange 2013 CU1 added support for Kerberos Constrained Delegation (KCD), so if you know what that is, and how to use it, now you can enable it, and be fully supported.

We shall begin by agreeing that you have used the TMG wizard for publishing Exchange ActiveSync. You have selected the Exchange 2013 CAS Farm as your target and set the correct Delegation setting (typically Basic but it’s your choice if you want that, or to use NTLM, as long as Exchange is enabled for the auth type you have chosen to delegate it should work fine).

What now? Nothing. For Exchange ActiveSync you are done. Move along, nothing to see here. It just works. Well done you.

Given that was so easy, let’s try another. Outlook Anywhere. That must be harder.

You run the Exchange Server 2010 Outlook Anywhere wizard, don’t forget to check the ‘Publish additional folders on the Exchange Server for Outlook 2007 (yes, out of date isn’t it) clients’ option and choosing the Exchange 2013 CAS server farm.

Now, just like before, you may need to revisit the rule the wizard creates, particularly the Public Name tab, and add the name to it, just as you did for 2007 and 2010, and if you are using Basic Delegation you will probably need to go and add basic to the authentication methods enabled on the CAS for OAB and EWS (just as you did for 2007 and 2010), but apart from those few things, you are done. The rule works for 2013, there is nothing else to do.

Wizard Default You Probably Want This
1 2

So at this stage you are probably wondering why we needed a blog post. If this stuff just works, why bother wasting valuable pixels and your time with a blog post. Well, OWA doesn’t work out of the box. So that’s where we need to focus.

The first thing to do is run the OWA Publishing Wizard for 2010. That gets us part of the way there. It creates a rule, which you can tell to prove OWA is working at the most basic level.

Clearly as you test the rule you will see the 2010 OWA Forms Based logon page. Don’t go trying to make it look like 2013 OWA just yet, let’s get the whole thing working before you start fiddling, as I know some of you will. For now, leave it…

So the first thing we need to do is modify the logoff parameter. That has changed between 2010 and 2013 and so the default TMG sets you up with won’t work. This is easy to do. Open the properties of the OWA publishing rule you just created and change the parameters on the Application Settings tab thus;


Wizard Default You DO Want This
1 2

That was easy.

Note: The release of Exchange 2013 RTM CU1 changed the way OWA logoff works, such that the TMG change recommended in this post no longer applies. At the current time there is no way to catch and force logoff at TMG when TMG is generating the form, instead users should be educated to close their browser window (as the pop-up tells them when they click Sign Out from within OWA).

And a small tip for those in a multi-domain environment and running “Get-Mailbox –Arbitration”. You need to run the following cmdlet first: Set-ADServerSettings –ViewEntireForest $true. After that you will “find” your arbitration mailboxes.

Next is the tricky one. Strap yourselves in, this one might be a bit hard to get on the first read.

Outlook 2013 brings to the table a new cloud app model, meaning you can download and install apps that enhance the power of Outlook. OWA has them too, if you have tried OWA 2013 or Outlook 2013 you might have seen the Bing Maps app, the Suggested Meeting app – some really cool apps that you can use out of the box. You can also build your own, integrating into your own in-house systems, for example.

Why am I telling you this? Did the app team want some free advertising? No. It’s really because they don’t work out of the box if you have TMG doing OWA Forms Based authentication in front of Exchange. Why? Well, the apps are surfaced in Outlook via a trident control, which is essentially an instance of IE framed into the Outlook host. The user’s exchange credentials are not provided to the app at runtime. So from a network perspective, the app loading looks like an anonymous HTTP GET, coming from an IE browser. And that request is to a sub directory of /OWA.

So guess what TMG does? Throws up a form, inside the app control window, asking the user to log in. Oops. Not a super user experience it has to be said. It looks a bit like this.


Now the way around this is familiar if you have ever configured Hybrid, or Org Relationships using the Microsoft Federation Gateway. We need to exclude some requests from pre-authentication. We need to craft a higher priority rule than that for /owa/* to catch these requests. Now, this is a bit deep, but I know the readers of this blog are smart, so I’m sure you will follow along.

The request Outlook makes is actually to /owa/ and what makes this more challenging is that TMG won’t allow you to specify path wildcards in the middle of a path, eg. /owa/*/*/owa2/ext/def – not allowed. Wildcards are only allowed at the end of a path – path/path/* is allowed for example.

The good thing here is that / is predictable. (Version on the other hand changes each time you update Exchange). It’s constructed using the ExchangeGUID of the org mailbox with the OrganizationCapabilityClientExtensions capability. You can find this cleverly named mailbox by running the following command on your Exchange Server;

Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like “OrganizationCapabilityClientExtensions”} | fl exchangeGUID, PrimarySmtpAddress

Here’s my example:

[PS] C:\WINDOWS\system32>Get-Mailbox -Arbitration | where {$_.PersistedCapabilities -like "OrganizationCapabilityClientExtensions"} | fl exchangeGUID, primarysmtpaddress
ExchangeGuid : 3eccca51-d996-49df-b6e0-302d644fdcaa
PrimarySmtpAddress : SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}

So once we have those two pieces of information, we take the ExchangeGUID and the @domain part of the primary SMTP address of that mailbox, and construct a string ( like this;

Warning: You should only do this during months with an ‘r’ in them otherwise you may cause a black hole to open and swallow the entire planet. Do not come looking for me if that happens and say I did not warn you.

Now for the TMG rule.

Use the OWA publishing wizard in TMG to create a higher priority rule than that you already built for OWA that contains these settings;

Path Tab: /owa/*

Users Tab: All Users (no pre-auth in other words)

Authentication Delegation: No delegation, but client may authenticate directly.

It looks a bit like this;

3 4


Apply that rule and it should now all work as expected. The rule allows just Outlook 2013 apps to bypass pre-authentication and work as expected.

Here’s my rule, it is higher in the list, making it a higher priority and so it is processed before the generic OWA rule. The rule is more specific to the request, so it applies to the traffic from Outlook apps.



Is this rule opening you up to an attack or some vulnerability you might ask? And you should ask, it’s a good question. Well for one, the Exchange GUID is unique to your organization. So in order to use the rule someone has to figure that out. That’s quite hard unless someone is eavesdropping on your traffic, and if the session is SSL encrypted, which it should be if you are serious about what you are doing, so really it’s a non-issue.

Secondly, you should understand that mail apps activate in context of a given (user selected) message, and only execute (load the source html/js) when clicked on by the user. The app needs to load in context of the Outlook/OWA host for any of the API's to be able to access data via cross-document messaging (in other words, loading the app source directly into a standalone browser instance won't have any message data to access).

What data the app can access depends on the permission level requested by the app (declared in the app manifest, and viewable in the app management EAC page). So as an admin, with the ability to publish apps you approve of to your users, you can ensure only apps you trust can be used.

For more information about requesting permission levels for mail apps, you should review the following topics:

So to wrap up, don’t forget, this new rule has to be higher in the processing order than the regular OWA rule. And if you were to move the OrganizationCapabilityClientExtensions capability to another mailbox, the ExchangeGUID would change, necessitating the rule to be fixed up.

So what else? Nothing. Well, nothing for now. At this stage you should have Exchange 2013 working very nicely through TMG, but if you do have issues, post them here and we’ll try to help.

Greg Taylor
Principal Program Manager
Exchange Customer Experience

Not applicable

So Microsoft’s move to delete TMG from their product catalog from December 1, 2012 is curious. Mainstream support for TMG lasts until April 14, 2015 and the lights won’t fully go out until April 14, 2020, so time is available to find a long-term replacement, probably from a third-party software vendor, who might just follow the line taken by some companies of building specialized appliances in the form of virtual machines. We’ll

Not applicable

Will this make Outlook 2010/2013 on domain connected machine on the Internet use cached credentials of the logged on domain user or will they get an authentication popup once using Outlook Anywhere? As far as I can remember, you need Kerberos Constrained Delegation to get this working?

Not applicable

Nice article. Why is publishing to web farm better than a load balanced VIP?

Not applicable

@ J - This won't solve that no - but if you enable Outlook Anywhere with NTLM auth and want to do pre-auth then you are right, you need to do KCD from TMG to Exchange. This is the doc you want -

@ Gary - Take a look at this - . Personally I think the web farm is the better solution, but there might be scenarios where publishing a VIP might be better - but I doubt it. :)

Not applicable

So, basically, with Exchange 2013 we have to expose an internal server to anonymous access from the Internet, without preauthentication on TMG? That sort of defeats part of the reason for having a TMG in the first place, and if you have an IIS bug the internal server is vulnerable to all sorts of automated scanning and attacks.

Yes, I realize that the URL isn't easily predictible, but since it will be used by every user on every computer they use to log on to OWA, it's not very protected either.

For organizations that need to apply the defense-in-depth principle and require pre-authentication on the perimiter, is there a way to disable these "cloud apps" in OWA and provide the user with an informative message instead?

Not applicable

Mattias, of course you can disable the apps if you feel you would prefer to -

But you know there are more and more customers not doing pre-auth every day. Many of our customers have moved away because it limits scale and performance and 10 years of Trustworthy Computing work has made putting Exchange and Windows together on the Internet,

with just TCP443 available, a risk worth accepting. If you have the skills to know what a DoS looks like, and perhaps back it up with some kind of IDS, then why bother to pre-auth at all is the question....

Not applicable

Thx for this article

i actually use a VM with ISA to publish my Exchange 2013 lab.

everything works fine except outlook 2013 bing map.

i added the specific rule with an higher priority than OWA rule.

Of course, i replaced ExchangeGuid and domain suffix as described in the article.

From an external mailbox, i sent a mail with the following address in the body "123 Fifth Avenue, Kirkland, WA 98033".

When i open the message from Outlook 2013 (Outlook Anywhere) or from OWA, i don't see the Bing's map button.

I checked ISA logs, i don't see requests with the following path /owa/exchangeguid@domain/*

Mail apps are enabled.

I probably missed something but what ? :)

thx for your help

Not applicable

WeetA - try sending yourself a mail, it doesn't need to come from outside. If that doesn't trigger the app, what version of IE do you have installed? It needs to be at least IE9. It's the client (in the case of Outlook) that spots and acts on the address. Are you using RTM Outlook? Or the public beta? I'm not sure the feature was in the beta.

Not applicable


i tried with internal mails sent to myself.

I'm using IE 10 under Windows 8 RTM and Office 2013 RTM (Technet).

Not applicable

Nice how-to Greg. Congrats!

Not applicable

You guys are aware that TMG/ISA has been sunset by Microsoft, right?

I'm not sure what is ever going to take TMG's place as a reverse proxy for Exchange.  Right now, I'm just allowing ports 80 and 443 open to my Exchange 2010 box for OWA and ActiveSync through my Juniper SRX.


Not applicable

Why post this article knowing that TMG Server 2010 will be discontinued a week from now? Why Microsoft?

Not applicable


isn't TMG End-of-Sale? (okay: there are 7 days left, so run to the stores and buy!)

So there isn't too much use of publishing an article for this. But it's nice that you confirm, that UAG isn't the best way to publish Exchange 2013, since UAG is the only alternative, which MS offers (and further more, it's quite expensive).



Not applicable

We've published OWA 2013 behind TMG and didn't have to follow the steps to exclude /owa/ from pre-authentication in order for the apps to work. I've tested both the Bing and Suggested Meetings apps in OWA and wasn't prompted with the form requiring me to log in.

We're running Exchange 2013 RTM.


Not applicable

@ WeetA - odd. Not sure why Outlook wouldn't recognize the address. You said OWA doesn't either? Are the apps disabled?

@ Ronald and Filipp - most Exchange customers use TMG, and can continue to do so even after we take it off the price list, so let's make sure they do it right is what I say. After all, my tv isn’t made any more, it’s been superseded by something else – but that’s doesn’t mean I need to rush out and replace it does it? No, and nor should customers who have, and use TMG.

@ Cory - are you sure you have pre-auth set up? Is your rule set to use Delegation, or is it set to allow clients to auth directly? If so, that's not pre-auth.

Not applicable

MS should address the DMZ.  It was premature to pull TMG and Edge servers.  In fact, they should be combined into one product.  

UAG doesn't make sense as a replacement for Exchange environments, as Exchange is an afterthought on UAG. It was designed for remote apps.  The licensing model doesn't work for exchange either.

Not applicable

@Greg, yes web apps are enabled.

Not applicable


well, i found something strange.

Bing maps button doesn't appear in OWA when the body is:

Comment ca va ?

123 Fifth Avenue, Kirkland, WA 98033

but it appears when the body is:

Ca va ?

123 Fifth Avenue, Kirkland, WA 98033

It doesn't appear too when the body is:

123 Fifth Avenue, Kirkland, WA 98033

Comment tu te sens aujourd'hui ?

It seems that the word Comment (translated from French to "How") cause the problem.

Can you test on your environment ?


Not applicable

@Greg, it's not so simple

No button with:


Comment ca va ?

123 Fifth Avenue, Kirkland, WA 98033

but the button is present with:


Comment ca va ?

123 Fifth Avenue, Kirkland, WA 98033

Not applicable

Greg - I just verified that pre-auth is set up. The rule is using Basic authentication delegation. The listener is using FBA and Windows (Active Directory) as the Authentication Validation Method.


Not applicable

According to what I know the Edge role completely disappear with this version.

So where should we put the Antispam Server in an Exchange 13 architecture ?

Is Microsoft going to provide a solution (Cloud or Software) ?

Not applicable

@Jet Microsoft's Cloud Anti-Spam solution is Forefront Online Protection for Exchange (FOPE) and the next release will be known as Exchange Online Protection. A previous article explains the new product -

Not applicable


If KDC will not be supported, is there a way to integrate Certificate Authentication on TMGs for Exchange 2013?



Not applicable

I have just setup exchange 2013 and am trying to publish OWA.EAS and Outlook anywhere via TMG 2010 fully patched.

TMG is setup as back firewall, the edge has its own firewall.

It goes like this:



Edge firewall (NAT)


DMZ ( - perimeter


TMG (dual nic, one in DMZ and one in LAN)


Exchange 2013 servers (2 x servers running all services setup as DAG)

The routing between perimeter and lan is a route and not NAT, OWA on the exchange boxes is basic auth and this simply worked out of the box, no changes needed, but I cant get EAS or Outlook anywhere to work.

When I test using exchange connectivity analyser for EAS, it fails on the options command - the error clearly shows the internal URL of one of the exchange servers but the port number has been changed to 444.

On the exchange box there is a exchange backend website and this is bound to port 444, but the real client access is using the default website and is bound to port 443 with the correct certs setup.

Anyone have any ideas?

Not applicable

Oh also when looking at logging on TMG while trying to connect, I see the allowed connection but it gets a 403 unauthorised message. Same as the analyser tool.

Not applicable

EAS Virtual directory set for basic auth, Auth delegation on the publishing rule set to basic, using same listener as OWA rule which is working fine and publishing the same web farm (the 2 exchange servers).

Autodiscover is set correctly as far as I can tell, but this is one of the main differences between OWA and EAS so this could be at fault I suppose.

Version history
Last update:
‎Jul 01 2019 04:10 PM
Updated by: