TMG available as SecureGuard appliance after Dec 1

In this Announcement Availability of Microsoft Forefront TMG 2010 on SecureGUARD Appliance Series from SecureGuard we can read that. “As announced by the Microsoft Server & Cloud Blog, Microsoft Forefront TMG 2010 will be discontinued and will be no longer available for purchase as of Dec. 1, 2012. Nevertheless SecureGUARD Appliances with TMG 2010 licenses will be available for purchase significantly longer than Dec. 1, 2012.”

My supplier tells me that SecureGuard at the moment plans to support their TMG appliances until 2023.

Read about all SecureGuard appliances and offerings on

Interested in buying SecureGuard appliances? Contact me at or just comment on this post.

Installing TMG SP2 on UAG

I get a lot of questions from my customers if they should install TMG SP2 on their UAG server. The short answer is Yes. The longer answer is…

The answer from Microsoft when asking about TMG SP2 support on UAG was… “Tested and fully supported coexistence of UAG SP1 and UAG SP1 UP1 with TMG SP2“. So you have to have UAG SP1 or higher before you install TMG SP2.

But what about the new Update1 to UAG SP1? Well if you plan to add both TMG SP2 and UAG SP1 Update1 to your UAG, the recommended install order is to first install the TMG SP2 and then Update 1 for UAG SP1.

Slipstreaming TMG SP2

If you would like to make a slipstreamed media of TMG including SP2 you need to first make sure it’s SP1 Update 1. Let me give you a quick guide on how to do this.

Get hold of your TMG DVD, remember that there are two versions Standard or Enterprise Edition.

Extract the content of the DVD to a folder (in my example D:TMG)

We need to download

 Update 1 and SP2 is not in .msp format but in .exe so first you need to extract the msp using

  • “TMG-KB2288910-amd64-ENU.exe /t D:Update1″
  • “TMG-KB2555840-amd64-ENU.exe /t D:SP2″

 Now we can start producing our slipstreamed DVD.

  1. Open a command prompt and navigate to D:TMGFPC.
  2. Add SP1 using
    “msiexec /a MS_FPC_Server.msi /p D:SP1TMG-KB981324-AMD64-ENU.msp”
  3. Add Update 1 using
    “msiexec /a MS_FPC_Server.msi /p D:Update1TMG-KB2288910-amd64-ENU.msp”
  4. Add SP2 using
    “msiexec /a MS_FPC_Server.msi /p D:SP2TMG-KB2555840-amd64-ENU.msp”
  5. Use your favorite ISO tool and make a DVD from the content of D:TMG

 You now have a slipstreamed media of TMG that installs directly with version 7.0.9193.500.

What will happen with TMG?

What is the plan for TMG in the future? Will it vanish or will it just be a part of the next generation where TMG and UAG become one “Unified Gateway”?

Why suddenly ask these questions you might wonder, well…

The last Gartner report, published 25 May 2011, on Secure Web Gateways presents the following Maqic Quadrant for Secure Web Gateways.

Magic Quadrant for Secure Web Gateway

Magic Quadrant for Secure Web Gateway

As you can see it does not list TMG and the report contains the following text:

“Microsoft has informed Gartner that it does not plan to ship another full version release of its SWG product, the Forefront Threat Management Gateway (TMG). The product is effectively in sustaining mode, with Microsoft continuing to ship Service Pack (SP) updates; the next one, SP2, is planned for 3Q11. Microsoft will also continue to support TMG for the standard support life cycle — five years of mainstream support and five years of extended support. In the SWG category, TMG will become less competitive over time, since Microsoft’s goal is not to compete head-to-head with other vendors in that space. We believe that Microsoft will repurpose TMG technologies in other products and services as part of its overall cloud strategy.”

I have spent the last few days trying to get some “official” comments on this from Microsoft but has so far failed. So we can only speculate what this means.

My speculation around this is that this is part of the cloud strategy as mentioned in the Gartner report and UAG is the gateway product prepared for the cloud. My guess and speculation is that this is not the end of TMG as function but maybe as standalone product. I think we will see TMG and UAG merge into one “Unified Gateway”.

[Update 2011-05-31]

During the last 48 hours I have recieved information leading me to believe my guess and speculation above is not entirely correct. The “truth” is not yet revealed but hopefully Microsoft realize that customers and partners are waiting for clarification on the product roadmap of TMG and UAG.

[End of Update]

As soon as any official statement is presented I will add that to this post.

[Update 2012-09-17]

Important changes to Forefront product roadmaps

[End of Update]

Use KCD to secure your infrastructure

In todays world, working remotely, and accessing information from outside the corporate network, is a demand. One huge problem with many solutions today is that this will make us expose our domain password on un-secure clients like mobile phones and internet café’s. On these un-secure devices it is very hard for us to know if there is some kind of password snatcher, and if the password is stolen this can often be used to logon to our corporate resources.

