OCS Reverse Proxy from Forefront TMG on a UAG Server – Getting Some Bang For Your Buck

As you may have guessed by the title, I get paid by the acronym….

With the release of Microsoft’s Forefront Unified Access Gateway (UAG) many companies have found a very useful product to securely publish applications such as OWA, Direct Access and SharePoint (among many, many others) from one place.  UAG also includes a TMG server built into it, which you can utilize as a reverse proxy for OCS or other applications you don’t want to require authentication for.  Microsoft even has a great support article detailing what is and isn’t supported here.  The article very clearly states you can utilize the TMG on your UAG server to publish OCS (although it doesn’t specify which roles); however making it all work is not as intuitive as one might hope.  With that in mind, I’d like to share what I learned while working on a recent deployment to help others who want to utilize their UAG for other purposes.

For starters let’s talk about the network; here is what my lab looks like for this scenario:

As you see in the diagram I have placed one NIC of the UAG into the DMZ network, and the other on the LAN.  I recommend having another firewall between the UAG’s “inside” interface and the LAN whenever possible but I didn’t have enough resources in my lab to make this work.

For this scenario I will be publishing OWA/ActiveSync with the UAG, and the OCS Webfarm FQDN (Address book, etc…) with the TMG.

For OWA I will be using the public IP of, with my lab firewall NAT’ing that IP to the DMZ IP of

For the OCS Webfarm I will be using the public IP of, with my lab firewall NAT’ing that IP to the DMZ IP of

Here’s the way we will be separating the IP addresses:



If you’ve ever installed UAG you have most likely noticed it utilizes IIS, and bind’s all the IPs ( on the boxes external NIC to IIS (sort of taking them hostage for UAG’s sole use).  Although this is perfectly fine if you plan to use the box only as a UAG server, it doesn’t work so well if you want to utilize the TMG role as well.  What we need to do is add bindings for only IP addresses we intend to allow UAG to control (and

Let’s get started.

First we can examine how the IPs are bound on each port by opening a command prompt and running the following command:

Netstat –ano

The output of this command will be pretty long, if you’d prefer you can send the output to a text file by adding “>c:\ports.txt” to the end of the command:

Then you can open the file and see bound to port 443 for PID #4, if you open task manager and go to process, you can see the PIDs for each process, 4 is the system:

Now on to unbinding the, open a command prompt (run as administrator if required) and type the following commands:



add iplisten ipaddress=

The above command reminds the binding for all IP address on the host.

Now, we need to rebind all IP addresses we want UAG to listen on, for example, the command below will allow the UAG to use :

add iplisten ipaddress=

Once that is completed we can re-run our “netstat –ano” command to verify is no longer bound to 80/443, instead we should see only the IPs we specified in the “add iplisten ipaddress=” commands.  You’re output should look like below, notice 443 is no longer bound on

At this point we have freed the hostages so to speak, and we can now use the TMG and UAG on the same server with different IP address allocated to each.  On to configuring your reverse proxy for OCS, for that I’d recommend checking out Randy Wintle’s  excellent article on the subject over at the UC Made Easy site here.  It’s a great article that I’ve used for reference a number of times and send many other folks to, so I won’t re-invent the wheel.

As a side note, although this article is specifically about the UAG and TMG, it can be directly related to OCS implementation which is why I’ve chosen to publish it here.  I hope this article helps someone out there and as always welcome any feedback.



About Kevin Peters

My name is Kevin Peters.
This entry was posted in Uncategorized and tagged , , , , , , . Bookmark the permalink.

13 Responses to OCS Reverse Proxy from Forefront TMG on a UAG Server – Getting Some Bang For Your Buck

  1. Greg says:

    Thank you so much for this article! I’ve been trying to publish OWA through TMG with portals running on the UAG server for days now with no luck.
    Adding the IP listen addresses fixed it all up.
    Many Thanks!

  2. Kevin Peters says:


    I’m happy the article helped you! Thanks for reading and posting a reply!


  3. Hello,

    I thought the idea of UAG was to let it do all the TMG work (mostly)? I personally use multiple IP’s (as you kinda have to if you want your UAG server to be more than a one stop pony) so I can publish OWA and sharepoint on different namespaces and thus different certs.

    That all being said I have to say that the unbinding trick is very clever and I will be keeping that in my tool belt 🙂


  4. Kevin Peters says:

    Hi Zach,

    Although the UAG is meant to take over much of the ISA workload, for things like OCS Address Book it isn’t supported. For that you need a TMG, and since the TMG install is already there on the UAG why not use it right?

    Thanks for reading!

  5. Jason Jones says:

    Hi Kevin,

    I have provided an alternative (more UAG native) option here: http://blog.msedge.org.uk/2010/10/publishing-ocs-2007-r2-web-components.html

    Hope this is useful…



  6. Kevin Peters says:

    Hi JJ,

    I’ve read through the article and like it. I’m not as deep on the UAG/TMG front so this article was written with help of a Microsoft engineer. I’m actually speaking with them on supporting this option, the big catch is being able to re-bind, not sure that will happen so it may not become a supported scenario.

    Either way good article and thanks for posting.


  7. Clive says:

    Would be interested to know if you have tried OCS 2007 R2 using UAG DirectAccess to Windows 7 Enterprise Clients ?

    • Kevin Peters says:

      Hi Clive,

      I haven’t tried that, usually when using DirectAccess you configure your rules so Lync traffic doesn’t go through the UAG and instead uses the Lync/OCS edge servers. This would be better on a number of levels including performance as the edge is purpose built to transport media and UAG isn’t.


  8. Wes says:

    My Lync deployment would have been 1000 times harder without all you have published. Thanks for doing this.

  9. Tom Pacyk says:

    Kevin, is there any supportability statement or any official document around this operation?

  10. Juanjo says:

    Thanks for making it much easier to publish Lync.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s