Bigfix Applying Updates

The Bigfix Console

Update Guidance

In order to push a software update or install out to endpoints, you will need a "fixlet".  The fixlet is a package that contains

• The executable to run
• "Relevance" or conditions used by Bigfix to determine which endpoints should receive the update/install
• "Action Script" or the set of instructions Bigfix will use to apply the executable
  • You can think of Action Script as a programming language unique to Bigfix
  • Note that some fixlets may not have an executable per se, but rather handle everything in Action Script;  this would be analogous to creating a Windows batch or PowerShell file

"Tasks" are also mentioned in the console.  A Bigfix task is like a fixlet in that it contains the above elements, but there are some differences.

• Fixlets are usually used to "fix things", such as updating, patching, installing, or removing software
• A fixlet's success is measured against its relevance; the fixlet is successfully applied to an endpoint if it is "no longer relevant" for that endpoint
• A task is usually use to "do things" that don't involve fixing or patching anything; the "Pharmacy VPN" tasks or actions that change an endpoint's settings (such as BF_Subdepartment) are good examples of this
• A task's success isn't tied to relevance; a task is successful merely if all lines in its action script completed without error

Since the focus of this document is "updates", we will focus on fixlets.  This can include fixlets that install or remove software as well.

Where Do I Get Fixlets?

You have essentially four sources for fixlets.

1. Bigfix provides thousands of fixlets for all kinds of software.  You can find the list under the "Fixlets and Tasks" menu option.  You can break that list down by looking in the various submenu groupings.  I've found "By Source" particularly helpful.
2. If you can't find what you are looking for in "Fixlets and Tasks", on rare occasions I have found a fixlet that I needed (or something reasonably close that I could modify) on a Bigfix forum.
3. Under "Sites"/"Custom Sites" there are "DoIT_Shared_Applications" and "Shared_Fixlets" sites.  Sometimes campus contributors will share fixlets in these sites that you can copy.
4. Yourself.  If you don't need to write any complicated relevance and the action script is pretty straightforward, it's not too hard to put a fixlet together.  I've often used the Software Distribution Wizard to help create my own fixlets.

Running A Fixlet

We'll assume that you already have a fixlet stored somewhere in the console.  For this example, we'll use the "Spirion Sep2023 v12 Windows Install" stored in "Sites"/"Custom Sites"/"Pharmacy"/"Fixlets and Tasks".

1. Find your fixlet, click on it, then click the "Take Action" tab.
   
   
   
2. Next, select the target endpoints that will run the fixlet.  The fixlet won't run unless it has targeted at least one endpoint.
   
   You can select individual endpoints if you want to target very specific ones.  For broader applications, you can select "Select Devices" or "Dynamically target by property" under the "Target" group.  "Enter device names" gives you a blank box that you can enter endpoint names, but that seems just tedious to me.  After that, you can select one of the properties in the hierarchical list.  In this example, "Select Devices" with "By BF_Department">"Pharmacy" will select the endpoints that are "relevant" for that fixlet.  In other words, they meet the relevance criteria defined in the fixlet.  You can move further down into the hierachy to select even more specific endpoints.
   
   Notice that when using "Select Devices" the endpoint list is limited to endpoints that are relevant to the fixlet, and then you can select properties from within that group.  Using "Dynamically target by property" tends to select endpoints from your entire endpoint population.  So if we selected that and then chose "By BF_Department">"Pharmacy", our list would be made up of ALL of the endpoints with a BF_Department value of "Pharmacy", whether they are relevant or not.  WARNING: when you select these really broad filters, you are depending on the fixlet relevance to target the correct endpoints.  It's always wise, no matter how you select endpoints, to review the list and make sure the fixlet is applied only to those endpoints it's intended for.
   
   
3. Next, click the "Execution" tab.  Most items here are self explanatory, so I will just jot down a few comments.
   
   
   
   1. None of the items have any effect on fixlet execution unless you select the checkbox next to it.  
   2. Notice that "Ends On" is selected by default.  Best practice is to always select some end time for your fixlet, otherwise it will just keep running.  This might be OK in rare circumstance (for example, to re-fix an endpoint if it ever become relevant again), but mostly it just consumes server resources and the Bigfix team will probably contact you about it at some point.
   3. Depending on what I'm doing, I usually let a fixlet run for a few days, but almost never more than four weeks out from the start time.  If it's just a quick run on a handful of endpoints, a shorter end time is fine.  If you're trying to apply the fixlet to a lot of endpoints or you're just not sure when they will report in, then a longer end time is appropriate.
      
      
4. Click OK to run the fixlet.
   
   
5. I have almost never bothered to use the settings on the other tabs, but feel free to explore those and use them as you see fit.
   
   
6. Once you submit the fixlet, you can monitor its progress in the "Actions" menu option.
   
   
   
   1. You can filter the running actions to display only the actions you submitted by creating a "Custom Filter" ("My Actions" is what I created for myself).
   2. In the "Actions" pane you'll be most interested in the "State" and "% Complete" columns.
      1. "% Complete" means what it says: the percentage of targeted endpoints that the fixlet has successfully run on.
      2. State is usually one of these.
         1. Open: fixlet is still actively running.
         2. Stopped: Bigfix operator (you) or one of the admins manually stopped the fixlet.
         3. Expired: If you gave an end time for the fixlet, this time has passed and the fixlet is no longer running.
      3. You can right-click and delete an action that is either Stopped or Expired.  It's always a good idea to do this when you're sure you don't need to keep the end results anymore.
   3. In the bottom pane you will find all the endpoints targeted by the fixlet.  You'll be most interested in the "Status" and "Exit Code" columns.
      1. Status is usually one of the following.
         1. Completed: the fixlet is done running on that endpoint.  Was it successful?  Look at the Exit Code.
         2. <not reported>: the endpoint has not reported to the console and has presumably has not received the fixlet job yet.
         3. Waiting: the endpoint has reported to the console, and is waiting to run within the given time period.
         4. Pending Restart: Bigfix is waiting for the endpoint to restart before it can evaluate whether it's relevant to the fixlet 
         5. Pending Download: usually this means the fixlet is running and waiting for files to be be downloaded to the endpoint so it can run them.
      2. The Exit Code is just a code returned to the console by the endpoint to indicate the final outcome of the fixlet.
         1. A "0" is a really good sign that the fixlet was successful in running whatever software it needed to run.  This corresponds to Windows/Mac batch file processing exit code of 0 to indicate success.
         2. "None" means the fixlet has not yet run on that endpoint, so we don't know the exit code.  This usually is found with a "<not reported>" status.
         3. Any value other than "0" or "<not reported>" indicates some error happened while running.  You will need to find out what that code means for your fixlet or the commands/files it is trying to run.  PRO TIP: you can double-click an endpoint in this list to get a "log" of what happened.  This can sometimes give clues about where the error happened.