Catch the Replay! 27-March Webinar - BigFix Decoded: The Reboot Conundrum

27-March Webinar - BigFix Decoded: The Reboot Conundrum

This Webinar series will enable you to get more value from BigFix. This series presents common business challenges, best practice solutions, and demonstrations to get you started. Register to join or replay. Joining live gives you the added bones of real time access to our Team BigFix experts who can address your questions in real time.

Rhonda Studnick Kaiser, Director of Client Experience, and John Talbert, Director of BigFix Professional Services, Dan Paquette, Director of BigFix Technical Advisors are your recurring hosts and moderators. Each month will have a featured technical expert or two as guests.

In this webinar, Joe Saylor (@Jsaylor), Michelle McGough (@mcjee), John (@brolly33), and Rhonda are going to dive into restarts and reboots. How do you effectively manage reboots? How do you ensure that your machines are ready for patching when there might be pending reboots? What about post-patching reboots? We’ll share our insights and best practices, illustrated by real life examples we’ve lived through and worked with our customers to implement. This should be a good learning for both those new to BigFix and those who need a refresher on best practices.

Register here: https://attendee.gotowebinar.com/register/5794128745044236128

Hey everyone, thanks for the webinar but reboots will be the vain of IT for the rest of our existence!

A few questions came up from the webinar, first one regarding the Pending Restart Detection analysis, is this the output expected under WindowsUpdate RebootRequired column?

If we have a machine that for example keeps on failing an update how does this help us since it was mentioned that this is helpfeul? Is it possible to translate that to the name of an update or an application? Or how do we correlate that information to find it ourselves?

And a feature request, when hovering over that the pop-up box doesn’t dissappear after a few seconds :frowning:

Joe quickly mentioned the _SuperSecretRebootOptOut bes client setting on a relevance, can you elaborate some more on that one? From what I seem to understand, for those VIP users, push out a registry setting with that name and value of “1” and these machines will not be prompted for a reboot?

And Parameters…Joe seems to think it’s great so can someone please expand on that :slight_smile:

Thanks!

is this the output expected under WindowsUpdate RebootRequired column?
how does this help us since it was mentioned that this is helpful?

Yes, this is what we expect to see. Unfortunately there isn’t a readily available resource that would let you translate one of those GUIDs into a specific patch.

The initial value you get out of this is that you can see that your systems are pending restart because of a windows patch and not some other reason, so you can begin your troubleshooting at the OS patch layer. You also get some internal consistency inside those values, so if you restart your first computer, and it returns the same list of GUIDs, you can know that Windows is having some trouble applying these specific updates and will need some attention. If the GUIDs change between reboots, then you can infer that Windows is actually applying something during each of your reboots, and it may resolve itself after another one or twenty tries.

_SuperSecretRebootOptOut bes client setting on a relevance, can you elaborate some more on that one?

The main idea here is to create some exception toggle that you can apply to systems in order to opt-out of your reboot automation. Invent a setting for your organization, and add it to your persistent reboot actions as a check in their relevance. This can be useful in many ways:

  • permanently applying it to your VIP’s so they never have to deal with any reboots
  • a tool for your support technicians to prevent reboots while working on a problem box
  • An emergency stop button in case an operator sends out too many reboots to your endpoints

As far as naming goes, it’s important in my view to obfuscate your toggle’s function a little bit. It doesn’t take a particularly savvy user to know that “_NeverReboot = 1” might get them out of restarting their computer. Something a little more opaque like “_TechnicianMode = 801” both makes it less obvious what your setting actually does, and also makes the required value hard to guess so you won’t have users abusing your reboot opt-out quite as easily.

And Parameters…

Parameters (specifically “action parameter query”) are a fantastic way to allow some flexibility in your content and really push it from single-use case to all-the-use-cases. For instance, we use parameters in this file upload fixlet, to give the console operator who may be troubleshooting some of these reboot issues the flexibility to upload any logs they might need from an endpoint.

you can take the GUID and create a custom filter looking for that guid in the action.

image

That should find it a little more easily.
Dave L.

Something else from the Patching Support site that might help with troubleshooting windows patches:

Task 12010: Collect Patch Diagnositics data, Registry key from Windows Endpoints

Action 1: This task is used to collect below mentioned patch diagnostics data from windows endpoints.

  • List of installed patches
  • Windows Update log (For Windows 10 & 11)
  • CBS logs
  • Events from ‘System’ for past 48 hours
  • BigFix registry keys
  • The results will be uploaded to the BigFix Server under below path: \UploadManagerData\BufferDir\sha1<last two digits of computer ID><full computer ID>

Action 2: This task is used to collect specific registry from Windows endpoints.

Specify the full path of the subkey. The key name must include a valid root key. Valid root keys are: HKLM, HKCU, HKCR, HKU, and HKCC. Example: KEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Note: If the registry key name contains a space, enclose the full path name in quotes.

The results will be uploaded to the BigFix Server under below path: \UploadManagerData\BufferDir\sha1<last two digits of computer ID><full computer ID>

Action 3: This task performs a clean-up of the client settings.

Hi Joe, thanks for the detailed reply. Now it makes more sense as to how one can apply that Pending Restart Detection analysis.

We have something similar then to the supersecretreboot… our msp set us up by using Computer Groups and creating a “Restart Exceptions” in which those VIP can be added to. At least visually this seems like a good alternative option - but the super secret registry key is much cooler :wink:

And I think I know what you refer to in regards to parameters, but I found the Parameters webinar which I am sure will give me more info.

Thanks again!

Hi @davel, I created a filter as your screenshot but I am not sure exactly what to look for, can you expand on that filter? Thanks!

when you create the filter it should only show the fixlet or fixlets with that specific GUID