Dealing with Exchange Server Update Rollups and Forefront Protection for Exchange

When Microsoft recently released the latest update rollup for Exchange Server 2010 a few disgruntled customers left comments about the situation with Exchange update rollups and Forefront Protection for Exchange.

If you’re not a Forefront user or you’re otherwise unaware of the situation, the issue is that Forefront Protection for Exchange and update rollups don’t play nicely together. For example during installation the update rollup can hang at stages such as restarting the Exchange services after the update has been applied.

This is why each update rollup release comes with the following instructions:

Note for Forefront Protection for Exchange users For those of you running Forefront Protection for Exchange, be sure you perform these important steps from the command line in the Forefront directory before and after this rollup’s installation process. Without these steps, Exchange services for Information Store and Transport will not start after you apply this update. Before installing the update, disable ForeFront by using this command: fscutility /disable. After installing the update, re-enable ForeFront by running fscutility /enable.

As a result we see comments like these from disgruntled customers.

Note for Forefront Protection for Exchange users: We still don’t care enough about you to add two lines to the setup script. Instead you have to do it manually. Or you can install the update via Microsoft Update and you’ll be in for a funny surprise.

Hey Microsoft…. could you not detect for your own software and automatically run the command fscutility /disable????, Now I cannot even get WUS to do this…. Annoyed! and feeling unappreciated as a FF customer

Microsoft actually has provided a solution for this, back when Exchange Server 2007 SP2 was released, and appears to have carried it forward for Exchange Server 2010 as well. A script named CustomPatchInstallerActions.ps1 can be used to perform pre- and post-installation tasks for update rollups.

I’m not sure why they don’t refer to it with each update rollup release, but as far as I can tell from my own testing it works fine.

Here is what you need to do.

1. In the Scripts folder of your Exchange 2010 installation find the file named CustomPatchInstallerActions.ps1.template
2. Create a new sub-folder in Scripts named Customizations
3. Copy the script template into that sub-folder, and remove the .template extension
4. Edit the file with the customizations you want, and the next time you install an update rollup the script will be called automatically

So what kind of customizations should you include? I did a little testing and here is what I suggest as a minimum. You’ll also find Microsoft’s advice here.

First, I ran fscutility /disable (from the C:Program Files (x86)Microsoft Forefront Protection for Exchange Server folder) to see what happens. I received the following output.

Error:
  Microsoft Forefront Protection cannot be disabled at this time.  Please stop
  the following services and then rerun this utility.

   FSCController
   MSExchangeTransport
   MSExchangeIS

So clearly some services need to be stopped first. That will need to go in the script.

After disabling those services fscutility /disable works successfully. So that can be run second.

  Removing dependencies...

      dependency on FSCController removed from Microsoft Exchange Information Store
      dependency on FSEIMC removed from Microsoft Exchange Transport Service
      Microsoft Exchange Transport Service Agent registration removed

Status:  Microsoft Forefront Protection NOT Integrated.

In the custom script itself the actions to perform before installing an update rollup go in the PrePatchInstallationActions function.

function PrePatchInstallActions
{
                Log "Running PrePatchInstallActions"

		Log "Stopping services"
		Stop-Service FSCController,MSExchangeTransport,MSExchangeIS -Force

		Log "Disabling Forefront"
		$fscutility = "C:Program Files (x86)Microsoft Forefront Protection for Exchange Serverfscutility.exe"
		Invoke-Expression $fscutility /disable

}

Notice I’ve also made use of the Log function that is in the script so that I can see in the log file later that my custom actions were run (or at least attempted to run). The log file is written to C:ExchangeSetupLogsCustomPatchInstallActions.log

After the update rollup is finished installing there is a similar process involved to re-enable Forefront. These steps go in the PostPatchInstallActions function.

function PostPatchInstallActions
{
                Log "Running PostPatchInstallActions"

		Log "Stopping services"
		Stop-Service FSCController,MSExchangeTransport,MSExchangeIS -Force

		Log "Enabling Forefront"
		$fscutility = "C:Program Files (x86)Microsoft Forefront Protection for Exchange Serverfscutility.exe"
		Invoke-Expression $fscutility /enable

		Log "Starting services"
		Start-Service FSCController,MSExchangeTransport,MSExchangeIS

}

When I upgraded two servers side-by-side, one with the CustomPatchInstallerActions.ps1 and one without, the one with the script updated without any problems and the one without hung while trying to start the services afterwards.

So in my testing this appears to work well, but it is something you should test in your own environment before relying on it too heavily.

Note that this script can be used for all kinds of situations even when Forefront is not installed. If you have any pre- or post-install actions required in your environment (eg running the StartDagServerMaintenance.ps1 script, disabling backups, disabling other antivirus software, sending an email alert to your team) you can include those in this CustomPatchInstallerActions.ps1 script.