BSA How-to Video: Windows Patch Analysis

Version 2

    Here's a quick video on how to setup a basic Windows Patching Job to do patch analysis.  It also includes the creation of a Patch Smartgroup, and a quick look at the results of the Patch Analysis.



    (double-click to open in youtube)


    Windows Patching (about 4:30 to read)


    Hi, I'm Sean Berry:  I’m a member of the Solutions Engineering Team working in Data Center Automation, and now we're going to talk about Windows Patching. 


    Why Patch

    Setup Patching Job

    Run Patching Job

    Observe Results


    In BladeLogic, audit and remediation are part of the same process for all kinds of compliance.  We’ll talk now about the audit or analysis phase for patching, and cover remediation in the next video.


    Last time, we built a Windows Patch Catalog and updated it with metadata.  Now we want to determine how many patches are needed on our server.


    Many patching efforts will start with a basic assessment: roughly how many patches are needed in our environment, according to our policy.  That provides useful input to determine the scale of the patching effort.  For environments that are patched regularly and effectively, a patch analysis should return a fairly consistent number of patches within each group of servers, with a few outliers where servers that haven't been patched in a while, or that have more applications than the average installed.  It may make sense to group together servers that will need a little extra attention.


    Since we built a patch catalog in the last video, now let's create a quick patching job.  The starting point for patch analysis is the Catalog, which contains the range of patches provided by the vendor, filtered by operating system or application.  Our policies will usually include a subset of these, further grouped by either Patch SmartGroups or explicit include/exclude filters. 


    For today’s exercise, let’s create a Patch SmartGroup specifying only Critical patches, a common production patch policy.  Right-click on the Patch Catalog, and select New Patch Catalog SmartGroup.  Let’s name it Critical Bulletins.  Select Windows Bulletin, the condition will be VENDOR_IMPACT, and select Critical in the window on the right side.  Click Next.  Access control is important for Patching: any group that needs access to this SmartGroup can be added here.  Click Finish. Right-click on the new SmartGroup, select Group Explorer to show the list of included hotfixes in the Group Explorer window at the bottom right.


    Right-click on the SmartGroup again and select Analyze Patch(s).  Let’s call this Production Windows Critical Patch Analysis, and store it in the Workspaces folder.  Click Next. 


    Observe that our new Patch SmartGroup has been filled in as an include list, since that’s where we initiated the job.  Other, simpler patch policies will often just use the “Group” option, with “Security patches” selected.  Click Next. 


    Our task right now is Analysis, but it is common to generate the remediation artifacts: the package containing the missing patches, and the job that will deploy them.  Here is where we would configure the options for the job and package.  We’ll come back to those in our patch remediation video: for now let’s leave this unchecked.  Click Next.


    We’re going to select one server for this exercise.  Normally we would be using Server Smartgroups here, ideally grouping together a set of patches that all have the same maintenance window and get patched to the same policy, but today we’ll use WIN08-WWW, a web server in our demo lab, built recently from install media.  Click Next.


    We can send ourselves (or our internal customer) an email if there’s a problem with the job, and we can send them the results of the patch analysis as well, if they’d like to see it.  This is great if you have distributed teams with overlapping responsibilities for servers and patching.  Click Next.

    Click “Execute Job Now”, and click Finish.  We can, and in a production environment, likely would schedule an analysis job to run on a regular basis, at least every month.  This will provide good visibility into the patch compliance of the environment to at least a minimum standard of patches.  While there may be many different analysis jobs running based on maintenance windows and server groupings, these results are brought together in an environment-wide view in the reporting tool.


              The Patching job will run for a minute or two.  The job will need to copy some small metadata files out to the endpoint to run the analysis, so you will need at least some level of write access to the host for this task, and the analysis will need to run as a privileged user, like a local Administrator.


              Let’s look at the results.  Let’s find the job in Jobs/Workspace, right-click, and Show Results.  We see our run from today, expand that down.  The Object view shows us by-hotfix how many servers need a specific hotfix: this can be useful if you’ve got a particularly high-priority or time-sensitive patch you’re chasing down.  Let’s go over to the Servers view.  We see that our server needs X patches.  Once this server is being more regularly patched, it will likely need anywhere from a few to a dozen patches every month as Microsoft releases them, and as our policies require them.


              Now that we know what patches are needed, check back in our next video on Patch Remediation, where we’ll deploy these patches.  Thanks for your time.