Tag Archives: Reboot

A reboot is required to complete file operations on ‘exchangeserver.msi’

I already mentioned this in my blogpost about Exchange 2016 CU6 and Exchange 2013 CU17, but when upgrading an existing Exchange 2016 server to Exchange 2016 CU6, the setup application stops after step 5, 6 or 7 (random) with the following error message:

“A reboot is required to complete file operations on ‘E:\exchangeserver.msi’. Reboot the machine, and then run setup again”


After rebooting and restarting the setup application the upgrade finishes successfully.

Rebooting the Exchange 2016 server prior to starting the upgrade process does not prevent this from happening. Also, there’s no difference between Exchange running on Windows 2012 R2 or Windows 2016.

The installation process has been tested by Microsoft and TAP customers, and tests are still conducted. It is somewhat clear what the root cause is for this issue, it is an MSI package that’s causing this issue. Please be aware that the Microsoft setup application executes around 200 MSI packages, and if only one MSI package is having difficulties you can see issues like this. Because of the number of MSI packages it is not possible to check in advance if your server will experience this issue.

At this moment the only solution is to reboot the server when requested and restart the application program.

Exchange 2013 Health Manager generating alerts in SCOM after reboot

We have a 26 server Exchange 2013 server environment, monitored by SCOM. Within Exchange 2013 Managed Availability is monitoring the health of the individual servers, and alerts are escalated to SCOM which sends out text messages to the Exchange administrators.

It is crucial to have this configured properly to avoid invalid or unneeded text messages being sent out.

I’ve noticed that after a reboot of an Exchange server Managed Availability can send out alerts, even when the probes and monitors involved have a global override. Using a global override Managed Availability should never send out alerts to SCOM anyways.

To avoid this from happening you can set the Managed Availability service on your Exchange 2013 server, which is the Health Manager service MSExchangeHM to “Automatic (Delayed Start)”.

The easiest way to do this is to use PowerShell using the Set-Service command:

Set-Service –ComputerName EXCH01 -Name MSExchangeHM –StartupType Type;

Where Type can be Disabled, Manual or Automatic.

Unfortunately it is not possible to set this to “Automatic (Delayed Start)” using PowerShell, but you can create a Registry key on the Exchange 2013 server to achieve this by using the Set-ItemProperty command:

Set-ItemProperty -Path “Registry::HKLM\System\CurrentControlSet\Services\MSExchangeHM” -Name “DelayedAutostart” -Value 1 -Type DWORD

To do this for all Exchange 2013 servers in your organization you can do something like this:

$ExServers = Get-ExchangeServer | Where {$_.Name –like “EXCH*”}
ForEach ($Server in $ExServers) {
  Write-Host “Setting Health Manager service on $Server to Automatic (Delayed Start)”
  Invoke-Command –ComputerName $Server {
    Set-ItemProperty -Path Registry::HKLM\System\CurrentControlSet\Services\MSExchangeHM -Name DelayedAutostart -Value 1 -Type DWORD