Setup previously failed while performing the action: recovering a failed Exchange upgrade

When a cumulative update or a fresh install dies halfway, Exchange setup remembers exactly where it stopped and refuses to do anything else until that job is finished. That's what "Setup previously failed while performing the action" means. In this post I'll show how to read the message, find the real failure in ExchangeSetup.log and resume safely with the same build, plus the one workaround to keep for last.

Symptoms#

Setup stops within seconds with one of these combinations, followed by a pointer to the setup log:

Setup previously failed while performing the action "Install". You can't resume setup by performing the action "BuildToBuildUpgrade".

Setup previously failed while performing the action "BuildToBuildUpgrade". You can't resume setup by performing the action "Install".

Setup previously failed while performing the action "BuildToBuildUpgrade". You can't resume setup by performing the action "Uninstall".

The Exchange Server setup operation didn't complete. More details can be found in ExchangeSetup.log located in the <SystemDrive>:\ExchangeSetupLogs folder.

A related readiness check can fail instead, once for each affected role (the role name varies): A Setup failure previously occurred while installing the HubTransportRole role. Either run Setup again for just this role, or remove the role using Control Panel.

The server usually still shows the side effects of the first failure: Exchange services stopped and set to Disabled, a retry that ends with Cannot start the service Microsoft Exchange Service Host, Outlook on the web errors, no mail flow, or components left Inactive (see Exchange components stuck Inactive after an update).

Why it happens#

As setup works through each role, it records its progress in the registry under HKLM\SOFTWARE\Microsoft\ExchangeServer\v15\<Role>, for example MailboxRole, ClientAccessRole or HubTransportRole:

• Action: what setup was doing, such as Install, BuildToBuildUpgrade (setup's name for a CU upgrade) or Uninstall.
• Watermark: the last step it completed.

A successful run removes both values. When they're still there, the next run compares the recorded action with the one you're starting: the same action resumes from the watermark, a different action is refused with this error. That's why uninstalling a server whose upgrade never finished, or starting a fresh install over a failed upgrade, hits the message straight away.

How to fix it#

1. Find the real failure#

The message only tells you that an earlier run failed; the reason is in C:\ExchangeSetupLogs\ExchangeSetup.log. Read the last errors, or let the SetupLogReviewer script from Microsoft's CSS-Exchange project match them against known issues:

Select-String -Path 'C:\ExchangeSetupLogs\ExchangeSetup.log' -Pattern '\[ERROR\]' |
  Select-Object -Last 15 | ForEach-Object Line
.\SetupLogReviewer.ps1 -SetupLog 'C:\ExchangeSetupLogs\ExchangeSetup.log'

C:\ExchangeSetupLogs\ServiceControl.log records which services setup disabled.

2. Fix that cause#

Typical culprits are services that wouldn't stop (restart the server before setup), antivirus interference (apply the documented exclusions or turn it off during setup), a pending restart or missing prerequisite (Exchange setup prerequisite errors) and Active Directory preparation (PrepareSchema and PrepareAD errors).

3. See what setup recorded#

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15' |
  ForEach-Object { Get-ItemProperty -Path $_.PSPath } |
  Where-Object { $_.Action -or $_.Watermark } |
  Select-Object PSChildName, Action, Watermark

4. Resume with the same action and the same media#

Restart the server, mount the ISO you originally used and run setup from an elevated prompt with an explicit path. A bare setup.exe in PowerShell can start the older copy in the Exchange Bin folder instead.

D:\Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF

If the recorded action is Install, rerun the original install command with the same roles. Either way, setup picks up from the watermark.

If setup can't even start because services are Disabled (Cannot start the service Microsoft Exchange Service Host), restore the services that were running before the update, rename C:\ExchangeSetupLogs (for example to ExchangeSetupLogs-OLD) as Microsoft's troubleshooting article advises, then run the upgrade command again:

Set-Location (Join-Path $env:ExchangeInstallPath 'Bin')
Add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.Setup -ErrorAction SilentlyContinue
.\ServiceControl.ps1 AfterPatch
Get-Service -DisplayName 'Microsoft Exchange*' | Format-Table DisplayName, StartType, Status

The POP3 and IMAP4 services are stopped and not set to start automatically by default; leave them that way unless you use them.

5. Last resort: clear the watermark#

If you genuinely can't complete the recorded action (for example, you must uninstall a server whose upgrade can't be finished), the widely used community workaround is to back up the role key, delete its Action and Watermark values and run setup again so it starts that role from the beginning:

reg export 'HKLM\SOFTWARE\Microsoft\ExchangeServer\v15\MailboxRole' "$env:USERPROFILE\MailboxRole-backup.reg"
Remove-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\MailboxRole' -Name Action, Watermark

Only touch the role keys that step 3 listed, and only after the underlying problem is fixed. Clearing the watermark repairs nothing by itself.

Verify the fix#

• Setup ends with The Exchange Server setup operation completed successfully. Restart the server afterwards.
• The registry query from step 3 returns nothing.
• The file version matches the build you installed: Get-Command ExSetup.exe | ForEach-Object { $_.FileVersionInfo }.
• Test-ServiceHealth shows RequiredServicesRunning : True for every role, and Get-ServerComponentState $env:COMPUTERNAME | Where-Object State -ne 'Active' lists only ForwardSyncDaemon and ProvisioningRps, which are normally Inactive on-premises.
• You've installed the latest Security Update for the new CU (installing Exchange security updates) and the Health Checker comes back clean.

Prevent it next time#

• Restart the server before every CU, run setup elevated with an explicit path, and keep antivirus exclusions in place.
• Run Health Checker and SetupAssist (aka.ms/ExSetupAssist) beforehand; they catch pending restarts and AD problems early.
• Patch one server at a time in maintenance mode (patching a DAG without downtime).
• Keep the ISO of the installed CU; repairs and some update errors ask for the original media.

References#

• Fix failed Exchange Server updates (Microsoft Learn)
• SetupAssist script (Microsoft CSS-Exchange)