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.

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


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.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.


  1. Greg

    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!

    1. Avatar photo
      Paul Cunningham

      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.

  2. Charlie Digiglio

    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!

    1. Avatar photo
      Paul Cunningham

      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 🙂

  3. Graham Riley

    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?!


    1. Avatar photo
      Paul Cunningham

      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 🙂

      1. Graham Riley

        Thanks Paul,

        I tried it and it works a treat!

  4. Zach Thawley

    Nice blog post; this is definitely helpful!

  5. Turbomcp


Leave a Reply