A few servers had continue to request, through the ConfigMgr, a reboot after the servers were, surprise, rebooted due to Windows Updates.

Use the below PS code you can see the current state of the reboot.

Invoke-WmiMethod -Namespace “ROOT\ccm\ClientSDK” -Class CCM_ClientUtilities -Name DetermineIfRebootPending -ComputerName <name>

Obviously, before actually doing any of the below suggestions – a restart should before forced on the client. On the servers in question, a minimum of one reboot per server has been confirmed before using this workaround.

The WMI method apparently only retrieves the current value of the ConfigMgr-client. To change the state of the WMI method – one has to digest the registry a bit;

The current state is saved in HKLM\Software\Microsoft\SMS\Mobile Client\Reboot Management\RebootData

On a server rename it to old, and then restarted the CCMEXEC-service.

To confirm that a request for a reboot you can either await the GUI initialization, or use the above PS code to verify the pending reboot state.

All Reboot requests are logged in RebootCoordinator.log in the ConfigMgr client log-folder.

Some interest articles;

http://blog.thesysadmins.co.uk/sccm-2012-stopping-your-computer-is-about-to-restart.html

http://blogs.technet.com/b/umairkhan/archive/2014/06/10/configmgr-client-reboot-internals-for-update-deployments.aspx

http://blogs.technet.com/b/heyscriptingguy/archive/2013/06/10/determine-pending-reboot-status-powershell-style-part-1.aspx

App-V 4.X

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.

App-V 5.0

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

Problems

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;

An error encountered while trying to start the monitoring session.

Event Viewer

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;

HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce

Manual resume

Try this;

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.

reboot

Never ending reboot prompts

App-V 5.0 Sequencer and Reboots