Solved: Exchange install keeps prompting for reboot before installing a CU

Let’s take a look at a common error in an Exchange 2016 or Exchange 2019 upgrade or installation where it keeps asking you to reboot before you can install the update. I hope the solution I offer helps you if you are stuck with this and unsure how to resolve it. The error occurred on an Exchange 2016 CU21 upgrade and on Exchange 2019 CU9 upgrade in a lab environment. The same applies to a production environment. When it comes to Exchange 2016 or Exchange 2019 Cumulative Updates (CU) or Security Update (SU), admins, whether experienced or new to the Exchange technology, run into issues with the installation of Exchange one time or another. In one of my previous articles, I spoke about the Exchange services that won’t start after a failed install of a cumulative update or security update.

In this article, I will talk to you about an error that sometimes comes up and causes frustration with an upgrade or install of Exchange, either 2016 or 2019. We are not covering legacy Exchange Servers in this article, but the same should apply to Exchange 2013. If you are new to Exchange Server and running your first installation or upgrade when you run a cumulative update, you need to do so from an elevated command prompt, or else the install will fail. This is running the installations without the graphical user interface, which also needs to run elevated. The same applies to running a Security Update. The installation or upgrade of Exchange 2016 or Exchange 2019 starts, and all seems to go well until it gets to the prerequisite analysis part. Then it fails with an error message: “A reboot from a previous installation is pending. Please restart the system and then rerun setup.” The error is shown below in the screenshot:

As a rule, I always reboot a system before running any installation, as you may have had Windows apply updates in the background with SCCM. Or perhaps another admin updated an application but did not reboot. An example of this is modifying the Symantec install to remove IPS. You reboot the system, and the same error returns when you rerun the Exchange 2016 or Exchange 2019 Cumulate Update setup. After the third reboot, you still get the error above, and you know something else is wrong. Just like in a failed Exchange installation or upgrade, information is written to the Registry and needs to be cleaned out for the installation or upgrade to continue. In this case, it is not a watermark but a path with a previous installation that did not clean up automatically. With the above error, there is a Registry key that is supposed to be empty or not shown, but sometimes it does not get updated, and it shows the information from a previous build or install. To fix the above error is relatively simple but does require you to make changes to the Registry. As a rule, always make a backup of the Registry or key you are removing in case you need to restore because you deleted the wrong key or information. Making changes to the Registry, if not done properly, can result in you having to recover the server, which you do not want to do. Once you have the backup in place, you can navigate to the following Registry key:

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

Here is a screenshot of the hive:

exchange reboot

Here you will have a key called “PendingFileRenameOperations” that has existing/old information. Simply double-click this key and remove the data inside it, or you can remove the key completely. Once you have completed the removal, you can rerun your installation of Exchange, and this time it should continue and not fail on the error in screenshot 1. If you encounter any other errors, those will need to be dealt with separately as they will not be the same as the one above. For example, if your setup failed on the ClientAccess part of the Mailbox part, you will need to go to the Registry section where the Exchange 2016 or Exchange 2019 is kept and remove the watermark for each section that failed. Below is an example of what the key looks like and the data in it:

exchange reboot

As mentioned, you can remove the key altogether or just the contents of it. As you can see on this particular Exchange Server in my lab (screenshot 2), I do not have a key called “PendingFileRenameOperations.” But I did have it on my other Exchange Server in Azure (screenshot 3). If you feel that you need to reboot first before attempting the installation or upgrade, go ahead. I have done the installation or upgrade of Exchange 2016 or Exchange 2019 with a reboot and without a reboot. Once you have completed the installation or upgrade and are confident everything is fine, you can either remove the backup of the Registry key or keep it if you need to. I have encountered the error a few times, but after a reboot, the error was not present anymore.

Featured image: Shutterstock

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top