Previously, in App-V 4.X, while sequencing you would never have to reboot. The idea, which worked in most cases, was the sequencer would simply – while in monitoring mode – execute what ever was in queue for the next startup before proceeding to the next part of the sequencing process.
This list of things to execute would be gathered and executed once you hit Stop Monitoring. Stop Monitoring was a button available in the sequencer up until App-V 4.6 and this could also be pressed multiple times. In App-V 4.6 SP1, and forward, changed the workflow of the sequencer and suddenly the button Stop Monitoring was not available. You could suddenly not hit this button multiple times, but simply check “I am finished” and click Next. Unfortunately – you could not go back. Multiple reboots were suddenly a hassle – as you would have to save the package and return to the start of the workflow to initiate a second reboot.
There had been a few known cases (never personally hit them) were reboots were simply not handled as nicely as one would like in this workflow. As always – things can get better.
In App-V 5.0 this changed drastically and now you were commanded to perform the reboot. The experience would be that at any time after the actual monitoring process started a reboot could be executed, and once the computer starts up again the sequencer will resume operations.
Reboot.exe is the process that scans your computer and apparently it saves the state into a sub-key of the App-V sequencer.
HKLM\SOFTWARE\Microsoft\AppV\Sequencer\Resume is the place to watch out for!
Under Resume there is a Serialized State that seems to explain where the current state of the package is;
I haven’t personally experienced any issues with this, however quite a few people have. As far as I know they have always a few things in common;
- The sequencer workstation is domain-joined
- Its running as a virtual machine
What happens if you perform a reboot and you do have an issue?
Firstly – the sequencer can catch that it hasn’t been allowed to prepare enough for a shutdown;
If no error message is presented this means that the sequencer was given enough time to prepare the sequence so that it should be successfully resumed once the computer is rebooted. However, something else can interfere during startup and then this happens;
A good idea is to check Event Viewer under Application and Services –> Microsoft –> AppV –> Sequencer and the Admin-log. By manually crashing the sequencer and just attempting to restart it this was generated;
An attempt to start the monitoring session failed (The process cannot access the file because it is being used by another process)
Run / RunOnce
You could avoid the reboot and manually locate what needs to happen for the application installation process. A tool to use in this process is Autoruns (from Sysinternals) or poke around the registry for potential clues in the Run registry key. Once you identify what is set there to run at the next reboot – simply run it to get it into the monitoring process. Hopefully this will allow you to proceed without having to deal with the reboot in itself.
Or you could to try to resume the sequencer again. I can’t say that I have been able to test this in anyway, but once a reboot is initiated the sequencer will write to RunOnce so that once you login again the process will resume;
C:\Program Files\Microsoft Application Virtualization\Sequencer\Sequencer.exe /resume
However, it did fail the first time … Why would it work the second time?
What could cause this?
My assumption would be that any type of process that would interrupt the sequencer to properly shutdown its business in Scratch or properly open it would of course interfere the process.
If there is a GPO that would clear out the temp-folder, very common within RDS environments, that could potentially cause issues (as the serialized state will be lost).
I have heard a rumour that redirect folders (such as My Documents, or AppData) might interfere.