App-V 5: On why the App-V 5 Sequencer *Really* Reboots

Prior to version 5 of App-V, when you sequenced an application that required a reboot, the reboot was simulated in that the sequencer would process the reboot action including the Pending File Operations and the RunOnce registry keys (RunOnce, RunOnceEx, GuiRunOnce, etc.) when monitoring ceased. In most cases, the simulation would be fine and all of the necessary reboot tasks would be processed properly. There were some exceptions – notably the famous disappearing Google Chrome application famously mentioned in “Stealth Puppy’s” [I love that handle] “Case of the Disappearing Application During Sequencing https://stealthpuppy.com/the-case-of-the-disappearing-application-during-sequencing/ “ where after the reboot tasks processed and the monitoring of the installation of GoogleChrome completed, the Program Files directory simply disappeared.

In defense of the sequencer, this was not as much the fault of the App-V sequencing process, but also an issue with the mechanism of the installation. This was easy to prove by going through the sequencing process and verifying the contents prior to stopping the monitoring process. The files were indeed correctly located prior to the stopping of monitoring:

However, when we ran PENDMOVES.EXE (https://technet.microsoft.com/en-us/sysinternals/bb897556) from Sysinternals, we found this:

The operation pending was to DELETE the actual files. This would explain why the files got deleted after the monitoring process ended. The next logical step would be to see if this was a properly captured operation and not just some bug in the sequencer and install the application natively. Prior to rebooting the machine, run the PENDMOVES.exe utility again. Upon doing this, you will find the EXACT same pending file operation – DELETE C:\Program Files\Google\Chrome.

So the native installation does indeed remove the files upon a reboot. The difference is after the reboot, the files are back where they need to be! How is this possible? Google triggers updates using the Google Update service which is set to start automatically. The missing files would force the Google Update service to pull down the most up to date version. Indeed a prime example of some of the exceptions to the rule that the 4.6 sequencer was not catching.

Going back to the original issue – and never passing up an opportunity to showcase a Sysinternals utility – I would recommend a workaround. Given the issue was a DELETE operation, you could leverage another Sysinternals tool to add in a recopy function as a workaround with 4.6. Before actually stopping the monitoring process, first copy the files in question to a safe area.

Then I used the MOVEFILES.EXE utility (https://technet.microsoft.com/en-us/sysinternals/bb897556) from Sysinternals to have them moved back during the simulated reboot.

Changes in the V5 Sequencer

So to ensure that the sequencer works better with installations that require reboots (or even multiple reboots) the sequencer was changed to actually reboot. When the sequencer detects that the application is requesting a reboot, all tasks are recorded and deleted (except for the PendingFileRenames key) to force resume only after the system is rebooted and the monitoring has resumed, otherwise, these tasks could occur prior to the sequencer resuming. This information is recorded to disk (although obfuscated) and the system will reboot as normal

After the reboot, the PendingFileNames key will be processed as it would in a normal reboot. Upon the user logon, the sequencer will be launched (as it registered itself to do that prior to reboot.) Upon relaunch of the sequencer, the sequencer reads its state from the registry and the file system and restarts monitoring. The first tasks that will be processed will be the RunOnce tasks that were captured prior to the reboot.

One Exception

While the Sequencer User Interface allows for the preservation of settings and a real system reboot, this is not the case for applications sequenced using the PowerShell Sequencer Cmdlets. Since this is mostly reserved for scripted MSI packages, those usually have suppressed reboots anyway.