I'm working with deploying Notepad++ via MECM (formerly SCCM), and specifically, installing it during an "operating-system deployment" task sequence which also installs a variety of other programs.

In the past, this has worked fine. With current versions (I don't know exactly when it started; see below), I am seeing that at some point after the Notepad++ install completes, something else appears to happen, and the "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations" REG_MULTI_SZ entry in the Registry is populated with a variety of NppShell-related paths and filenames; NppShell.dll, NppShell_01.dll, NppShell_02.dll, NppShell_03,dll, NppShell_04.dll, NppShell.msix, NppModernShell.dll, and NppModernShell.msix have all been seen (all present simultaneously in that Registry entry).

This Registry entry is used to record the names of files which should be renamed or deleted when the computer reboots, because they cannot be safely deleted while it's running (e.g. because they're in use, and Windows file-locking semantics prohibits it). When this Registry entry is populated, many (but not all) MSI-based installers will error out and fail to install, on the basis that a system reboot is pending.

We therefore see that at a semi-random point after the installation of Notepad++, our installation task sequence encounters an error while installing a different program, and aborts without completing the rest of its installation process.

I could (and probably will) implement a kludgy workaround by setting the task sequence up to reboot after installing Notepad++, but this is not an entirely satisfactory solution.

For one thing, it does not necessarily solve the problem; if the post-NP++-install actions which cause that key to become populated have not yet occurred by the time we reboot, then they will presumably occur after the reboot, and the errors will occur at that point. Because we do not have a way to synchronously wait for this to happen (aside from a polling loop to wait for this key to populate, which is problematic on multiple fronts), we cannot safely just rely on rebooting to clear the blockage and continue.

For another thing, this problem did not occur with previous versions, and it is distasteful to accept a regression and work around it, rather than trying to get it fixed at the root.

Is there any possibility of getting the installer adjusted so that either this does not happen, or there is a way (perhaps an optional install-time switch) to make the installer block and not exit until this change has finished applying?

I do not know exactly when this started happening. We have seen it with version 8.5.7, but we have also seen that version appear to work fine. The problem was first observed, as far as I know, within the past week; I have guessed that it might be because of a post-install auto-update to a just-released newer version, but partially against that idea is the fact that I have successfully reproduced the issue when installing 8.6.8 with the '/noUpdater' switch. I have not gone so far as to revert to the 8.5.7 installer and add the '/noUpdater' switch to test whether the issue still manifests, but I can do so if necessary.