Error 1638: another Exchange version blocks this cumulative update install

Fix it now

Error 1638 is ERROR_PRODUCT_VERSION: Windows Installer found another version of the same product registered and stopped before touching a file. On an Exchange server that almost always means the package you launched is the same as or older than the installed build, or belongs to a different Exchange version altogether.

Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}
Get-ExchangeServer | Format-List Name,Edition,AdminDisplayVersion
winver

1. Compare the installed build with the build on the package you are running. Exchange only moves forward: if the package is the same or older, stop, because the installer is right.
2. Confirm the package matches the product. An Exchange 2016 CU will not install over Exchange 2019, and neither installs over Exchange Server SE.
3. If you meant to move to Exchange Server SE, check the route. Microsoft supports an in-place upgrade only from Exchange Server 2019 CU14 or CU15; from Exchange 2016 or earlier it is a legacy upgrade, meaning a new server and a mailbox move.
4. If you are already on the newest CU for your version, you want the current security update instead. Those install over a matching CU and are not full builds.
5. Run Setup.exe from an elevated Command Prompt rather than double-clicking it, so you can read the failure and the log path.

Error 1633 (0x80070661) is a different refusal: ERROR_INSTALL_PLATFORM_UNSUPPORTED, the package is not supported on this platform. On Exchange that usually means the operating system underneath, not the processor.

If the correct package installs, you are done. If you have run out of packages that will install, the next two sections explain why and what the options actually are.

Why it happens

1638 is the installer’s product-version check. Every installed product registers an upgrade code and a version, and every package declares which versions it may replace. Where the package’s rules do not cover what is already present, Windows Installer refuses before writing anything. Microsoft’s published text is blunt: another version of this product is already installed, and installation of this version cannot continue.

Exchange runs into this more than most products because cumulative updates are full builds. A CU is the entire product rather than a patch layered onto the last one, and installing it is an in-place upgrade of the whole server. You may reinstall the same build as a repair, and you may move to a newer one. You may not go backwards, and the installer enforces that by refusing rather than warning.

1633 says something different and is worth separating. ERROR_INSTALL_PLATFORM_UNSUPPORTED means the package is not supported on this platform; 0x80070661 is the same code carried as an HRESULT. Exchange has been 64-bit only for years, so a true processor mismatch is rare. Far more often the file belongs to a different Exchange version, or the build does not support the Windows Server release underneath it. Exchange Server SE is supported on Windows Server 2019, 2022 and 2025, with .NET Framework 4.8 or 4.8.1, and Microsoft does not support an in-place upgrade of the operating system with Exchange installed.

There is one more thing the installer will not tell you: whether a newer package exists at all. Once a version leaves support, the last CU published for it is the last one there will ever be, and 1638 on that server is not a fault to configure around.

Full reference

Matching the message to the situation

The two routes to Exchange Server SE

Two coexistence rules matter when you plan this. Exchange Server SE RTM setup prevents coexistence with Exchange Server 2013. From Exchange Server SE CU2, setup refuses to coexist with any version of Exchange that is not supported at the time of that release. Both are enforced by setup rather than advised, so a plan that assumes otherwise stops at the readiness checks.

Product keys and licensing under SE

Exchange Server SE RTM does not require a new product key: a server that has been upgraded in place or through a legacy upgrade continues to function. Microsoft has said that a future cumulative update introduces a product key requirement, so treat the key as something to have ready rather than something you will never need.

The commercial model is unchanged. A server licence is assigned for each running instance of the server software, with Standard supporting 1 to 5 mailbox databases and Enterprise 1 to 100. A Client Access Licence is required for each user or device that accesses the server, in Standard and Enterprise forms, where the Enterprise CAL is an add-on that requires a Standard CAL alongside it.

Platform requirements, because 1633 is about them

• Exchange Server SE runs on Windows Server 2019, 2022 or 2025, in either the Desktop Experience or Server Core installation option.
• It requires .NET Framework 4.8.1, or 4.8 as the alternative, on Windows Server 2022 and 2025.
• Only the PowerShell version included with Windows Server is supported. Windows Management Framework add-ons are not.
• An in-place upgrade of Windows Server between major versions with Exchange installed is not supported, so a platform move means a new server.

Do not uninstall Exchange to clear error 1638. Removing the last Exchange server from an organisation takes recipient management for the whole directory with it, and the recovery from that point is a restore rather than a reinstall.

When you are stuck between builds

The awkward case is a server whose reported build does not match anything you can download, usually after an aborted run. Do not go hunting for an exact-match package. Read the setup log, fix the thing that stopped the previous run, reboot, and rerun the same package in upgrade mode. Setup is designed to resume, and resuming is far safer than trying to reconcile a version number by installing something else on top.

Every code this article covers

Confirm the fix worked

1. Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo} reports the build you intended to reach.
2. Test-ServiceHealth shows no required service missing.
3. C:\ExchangeSetupLogs\ExchangeSetup.log ends in success rather than a rollback.
4. OWA and the admin centre open, and a test message goes in and out.
5. On a DAG member, the server is out of maintenance mode and its database copies are healthy again.

Questions people ask about this