Understand ISA/TMG updates

  • Article

The purpose of this blog post is to provide you with some interesting information about the different kind of product updates the ISA/TMG Sustained Engineering (SE) team can release during the lifecycle of ISA Server or Forefront Threat Management Gateway.

First of all, we will make the distinction between a bug and a design change request (DCR):

  • A bug is a problem in the code that leads the product to not behave as expected (unexpected crash for instance) or cause some regression compare to a previous release.
  • A DCR is requested by customers to modify the way an existing feature works or to add a new feature in the product. For instance, the TFTP application filter introduced back in ISA Server 2006 is an example of the implementation of a DCR raised by one of our customers at that time.

Most of the times bugs and DCRs are raised by our customers through support cases. However they can also be raised internally by Microsoft IT, PSS and by the ISA/TMG Product team itself (developers, testers, Program Managers…).

The resolution of a bug (fix) or the implementation of a DCR can ship in different vehicles, which could be the following:

  • A hotfix
  • Available to customers on-demand via the PSS channel
  • Code is based on last accumulative hotfix
  • A public hotfix
  • Available on Microsoft Update and/or Download Center
  • Code is based on last accumulative rollup
  • A security Update
  • Available on Microsoft Update and Download Center
  • Code is based on last accumulative rollup
  • A Rollup
  • Available each quarter (can be shorter) to customers via the PSS channel
  • Code is based on the last accumulative rollup with the addition of all hotfixes approved since last rollup
  • A Service Pack
  • At least one Service Pack per year (according to a plan of release). Available on Microsoft Update and Download Center
  • Code is based on last major release, include all rollups and approved hotfixes since last major release

Of course, all of the above is described in public KB articles.

Before releasing the official fix to a bug, the SE team generally releases an unofficial fix first (also known as “private” fix) except if the fix is planned to be part of next Service Pack or next major release. This unofficial fix is sent to the customer (who opened the support call) for testing. Once the customer approves the fix, the product team will package the fix in one of the shipping vehicles described above, based on the urgency of the bug.

It’s important to note that an unofficial fix does not undergo a full cycle of tests (only the official release does). It is intended to prove that the fix solves the bug. That’s why it is recommended to install and test an unofficial fix on a test environment, rather than the production environment.

Once the official fix is released (in a Rollup for instance), the customer must uninstall the unofficial fix first, then install the rollup.

In some very specific situations (when an issue is hard to troubleshoot), the SE team can provide an instrumented private update to the customer via PSS. This update is intended to provide detailed tracing information to the developer owning the bug in order to understand the root cause of an issue, and later on to design a fix solving the problem.

Another point to mention is that some official fixes (for specific issues) are disabled by default. A VB script must be then executed on the server or array in order to enable the fix. The script is always provided in the KB article describing the bug. Here is an example:

http://support.microsoft.com/kb/2445386/en-us

We hope you’ll find this information useful!

Author:

Eric Detoc, Escalation Engineer, Forefront TMG

Technical Reviewer:

Eyal Peri, Senior Program Manager, Forefront TMG Sustained Engineering team