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.

Services not starting after Exchange Server rollup installation

Services not starting after Exchange Server rollup installation

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 Server\fscutility.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:\ExchangeSetupLogs\CustomPatchInstallActions.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 Server\fscutility.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.

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Find Paul on Twitter, LinkedIn or Google+, or get in touch for consulting/support engagements.

Comments

  1. Thanks

  2. Zach Thawley says:

    Nice blog post; this is definitely helpful!

  3. Graham Riley says:

    Hi Paul,

    Many thanks for this. Just a couple of questions if I may?
    Did you modify the Execution Policy?
    Is there any way to simulate this script rather than hoping it will work the next time I try and install an Exchange RU?!

    Cheers,
    Graham

    • Hi Graham,

      My systems are set to RemoteSigned. I didn’t change them as far as I know (or if I did, can’t remember).

      You can take out the code from the script and modify it to your heart’s content to add break points or logging or anything else that would help you test it more thoroughly when running it manually. It is just a PowerShell script after all :)

  4. Charlie Digiglio says:

    I noticed that you say to create a “Customizations” folder, but Microsoft’s site says to use “Customization” without the “s”. Just wanted to point that out in case anyone has a problem with it working – I’m not sure if it’d still work or not with the “s”. Thanks for this info though, this allows us to script out pretty much our entire pre- and post-update process!

    • Hi Charlie, I’m going to update this article anyway since the latest UR4 for Exchange 2010 SP2 makes this process redundant – the UR itself now handles the Forefront services automatically :)

  5. Does this still apply today deploying Service Pack 3 for 2010?

    Also… with Forefront AV for Exchange going away, what do you recommend as a suitable replacement? Thinking about Kaspersky for Exchange myself. Thanks!

    • The Forefront manual stop/start is no longer required.

      I’ve had a reasonable experience with Symantec Mail Security for Exchange. What I would generally recommend is you choose 2-3 well regarded products and use their trial periods to assess how well they work for you in terms of performance and manageability.

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.