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 188.8.131.52, with my lab firewall NAT’ing that IP to the DMZ IP of 172.16.3.22.
For the OCS Webfarm I will be using the public IP of 184.108.40.206, with my lab firewall NAT’ing that IP to the DMZ IP of 172.16.3.56.
Here’s the way we will be separating the IP addresses:
UAG IP For OWA: 172.16.3.22
TMG IP For OCS: 172.16.3.56
If you’ve ever installed UAG you have most likely noticed it utilizes IIS, and bind’s all the IPs (0.0.0.0) 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 127.0.0.1).
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:
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 0.0.0.0 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 0.0.0.0, open a command prompt (run as administrator if required) and type the following commands:
add iplisten ipaddress=127.0.0.1
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 172.16.3.22 :
add iplisten ipaddress=172.16.3.22
Once that is completed we can re-run our “netstat –ano” command to verify 0.0.0.0 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 0.0.0.0:
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.