Edit 6/10/2010: Corrected the script path.
Certain 3rd party software such as anti-virus and anti-spam have their own services running on the Exchange server and these can sometimes prevent Exchange services from being stopped successfully. This in turn can prevent the installer from updating files loaded by these processes and may require a reboot to complete the installation.
Since we have no control over 3rd party software, we've added the ability for you to register custom commands via a PowerShell script to stop and restart services, amongst other possibilities. Use of this mechanism may provide a way to avoid unnecessary reboots of the computer after update rollup installations. The script has three different sections - pre, post and rollback - that will allow the installer to take appropriate actions throughout the installation process.
In order for the installer to find and process your script file, it must conform to the following conventions:
Filename: CustomPatchInstallerActions.ps1
Location: <ExchangeFolder>\Scripts\Customization
The script file must have 3 sections:
PrePatchInstallActions : User defined actions that will be performed before the installation starts.
PostPatchInstallActions : User defined actions that will be performed after installation has finished.
PatchRollbackActions : User defined actions that will be performed after rollback of the installation (due to cancellation of installation).
As stated earlier, all sections are required. If any section is missing in the file no user-defined actions will be done. The installation will continue with its normal operation.
Due to technical limitations in the installer framework, there is no way to detect return values from the custom script. However, you are encouraged to use logging to track the progress of your script, including success/failure status and general tracking information.
The installer will place a template file (CustomPatchInstallerActions.ps1.template) into the ExchangeFolder\Scripts folder. This template should provide a good starting point for developing your custom script. Just in case the template does not exist yet on your server, the sample is also listed below. By having the extension of ".template" we are ensuring that the sample doesn't run. You will have to rename it with the ".ps1" extension in order for the installer to pick it up during installation.
We would like to stress the necessity for thoroughly testing your custom script before deploying in a live environment. Microsoft cannot validate any custom functionality you decide to add and cannot prevent execution of incorrect scripting code. You also need to properly sign the script if the "ExecutionPolicy" for PowerShell is set to "RemoteSigned" or "AllSigned".
You can find the sample script here.
- Exchange SE Team
