TMG installation problems can be a bit trick to troubleshooting if you don’t know which components are involved, however if you know then things start make more sense. Most of the setup problems that I faced up to now on TMG 2010 (since RTM) were related to ADLDS or some kind of domain connectivity problem. The most two recent examples are described on two articles that I tech reviewed from my friends Bala Natarajan and Niladri Dasgupta wrote:

Last week I worked on an issue where TMG admin was not able to install this brand new TMG to be used as Edge Firewall. The error message that he was receiving was:

Error_Final

After this error the setup process rolled back and finish without completing the installation. As recommended on the previous two articles mentioned in this post, the first step is to review the setup logs and look for more information in order to move the troubleshooting further. In the ADAM Log file we can see the following entry:

log

When you see an error where trust relationship between client and domain is failing, be sure to do your homework, in other words, check:

  • General connectivity with the DC – can TMG access the DC (ping, tracert, etc)?
  • Name resolution – can TMG resolve DC’s name?
  • NIC Binding Order – is the Internal NIC on the top of the binding order?
  • Secure Channel – is the secure channel between the server where TMG is installed and the DC working correctly?

When I hit the third test I found out the problem:

binding_order_final

This was the problem, because Windows (where I was trying to install TMG) was sending the traffic to the wrong interface. Once we moved the Internal to the top, flushdns (with ipconfig) and ran the setup again the issue went away and the installation finished successfully.

Note: same recommendation to have Internal on the top applies to UAG, check it out a great reference on that written by Jason Jones at http://blog.msedge.org.uk/2010/04/recommended-network-card-configuration_14.html