Hi all,
I have a customer with a set of requirements, and I think they could use BigFix effectively to solve their problem. The problem is that they have several Windows servers that must be patched, but which can only be rebooted if authorized to do so based on information in an external application. Basically, each Windows server needs to run a local script to request information from the external application, then, based on that information, determine if a reboot is allowed or not. The configuration I’ve conceived is:
A fixlet to download the current patches and install on reboot (this already exists)
A task with an action, where the action:
calls the client script and returns a true or false value (or similar)
is set to re-run every hour if unsuccessful
is set to expire in a week if still unsuccessful
The script called by the action would be a Windows PowerShell script utilizing the ‘curl’ alias to access the REST API of the external system.
My question/request is mainly a sanity check. To me, this seems like a logical function for BigFix to perform, but I’m hoping to get feedback either pointing out deficiencies (or possibly overlooked details) or letting me know I’m on track.
Thanks,
Frank
As always, “it depends”.
The concept sounds feasible, but has some considerations. Will every endpoint be able to reach this database, and how do you handle any authentication needs? Consider that the BigFix client is running as LocalSystem, so the Computer account may need to reach the database. If you are distributing database usernames or passwords, read up on using Secure Parameters and be aware those credentials, even if sent securely, could be retrieved by local administrator on the endpoint.
Some common alternatives that are often used, would be to use the API from a dedicated system, maybe your root server, to contact your CMDB and retrieve the allowed patchibg schedule for all of your systems, and use that information to send an action through BigFix’s REST API to those endpoints and apply a client setting, registry entry, or create a file that flags whether the machine can patch and reboot. You could use that setting/reg entry/file in your action, or use it as a custom Constraint when you send the patch actions.
There are a lot of variations, but a common one would be to send Lock and Unlock actions to your endpoints based on schedules you retrieve from the CMDB. That way your patch fixlets and action settings don’t need to be modified at all.
If you search for PatchWindow or Maintenance Window here in the forum, there should be details on several solutions you might be able to leverage.
Awesome! Thanks for the feedback, Jason. All of the information is great, including the “Secure Parameters” tip.
Frank
Hi Frank,
This may be something similar that I posted that you could look at Custom Maintenance Window Process
One thing to note is around the timing when the agent will run the action, I have set up actions to run every 15 minutes (as an example) but depending on the load of the server, this can sometimes take 30 to 60 minutes to run. So the “scheduling” on actions does not always happen when you would expect. I started a thread on that too Slow processing of content. I seemed to see this on systems with 8 or more processors. Really odd.
Martin
That’s awesome! Thanks, Tick!