Client Management Suite

Hoping Hightower jumps in...,

Background:
New 7.1 installation, Endpoints have the appropriate agents and plug-ins (3100 endpoints)
Endpoints are geographically dispersed across several states, I have Package servers at all the appropriate sites

We recently acquired several hundred (thousand) endpoints from a couple different acquisitions. The patching practices from these are all over the place. Some are well patched others are in the weeds. I need to do the first "true up" patch cycle. If I look at the compliance by bulletin for the last year I think its like 173 Bulletins for all the Windows OSs. The work flow will be for all the patches to be approved at HQ then have regional IT people test in the lab before releasing to the endpoints they support. I have already changed my default remediation setting to target the lab OUs. I was hoping to just grab all the updates in one lump this first time and get them bundled together for distribution. Apparently that isn't possible, A:) Altiris times out bundling the packages for distribution. B) I receive an error about not being able to mix OS families.

I am looking for ideas or recommendations of how to get through this first patch. I know I could go through and approve each bulletin one at a time, but then all 173 would need to be touched several times before they would actually be targeted at production. Ongoing I expect it to work just that way. Do I really need to do separate process for each OS type in the Org, That seems like a lot of duplication since mostly XP/2003 are the same and so on for Win7/2008 and the other classes.  I am not completely opposed to doing one at a time but there must be a better way. I am sure I am missing some nuance and it's not that complicated.

Thanks.

Hi Bret,

Typically I bundle Security Bulletins by month and Windows Updates by month.  So, for August of 2013 I have two Software Update Policies:

2013 08 August - MSSB
2013 08 August - MSWU

Here are my steps to create these policies (I do almost everything from Home > Patch Management):

1.  From Software Bulletin Details I first sort by Release Date.  Then I right-click and give all of the bulletins that we're avoiding our custom severity of "PHC Avoided".  Then I select all of the bulletins we've approved a custom severity of "PHC Enabled"  (PHC being the acronym for my employer).

2.  Refresh that page's report (sort by date again, if necessary).  I think control-click all of the PHC Enabled bulletins that are not showing as downloaded and select Download Packages.  Then wait for all of the downloads.

3.  Control-click everything in a given month that you want to bundle together.  In my case I'd start with Microsoft Security Bulletins that were released in August 2013, then right-click and select Distribute Packages.  This will open a new window where you'll build the Software Update Policy (I call this the "Payload" policy for my own sanity).

4.  Give this new policy its name.  In my case it's "2013 08 August - MSSB".  This way all of my month SUPs sort together and makes assignment on a regular basis much easier.

5.  Select your targeted filter.  In my case I always start with my "PHC Patch Workstation Policy - Test" filter.  In September I'll go back into this SUP and add my "PHC Patch Workstation Policy - Enterprise" filter.  You'll see that I like naming items so they sort together.

6.  Click Next.  From here you can deselect individual Updates if you'd like.  I do not usually do this but if you have the option enabled to automatically disable superseded updates and you go back and look at old SUPs, you'll see that many of the updates get disabled over time (don't freak out over that).

7.  You can enable the SUP at this point and save it, or save it and enable it later.  Your choice.


If you follow this approach you'll go from having to create 173 policies and assigning each one individually to your filters and take that down to ...20?  Yeah, that still sucks but the upside is that you only have to do this one time if you're smart about creating your patch group filters.

Instead of adding your Lab filters individually to the SUPs and run the risk of having to edit them all in the future in case of another M&A, how about creating a filter for "Workstation Test Labs" and then adding each site's Workstation Test Lab into that parent filter?  That way you just have to add a new site's new Test Lab filter and then all of the policies apply immediately.

One other thing, I only put Bulletins in *ONE* SUP.  We don't see the need to target our systems with different bulletin content.  We don't need to group or filter by OS or even installed software because the applicability checks run and only the relevant patches are delivered to a computer (so XP patches aren't staged to a Win7 computer and Office patches aren't staged to a computer w/o Office installed, etc.)

I don't know what the error about not being able to "mix OS families" is about as I've never seen that.  Perhaps it's byproduct of timing out trying to assemble a policy with so many bulletins.  I've heard unofficial recommendation to not include more than 100 updates (not bulletins) in one policy but I've done as many as 150 updates in one policy.  I suspect that your hardware and SQL server have a lot to do with your capabilities here.

Does this help?  Did I miss anything?

A couple of screenshots.

Thanks for the detailed explaination. More than I hoped for. I was able to bundle this up into some chewable bites. More than I hoped for but as you said 20 is better than 173.  thanks for the suggestions

It's a shame threads like these can't be stickied.  This could be very helpful to anyone new to patch.

@HighTower, it looks like you keep superseded patches in your policies?  Am I right that the only negative I can think of with doing so is superseded patches would stick around on the server indefinitely?  

The last time I asked support, the only way for the patches to delete themselves on the server is if you remove them from policy (or delete policy if whole thing is superseded), and then also disable the patch in remediation center.

Thanks for any info.

Correct, I tend to leave them all in place and never touch them again.  The only cost is disk.

Something to keep in mind is that not every bulletin is COMPLETELY superseded.  It's likely that you have one or more updates within a bulletin that gets replaced but since you can only enable/disable a bulletin as a whole the overhead required to reevaluate every bulletin every month does not interest me.

See the attached spreadsheet for an example of what I'm talking about.

Yea, we do one update per policy, doesn't seem necessary but it's manageable in a smaller environment. It allows me to clear out the superseded stuff more easily though every month when I'm creating a dozen policies instead of 1 or 2 I question if I should do it your way.