Choco: New Chocolatey Helper "Pending Reboot"

[DarwinJS]

Visual Studio is a package that takes a very long time and then fails when a reboot is pending.

I have a oneliner that is an abbreviated version of:

https://gallery.technet.microsoft.com/scriptcenter/Get-PendingReboot-Query-bdb79542

that I would like to code up as a helper.

[ferventcoder]

@DarwinJS let's discuss what you think this should do first. What would be the purpose of this helper?

[DarwinJS]

It would be handy for:

• Packages like Visual Studio which will fail with a uninformative error message could instead say "This package can't run if a reboot is pending, please reboot and try again."
• After a package runs it could be called to give the warning "This package requires a reboot, please be sure to reboot before using the software it installed"

Actually for the second one I wish choco did that built in after each package has run - something like "Warning: this package or something that ran before it requires a reboot" and also possibly a variable that tracks when a reboot is needed."

I guess if Choco checked at the beginning and end of every package and displayed a warning it would be helpful.

There have been times I have run a TON of automation and no reboot is needed - so it's good to know when one absolutely is.

Also when non-installation tech people run choco upon my recommendation - they just aren't thinking "Hmmm, I bet choco supresses reboots and I'll generate a lot of unnecessary support calls if I don't reboot before using the items I just installed."

D.

[DustinVenegas]

This has definitely been an issue for me since some installs succeed silently if a reboot is necessary. I've had to resort to checking HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired before critical sections during automated scripts.

[DarwinJS]

With this oneliner I check two other places, but not
pending computer rename, pending domain join or SCCM reboot.

[ferventcoder]

• After a package runs it could be called to give the warning "This package requires a reboot, please be sure to reboot before using the software it installed"

Chocolatey itself is going to provide this.

[ferventcoder]

Actually for the second one I wish choco did that built in after each package has run - something like "Warning: this package or something that ran before it requires a reboot" and also possibly a variable that tracks when a reboot is needed."

Ha! I hadn't read that far yet!

[ferventcoder]

@DarwinJS @DustinVenegas I already know every thing that we'd need to check for whether a reboot is required - we capture CCM, computer rename, all of the things - https://github.com/puppetlabs/puppetlabs-reboot/blob/7f0c2bfc84a4bb4c706d79195b6574259a9745bb/lib/puppet/provider/reboot/windows.rb#L73-L199

[DarwinJS]

@ferventcoder - Cool! Will it be exposed as a variable?

So it seems like a helper might still be nice when it is _known_ that a setup.exe will self-block if a reboot is pending?

Maybe for now it could be my oneliner and when choco has built-in support the helper is refactored to just check the built-in variable?

[ferventcoder]

There are a few steps that need to fall into place first before this - most of that is already in 0.9.10, but the bigger one is getting the install-chocolateyinstallpackage known to Chocolatey C# so it can handle providing more information surrounding the exit code of the software (in addition to making the checks).

[ferventcoder]

And possibly a variable - it seems like we'd need something to be provided - so a package can fail until no pending reboot is required.

[ctmcisco]

Hello, I am have created a Choco package that requires a reboot after install. I assume this is not built in to Choco? I ran the get-pedingreboot function to confirm the pending reboot. The install goes well but Choco gives out an error and does supress the reboot I notice in debug. Is there a work around that can be implemented. Does the paid version handle this? I also may try to couple with Boxstarter and integrate the reboot in the chocoinstall script.

[bcurran3]

@ctmcisco - Rob will give you the official Chocolatey future plans on this.

I wrote the fastanswers extension. I've got it on my TDL to investigate adding a Set-RunAfterReboot or some such name that I'm pulling out of the air at the moment. Basically it would check for errors such as 1603 and add a "chocolatey install packagename" to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce so that it will (attempt) install after restart. If you like this idea, open an https://github.com/bcurran3/ChocolateyPackages/issues in my repository and I'll get on it sometime next week.

[DarwinJS]

@bcurran3 - if you haven't had the chance, you might want to read my blog on this exact topic and steal my code ;) https://cloudywindows.io/post/continue-your-automation-to-run-once-after-restarting-a-headless-windows-system/ (hint HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce - still requires user logon - it exists so you can hit every user with one registry key)

[bcurran3]

Thanks @DarwinJS. Just read (most of) it and I think Example 3: Oneliner Self-Deleting With No Script File is a great method to accomplish this. You just saved me a lot of time testing/debugging/failing!

EDIT:

I'm guessing:

schtasks.exe /create /f /tn RetryPackageInstall /ru SYSTEM /sc ONSTART /tr "cinst %ChocolateyPackageName% && schtasks.exe /delete /f /tn RetryPackageInstall"

...would work fine after a known failure. Problem comes in when there are more than one failures. I'd also have to do a simple check for the "RetryPackageInstall" task and make a "RetryPackageInstall2 etc if it exists.

EDIT 2:

Further thought, I'd just name the task related to the package name and then there would be no problems or duplicates!

schtasks.exe /create /f /tn Retry%ChocolateyPackageName% /ru SYSTEM /sc ONSTART /tr "cinst %ChocolateyPackageName% && schtasks.exe /delete /f /tn Retry%ChocolateyPackageName%"

[abmoham]

IMO - it sounds like the ‘retry’ methodology should be broken out into a separate thread (I like where it’s going though 👍) so we could finally get a complete ‘pending reboot’ function built. Does that make sense?

[DarwinJS]

You'll want to keep in mind that there are a lot of potential State differences in a machine that is running a package in the scheduler upon reboot versus the wherever it originally ran. For instance availability of the internet due to user proxy settings. Or availability of any network resources due to user authentication requirements. Most systems that support a reboot like you are proposing use a policy of copies of all needed files locally before the reboot. E.g.SCCM is one of these systems. It is hard to predict how many of these potential States a given package operation would be dependent upon. So in my opinion it is unlikely that you could build a universally applicable retry on reboot.

[abmoham]

Agreed, those are the nuances of a software deployment system vs the current ‘client’ feedback to ensure local package installation (wrt: the reboot flag before and/or after installing a package).

[bcurran3]

I've opened an issue for myself as a reminder to experiment with this idea, https://github.com/bcurran3/ChocolateyPackages/issues/27. Any thoughts and feedback are welcome there.

[bcurran3]

FYI: I did create a helper extension that checks and warns on pending reboot. It also pauses when the Windows Installer is busy (hopefully heading off a some of those MSIEXEC install errors) as well as when it finds multiple instances of choco.exe running. It's PRE release right now as I'd still like to do some post install handling of errors for possible retry at reboot... if I can figure it out.

Anyone who wants to play guinea pig and provide feedback can look at https://chocolatey.org/packages/chocolatey-preinstaller-checks.extension - I'm pretty confident all the pre-install checking is 100%.

[DarwinJS]

I would suggest that this module be passive - only log about possibly concerning situations and set variables to indicate they exist. Then separately look into which of these might merit building "handlers" - the handlers should be opt-in only - at the package level. Once their code is working well you could consider global opt in for ones that prove their value and stability.

But I would not mix passive checking with taking actions to resolve conditions.

Also, on reboot pending check report the detailed reason one is pending - just like get-pendingreboot.