Let’s start this post about Exchange with a common question: Now that Microsoft has stopped selling TMG, should I rip it out and find something else to publish Exchange with? I have occasionall...
Updated Jul 01, 2019
Version 2.0
Blog Post
I commented on Linkedin on this same discussion point, TMG/Exchange. I fully concur with Greg.
The decision to deploy TMG depends on your business's security profile. At the end of the day its just not a requirement anymore and is entirely optional. For web services only 443 needs to be accessible which as you know Exchange accommodates for web service workloads as the traffic is encrypted.
But if your InfoSec department mandates no direct connections from the internet then TMG considering you already have it deployed is an option. But deploying TMG simply for pre-auth and termination of web traffic in a DMZ, with the current version(s) of Exchange represents only anecdotal 'increases' in security at best. You could also view it as lessening your security as its represents an additional component in your Exchange deployment.
These are only decisions that you can answer by talking to the relevant teams in your organisation responsible for these decisions. Personally though i think its time for InfoSecurity teams to start understanding the changing application layer landscape instead of repeating and implementing the same sage habits simply because it makes them feel warm and fuzzy about how 'secure' their environment is. As Exchange since Exchange 2003 has never required a reverse proxy.
Building on the above i don't see the point in using IIS-ARR for Exchange either. For Lync a reverse proxy is a mandatory requirement for publishing web traffic for services such as mobility that have to connect via a RP. But whats the point of using IIS-ARR for Exchange when it adds no additional security nor inspection of web traffic to your deployment if securing web traffic is the goal.