After Microsoft announced that they will not be developing ForeFront Threat Management Gateway (TMG) anymore, and that this product, together with UAG is end-of-life (you can see more about this here), a lot of people I work with were pretty confused. To most of them, words “end-of-life” sounded like “not supported anymore” which is not the fact. However, from technical perspective, most clients I work with were worried about how to publish Exchange server without TMG.
In this post, I will try to cover most common scenarios with Exchange+TMG and ways how to handle these scenarios in near and far future. You’ll see that things are not as black as they might look at first sight.
First, let’s remind ourselves what TMG actually does for Exchange server. TMG 2010, as firewall/proxy/caching solution, is, among other things, capable to provide application level publishing for Exchange Server, instead of doing that just on transport layer. This means that instead of just forwarding (and protecting) HTTPS and SMTP traffic to your Exchange, TMG is actually “aware” that it has Exchange behinds its back. Because of this fact, it can impersonate Exchange server in some scenarios (for example, for OWA), terminate client connections on itself, authenticate users and then connect to Exchange to fetch the content for the user. TMG is using, so called, listener components to securely publish Exchange (and other) services to the Internet. For the Exchange publishing scenario, listener component is, for example, able to generate form based authentication page for OWA, securely authenticate a user, and then establish the connection to the Exchange server CAS. Besides, TMG was also able to securely publish your SMTP or SMTPS to the Internet, as well as to protect that kind of traffic from malware. This kind of publishing was very convenient for a lot of companies. I mostly work with medium to large companies, and quite a lot of them were using TMG to publish Exchange servers to the Internet, because solution is affordable, reliable, easy to deploy and manage and showed up to be very secure. Of course, there some downsides of using TMG for other purposes, but quite often I was seeing dedicated TMG just for Exchange publishing. In much more rare cases, UAG was also used to protect Exchange, but since it is also EOL, situation is actually the same.
The question we have now is what to do with Exchange publishing in post-TMG/UAG era. So, let’s see some most common scenarios you might run into.
Scenario 1: You already have TMG 2010 and Exchange Server 2003/2007/2010 deployed. What are your options? I want to be very clear on this point: Although TMG is end-of-life product, this does not mean that you have to look for another solution immediately. TMG 2010 will still be supported until year 2020, per support lifecycle policy for this product. This gives you quite a lot of time to find another solution, while still using fully supported configuration. So, no reason to panic, there’s a plenty of time left to think about other options. Make sure that you update your TMG server on regular basis, and you’ll be fine.
Scenario 2: You already have TMG 2010 and Exchange Server 2003/2007/2010 deployed, but you are planning an upgrade to Exchange Server 2013, and you know that TMG does not natively support Exchange Server 2013 publishing. What should you do? Yes, it is true that TMG does not support Exchange Server 2013 publishing out-of-the-box, but there’s pretty simple solution to make it work. First, you don’t need to worry about SMTP publishing – it works as before. You just have to direct your SMTP publishing rule to Exchange Edge server (available only in Exchange Server 2013 SP1) or to Client Access Server (if you don’t have Edge, in version 2013, incoming SMTP is handled by CAS server in Exchange 2013). For publishing Exchange web-based services, such as OWA, OA or Active Sync, you’ll have to run new publishing wizard, select the option to publish Exchange 2010 (as you’ll not have 2013 available), and after you create the rule, you will have to do some small fixes in publishing rule you just created. There’s a great post from Greg Taylor, Principal Program Manager from Exchange PG, that covers this, step-by-step, and you can find it here. Basically, in most cases, you’ll just have to adjust the URL for OWA logoff, which has changed in Exchange 2013. However, if you decided to go with latest and greatest technologies, and use MAPI over HTTP functionality (supported only when using Exchange Server 2013 SP1 with Outlook 2013 SP1), you will also have to add /mapi/* virtual directory path to Outlook Anywhere publishing rule, as this folder was not published before by Exchange publishing wizard. This is not mandatory thing to do. Exchange Server 2013 SP1 can also work with MAPIoverRPCoverHTTPS client connections, like Exchange 2010, but if you have Outlook 2013 SP1 clients you can also enable MAPI over HTTP as it brings several performance and stability enhancements. You can see more about this in great article by Tony Redmond here.
Scenario 3: You already have some 3rd party publishing solution in production, for Exchange Server 2003/2007/2010 publishing, and you’re planning to upgrade your Exchange organization to Exchange Server 2013. In this case, most important is to test your current solution with Exchange Server 2013. It might require some modification to the current publishing configuration, but in most cases, you will be good to go with what you have. If your current solution can’t work with Exchange Server 2013, or you want to replace it for any reason, look for the next scenario.
Scenario 4: You are planning to deploy Exchange Server (in any version) but you don’t have a publishing solution or your current solution does not work with version of Exchange you’re about to deploy and publish. In this case, things can be a bit complicated. First, you should be very clear on what you’re publishing. For the Exchange server, in most cases, you will want to publish SMTP (so your Exchange can receive emails from the Internet) and HTTPS-based services such as Outlook Web App, Outlook Anywhere, Exchange ActiveSync and, in some less frequent scenarios, Exchange Web Services. One of the very nice features of TMG is that it is capable to securely publish all these services, while providing attack protection at the same time. But, you are not able to buy TMG anymore. As said before, it is still supported, but not on the market to buy anymore. That leads us to situation where we must find solution to securely publish SMTP and to publish HTTPS based services. If you are looking for hardware (or virtual) appliance to solve this, most likely, you’ll have to look for two solutions instead of one, like with TMG. You will need one solution for publishing of web-based Exchange services, and another solution for securing and publishing the SMTP. In this case, budget becomes a very important factor. So, let’s look a bit deeper into these scenarios.
Scenario 4.1: You have a very limited budget, but you need a solution that works. I hear this all the time J. Well, actually there are solutions for this scenario, which can be almost free. Instead of using TMG (which was, by the way, pretty affordable), you can achieve reverse proxy functionality by using Application Request Routing component for IIS. This is an extension for IIS in Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, and it’s free. To use quote from Microsoft, IIS Application Request Routing (ARR) 3 enables Web server administrators, hosting providers, and Content Delivery Networks (CDNs) to increase Web application scalability and reliability through rule-based routing, client and host name affinity, load balancing of HTTP server requests, and distributed disk caching (end of quote). Well, we can also use it to load balance and publish Exchange Web services. It is not complicated for deployment, and if you choose to go this way, you can find a very good guide on how to configure it here. You might have noticed that ARR is not supported on Windows Server 2012 R2. This is because 2012 R2 provides another technology for similar purpose – Web Application Proxy. Unlike ARR which is an extension to IIS, WAP is the subcomponent of Remote Access role in Windows Server 2012 R2. It actually replaces AD FS Proxy from previous Windows versions, but it also provides some publishing functionality. WAP is free, as it is included in Windows, but it requires some more administrative time to deploy and configure. It requires that you deploy AD FS on separate machine to make WAP work. With WAP, you can also use AD FS based authentication. If you have Exchange only on-premise, this might not be very attractive option, but for hybrid deployments with Office365, WAP is a great solution. If you decide to give it a try, you can find good step-by-step instructions to set it up here. However, ARR and WAP can’t publish SMTP for your Exchange server, so you will need another solution for that.
For the SMTP, you’ll need to address multiple keypoints. From the aspect of Exchange, it is very important if you are using Edge role or not. If you are, then you can deploy Edge server (or servers) in DMZ, and publish SMTP on the firewall. You can activate anti-spam agents on your Edge server, and stop most of the dirty SMTP traffic before it enters your internal network. However, you still have to deal with antivirus protection. As a part of Microsoft decision to shut down Forefront family of products, Forefront for Exchange server is also not available anymore. You can go with a third party antivirus solution, or you can choose Exchange Online Protection from Microsoft. If you don’t already have some on-premise AV solution I recommend that you seriously consider Exchange Online Protection. Yes, I know, that emails are going through Microsoft servers before they reach you, I’ve heard this argument a hundreds of times, with all variations of NSA-related conspiracy added to the story. I’m not going to elaborate on that, but will just say that if your email will be going through Microsoft servers before it reaches your Exchange, that will certainly be one well-known point in its path. Do you know anything about others?
Scenario 4.2: You have some budget to spend on Exchange publishing solution. Good for you J. In this case, I recommend that you look for some solutions from F5 and Kemp. I’m not actually promoting any of their products, but in Exchange community these are proven to be reliable and secure solutions for Exchange publishing. With some of the products they are offering, you can publish and load balance both HTTPS and SMTP. Also, if you are looking for a good (but not cheap) SMTP AV/AS/gateway solution, you should definitely check on Cisco Ironport Email Security appliances. I’ve seen these working in a production, and I’m pretty amazed by effectiveness they provide.
Feel free to comment on this article. I tried to summarize some solutions, based on my from-field experience so far. I’m not saying that this is all, but I hope it will help some people to go in to the right direction.