Error 1618 and a half finished Exchange CU: setup will not start again

Fix it now

Microsoft publishes 1618 as ERROR_INSTALL_ALREADY_RUNNING, another installation is already in progress. After an update that failed partway that is often no longer true: nothing is running, but installer state from the previous attempt is still in place. Reboot first; it clears this in most cases.

Get-Command ExSetup.exe | ForEach-Object {$_.FileVersionInfo}
Test-ServiceHealth

1. Reboot the server. It costs far less than anything else on this list and clears most stuck installer state.
2. If setup still refuses, check whether something genuinely is installing: look for running installer processes and confirm Windows Update is not mid-installation.
3. Read the end of C:\ExchangeSetupLogs\ExchangeSetup.log. If it says a previous run failed while performing an action and must be resumed, that is an instruction rather than an error.
4. Rerun setup in upgrade mode from an elevated Command Prompt with the same media and build as the interrupted run: Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade
5. Let it finish and reboot afterwards, as Microsoft requires for any Exchange update.

Do not uninstall Exchange to escape this. Microsoft states that uninstalling a newer build removes Exchange from the server completely rather than reverting it.

If setup runs past the point it previously stopped and the log records completion, you are done. If it fails again at the same task, that task is the problem, not the installer state.

Why it happens

Windows Installer serialises installations across a machine, and it does so with a named mutex. Microsoft documents the behaviour precisely: an attempt to call the installer’s API returns ERROR_INSTALL_ALREADY_RUNNING, 1618, while the _MSIExecute mutex is set, and also while the current process is processing the InstallUISequence or AdminUISequence table. The mutex itself is held only while an execute sequence is running. That is why a reboot resolves it: the process that held it is gone, and the mutex with it.

0x80070652 is the same condition expressed as an HRESULT, because 0x8007 is the HRESULT wrapper for a Win32 error and 0x652 is 1618. There is no second, subtler failure hiding behind the hexadecimal form.

Exchange keeps its own state as well, recorded per installed role. It notes which action is in progress and how far the task sequence got, and that state is what allows setup to resume rather than start again. The message about setup previously failing while performing an action belongs to that second mechanism. Microsoft publishes no page describing it, but its function is clear from context: it names the action that was interrupted and asks you to run setup again so it can carry on. Reading it as a fatal error is how people end up considering a reinstall they do not need.

Full reference

The two codes, and what Microsoft says

Knowing that 1638 exists is worth something here, because an update refusing to start because a different version is present looks similar from the outside and is fixed differently.

When the mutex is held

Microsoft’s description of the _MSIExecute mutex is narrow and useful: it is set only while the InstallExecuteSequence, AdminExecuteSequence or AdvtExecuteSequence table is being processed. Two installations cannot run in the same process, so an API call returns 1618 while the mutex is set and also while the current process is processing the InstallUISequence or AdminUISequence table. In practice that means the condition belongs to a live process, and killing the machine’s installer state by rebooting is a legitimate first move rather than a superstition.

Before changing anything under the Exchange server registry key, export it to a file you can restore. Microsoft publishes no supported procedure for clearing Exchange setup state, so this is unverified territory: take the export, change only what relates to the role that is stuck, and expect the rerun to take as long as a fresh install of that role.

The command line to resume with

<drive>:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /Mode:Upgrade

Use _DiagnosticDataOFF instead if you do not want diagnostic data sent. Microsoft states the older /IAcceptExchangeServerLicenseTerms switch stopped working with the September 2021 cumulative updates, so a script that still carries it will fail before it does anything useful. On Exchange Server Subscription Edition the package you are resuming will be a Security Update or a Hotfix Update rather than a cumulative update; launch it elevated in the same way.

Why uninstalling is never the shorter route

• Microsoft states that after you upgrade to a newer build you cannot uninstall it to revert: uninstalling completely removes Exchange from the server.
• Removing a server also removes its configuration from Active Directory, so what follows is a recovery installation against a configuration that is no longer there.
• The supported route for a server that genuinely cannot be recovered is to rebuild the machine and run setup in recovery mode, which reads its configuration back out of the directory.
• That is a serious operation with its own planning, not a first response to an installer that will not start.

Stopping it happening again

• Patch Exchange in a window where nothing else patches the server, and pause management agents that update themselves.
• Run from the console, or from a session that survives a disconnect.
• Reboot before and after, as Microsoft asks.
• Keep the media that matches the build until the update has completed and been verified.

Every code this article covers

Confirm the fix worked

1. Setup starts and runs past the point it previously stopped.
2. The end of C:\ExchangeSetupLogs\ExchangeSetup.log records completion rather than a rollback.
3. Get-Command ExSetup.exe | ForEach-Object {$_.FileVersionInfo} reports the build you intended.
4. Test-ServiceHealth reports every required service running, and mail flows.

Questions people ask about this