KCD (Kerberos Constrained Delegation) makes it possible for us to build solutions that do not require the domain password to access resources like ActiveSync, OWA and Sharepoint. Microsoft ForeFront UAG and TMG are two great products that can make use of KCD to secure your infrastructure.

How to make it work…
What you do is that you configure TMG/UAG to authenticate using a method that do not require the users domain password. This could be an OTP (One Time Password) for example. You then configure delegation to use KCD and UAG/TMG will request a Kerberos ticket on behalf of the user and present that as credentials to the service. In many scenarios you will find that UAG´s more flexible authentication options will make this much easier using UAG then TMG.

The ActiveSync example…
ActiveSync is widely used to access email based on Microsoft Exchange. Usually this means the username and password of the domain account is stored in the device. A mobile phone, no matter how “smart”, is not a secure platform. What you can do is to configure a second identity store where the username and “activesync password” is stored. You then use UAG/TMG to authenticate against that store and then use KCD to get the users data from Exchange. This way the password stored in the device is not the same as the domain password and you can also enforce a different password complexity and change policy.

First of all we need to understand that in order for KCD to work there are some demands on the infrastructure.

  • The UAG/TMG server must be a member of the same domain as the resource the user tries to access.
  • UAG/TMG needs to be trusted for delegation for the specific service
  • The username needs to be the same if using multiple identity stores.
  • The resource needs to accept Kerberos authentication.

More to come…
I am currently working on a more detailed article to show how to configure the ActiveSync example using UAG and AD LDS as the ActiveSync user store. I might even throw in a section on how FIM (ForeFront Identity Manager) can be used to automate the process of managing the second identity store required in this example.

Issues when Migrating from ISA to TMG

Migrating from ISA to TMG is in some case quite easy, but in others it can be quite a jurney. In one of my latest cases it was indeed an interesting jurney…

So let me share some findings with you.

Moving from Standalone ISA to TMG Array.
This does not look to be a problem in theory, but…
Things you can do in a standalone ISA are sometimes not possible in a cluster.
This time it was the use of multiple subnets on a single nic. When moving to NLB you cannot have a VIP from a different subnet.
Found this out when i entered the scene day 1… And this caused the project also needing to do some IP-routing changes in the network.

Migrating Rules
Even though it is possible to export/import configurations in some scenarios. You usually want to take the opportunity to change the rules to take advantage of new features in TMG and also to clean up in the “mess” after adding rules over the years. While doing this kind of migration I have discovered many times that customer tells you one thing and the rules show something else.
You ask the cu…
“Have you made any special settings that we need to consider?”, and cu will answer “No”.
Well what you find in the rules is that a lot of them have “special non-default settings”. And when do you find this out… When users start testing! A little bit to late in other words.
The problem is that it is not a trivial task to check 100 rules in detail in order to grasp how many places have “special settings”.

Active FTP
This cu had a few FTP rules in place. They already knew which ones needed to be cleared from the “Read-Only” flag. They had learned that the hard way in ISA. But they did not know if they also required “Active FTP”. In a TMG cluster you need to “enable” Active FTP on first the enterprise level… And also on the Array level.

NLB and Procurve – Not the best combination

Using NLB to build TMG (or UAG) clusters is heavily dependent on switches used. HP Procurve has shown to not being “up to the job” in many cases.

After spending the last days helping a customer Migrate from ISA to TMG and trying to figure out how to get NLB to work in their environment I thought i should share some findings.

Unicast or Multicast
It is important to remember that TMG does not care if you use Uni- or Multicast. This is entirely a switch problem. Problem is that many network guys do not know how to pick the right one for the specific switch model at hand.

NLB in Procurve
When using typical Procurve switches (like 2800-series) you will find yourself stuck on using Unicast NLB and also having to add some static MAC-address entries in the environment.

When trying to use Multicast NLB we discovered that HP switches will not let you add Multicast MAC-addresses as static entry’s in many models.

One thing that i noted in this project is total lack of information from HP on how to integrate NLB with there different models.

Why NLB?
Many of you might say… Stop using NLB and get a HW LB instead…
In my opinion NLB should always be the first load balancing you should consider when building TMG and UAG clusters.

Why?… Simply because this is the one integrated into the product. If using any other LB you will not benefit from TMG’s integrated management. Configuring a stand-alone LB to detect service failures in TMG to cause a node-drop is not an easy task. I have also found that when using external LB you will in many cases not be able to use routed relations and will have some serious problems to get bi-directional affinity to work, especially in protocols like RPC.

Security or Performance

Just spent a day last week with one of Swedens largest Universities. I was talking about TMG.
What struck me was that the main problem they had with TMG was that it was reducing their bandwidth!

I find it quite strange to still here customers talking about Firewalls in terms of bandwidth rather then about the security and protection they add to their infrastructure.