Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Altiris 7.1 Testing Patch Remediation Center with a test group, not my production group

Created: 27 Jun 2013 • Updated: 08 Jul 2013 | 40 comments

I have been wanting to utilize Patch Remediation Center in the Symantec Management Console to patch some our 3rd part applications like Adobe Reader, Flash Player, Quicktime Player. It is under Actions > Software > Patch Remediation Center.

I want to first understand how it works, behaves, etc before I use it on our Procduction workstations. Our Production workstations are from 2500 - 3000 with a mix of XP and 7 x64 workstations and my test group is anywhere from 5-10 workstations with the same mix of OS's. I setup Import Patch Data for Windows under Jobs and Tasks. My example I am trying to test patching Adobe Reader 10 and 11. So I check off the updates for 10 and 11 I need, setup schedule and it completes. Next is Patch Remediation Center; I right-click the bulletin(s) and download packages, next is to setup the Distribute Packages. I setup a new Policy with Step 1; at the bottom area "Apply To Computers" I setup my test group that I named "Patch Remedy Group" that consists again of 5-10 computers and mixes OS's. This is so I can see my test pc's infront of me and watch how this patch remediation works and behaves. After said and done with the policy and the policy is turned on. Windows Assesments need to run, then the list of computers able to get these patches will be generated under "View Targeted Computers". Everytime I setup this up, my test computers NEVER show up under Targeted Computers. It is always the production computers on our network that get applied. The production computers that have Adobe Reader 11.0. installed. My test computers also have Adobe Reader 11.0 installed. I ahve treid setting up a patch of 11.0.1, 11.0.2, and 11.0.3. Same setup everytime of my Patch Remey Group, but the Targeted COmputers always come up as my Production Computers.

Any reason why I cannot get my test group as the targeted computers instead of production computers? I am not even near ready to have my production computers get any of these patches.

Operating Systems:

Comments 40 CommentsJump to latest comment

HighTower's picture

I'm having a hard time following you but are you asking as to how to change the default Resource target for your patch policies?

If so, go here:
 

Settings > All Settings > Settings > Software > Patch Management > Windows Settings > "Windows Patch Remediation Settings"

From there you can select whatever Target or Filter you'd like to be the "default".  Your selected target or filter will be listed instead of the product default which, I believe, is "Computers with Software Update Agent Installed".

MJammer's picture

Wednesday afternoon i setup all of this, I also found the same default area under All Settings as you mentioned above. By default the group initially setup is "Windows Computers with Software Update Plug-In Installed". That group of targets is all of our production workstations that i am deploy to yet. I removed that group and placed my "Patch Remedy Group", But after a Windows Assesment is done; all of my production computers are coming up as the targets. Even though my policy is setup for my test group and the default resource target is also my test group.

Here are the target computers I do not want.png my patch remedy test group.png patch remedy setup as default.png PR Center and my policy to test AR 11.0.2.png
MJammer's picture

Answer this question for me High Tower. Is the targeted computer list the actual list that the update(s) will be applied to? If my patch test group is setup in the policy for the bulletin of Read 11.0.1 will the patch only go to the test computers and spare the other production computers in the target list?

HighTower's picture

It looks like your test computers are also part of your production computers target.  That's one thing.

I think that what you're doing is looking at the bulletin in the Patch Remediation Center > Bulletins and Updates> and then right-clicking that Reader update and clicking "View Targeted Computers".  Right?

What that's showing you is all of the computers in your environment that have been deemed eligible for that particular update based on the results of the Windows System Assessment scan.  This does NOT mean that they're targeted for installation.

Let's start at the beginning.  You have to have the following elements configured to get patches to install.
 

1.  You have a bulletin you want to deploy that has appeared in your Patch Remediation Center.  You'll have to right-click > Download Bulletin.  Once the download has completed you'll go to...

2.  Now you have to create a Software Update Policy.  This policy contains all of the bulletins that you're choosing to bundle together.  Typically I do two bundles per month.... one for Security Bulletins and one for Windows/App Updates.  At my company I tend to refer to these as "Patch Payload Policies."  You will find these under Manage > Policies > Software > Patch Management > Software Update Policies > Windows. 

I usually name these like "2013 06 June - MSSB" because it's descriptive and they sort well.

3.  Now that you have your bulletin's package(s) and you have your Software Update Policy you need to specify a target/filter.  In my environment I have created a Test Workstation filter that I've assigned about 220 computers to and a production Workstation filter that has the remaining ~5200 workstations.  NOTE:  I have excluded the Test filter from the Production filter for so that I only have one patch plug-in policy applying to any given computer.

I've also created nearly a dozen different filters for servers to bundle managed servers into different maintenance/patch groups as we can't reboot 950 servers at one time.

4.  Finally you need to configure when patches are going to apply, whether or not the computer is going to reboot, and how the agent is going to behave during the update process.  You're on the right track for creating a staged rollout process and NOT using the built-in "Default Software Update Plug-In Policy" because that only applies to everything that has a Windows Software Update Plug-In installed.  We need to be more granular than that.

I created a separate Software Update Plug-in Policy for each of those filters that I created in step 3.  So, if you have 10 filters for your patch groups then you should have 10 (plus the default that's now disabled) Software Update Plug-In Policies and the names should be similar for both the filter and the Policy to keep things sane.  This is where you define your different schedules and how the AGENT is going to behave.

So how do I get patches to the right computers?  We're going to go back to step 2 here.  For my company's patch policy we choose to keep our production space one month behind current.  For instance, in May we apply the May patch bundles to the Test computers and the April patch bundles to the Production computers.  And so on every month.

What this means is that I have to go into the "payload" policies that we set up in Step 2 and associate the targets that we created in step 3.  That way only the systems in those targets get the patches, even if there are hundreds more computers that are listed as applicable. 

Does this make sense?  Does this help?

MJammer's picture

I think we are on the same page now with your explainations. Giving you answers from your above items:

1.  I have asked for the bulletin(s) that I want to test. I have done the downloading of the packages to go with that bulletin(s).

2. I have already created the policy for the software update(s). In one of my attached files you would see "Adobe Reader 11 Update 11.0.2 (APSB13-02)". That is what I want to test adobe reader 11 patches with. Then I will move on to patch 11.0.3.

3. Looks like you setup and work with filters; not groups. I have been using groups not filters but I can switch over to filters for Patch Mgt. My Altiris Administrator has been using filters for some situations and I can probably have a filter setup that will target only my test group. Do you think filtersare the better way to go? That will allow the Target Computer list reflect only my test computers, not my production computers?

4. Yes, I am only testing because I need to see how patch mgt. behaves. That is why I do not want to see production computers in my Target list(s). Once I am only targeting test computers, and making patch mgt. work the way I need it to. I can then move on to production computers.

This approach would continue for future patches of adobe reader, flash player, quicktime player, etc.

HighTower's picture

As far as "Groups" do you mean Targets or do you mean Organizational Groups?  If you're talking OGs I was not successful with this because I couldn't assign the Plug-In Policy against an OG, only against a Filter.  If I remember correctly that's what led me to creating the filters in the first place.

To be honest I don't use OGs for much besides targeting for software deployments.

JeanWilson's picture

HighTower, Your process is very well developed. You should create an HOWTO article about it.

HighTower's picture

Thanks, I've been kicking the idea around for a while.

I've even got things set up to do an inventory-based patch filter membership.  I set a registry value via a Task and then use a custom inventory on that registry value.  The inventory value then drops that computer in the appropriate filter.

JeanWilson's picture

Almighty HighTower, do you mind sharing your how you did this? (your inventory patch automation) I would like to test it and employ in production.

MJammer's picture

"As far as "Groups" do you mean Targets or do you mean Organizational Groups?" When I mention groups I am talking about OU built for Altiris, not OU's that belong to Active directory. A side note, our network uses AD and our AD groups are also imported into Altiris. But we do not use are AD OU's for any deployments. Any OU's we are using are made in Altiris. We have a test OU made with a couple sub-OU's for certain testings.

I'll create a brand new filter and setup it so only my test computers appear under Filter Membership. Then i will setup that filter with one of the polices for the Adobe reader 11.0.1 bulletin.

MJammer's picture

After setting up filter; I now see three of my test computers. I am testing with APSB13-02 (Adobe reader 11.0.1 update). But the target list is the same as it was last week. Right off the bat it is displaying my three test computers plus all production computers that are allowed to get this update. Shouldn't the target list reset itself to a blank list the re-build only showing what my filter includes?

HighTower's picture

No, the target list shows all applicable computers based on the results of the Windows System Assessment Scan.

Just because they're in the target list doesn't mean that the updates will be applied.

MJammer's picture

That is good, and since my three test computers are within the list. Those three should get the update? As long as I turn on the policy and have the filter applied to that policy for the bulletin?

MJammer's picture

Everything looks ready to go

1. Filter is in place with my three test computers, I have two more test computers in preparation.

2. The test computers have the Agennt in place with Software Update Tab ready to get updates.

3. Bulletin APSB13-02 is enabled and distribution is setup with the filter under "Apply To Computers".

4. The policy for bulletin APSB13-02 is enabled. Package Options are checked off: Multicast, Run ASAP and Override Matinence Windows.

Waiting for activity to take place

MJammer's picture

I have the update's policy setup ASAP under 'Run' so it should run as soon as the update appears under the target's Software Update Tab?

I changed it from ASAP to a schedule, using agent time to begin 7/1/2013 Start time 13:00 (1:00 PM) without an end time. I setup that up at 1:07 PM today. Rebooted, logged in pc and expecting update to kick off as soon as I signed on. It is still in pending status. Override maintainence windows is checked off. Still waiting as of 1:20 PM. Shouldn't this update get applied by now?

HighTower's picture

If the update shows as Pending then the client hasn't downloaded the package yet.  Are these test clients attached to a Package Server?  Has the Package Server staged the Adobe patch yet?

Altiris patch management does not work the same as hitting the Windows Updates website as updates are not presented in the same way.  Windows patches/updates are served up the same as any policy-delivered SWD package.

MJammer's picture

All three test computers are looking at our HQ Altiris Server. That is the main server, we have sporadic package throughout our lan in multiple locations. The HQ server is where I access the Symantec Mgt. Console. At 4:12 PM they are all at the same state. What exactly do you mean by staged? The HQ server has the the update downloaded to it with it's APSB13-02\{GUID Folder]\AdbeRdrUpd11001.msp

HighTower's picture

Did this wind up working?  I didn't answer yesterday because this is a process that can wind up taking longer than you would think that it should, especially if you're in the mindset and expectation of the MS Windows Update website.

MJammer's picture

I do not have the Windows Update website in mind. We have an internal WSUS Server for our OS updates. As of 4:15 PM 7/2/13 I have still been waiting, still in 'pending status'.

Last Applied = Never

Schedule = Not Scheduled

Even though the policy for this bulletin has a schedule that began 7/1/13, no check on the end date box (so it should run forever), override maintainence windows. The HQ server has had the adobe reader 11.0.1 msp file since this was first created. So it is 'staged' correct?

I would like to compare this to the software area: Manage > Software > Deliverable Software > Releases. Also the polcies that are made in conjunction with these software releases. I have used this for Adobe Reader 11.0 back in 2012, made up a policy to run through the symantec mgt agent, but made it available so the user can run the install of 11.0 when needed; and it worked perfectly.

I would expect patch remediation center to now patch 11.0 (my test computers for right now) asap after login. More or less force run the 11.0.1 update.

HighTower's picture

I think that it's "Pending" because there is no actual schedule associated to the policy.  I know that you set the bulletin policy to ASAP but try setting the Plug-In Policy to something in the future.... just do like 12/1/2020 for giggles and see what happens.

MJammer's picture

You mean with the software update plug-in? There is something that can be arranged with a schedule that will affect how patch mgt behaves?????

HighTower's picture

Yeah, if the patch is still "pending" it's never scheduled to apply and therefore will never apply.  Even doing the manual commandline AeXPatchUtil.exe program should probably not do anything at this point. 

Setting the Plug-In Policy to a one-time event waaaay in the future allows you to get a "manual" patch type of behavior out of the system.

If you can wait a week or so I'll try to have my entire patch estate written up in an article.  Maybe it would make more sense that way.

JeanWilson's picture

Almighty HighTower, do you mind sharing your how you did this? (your inventory patch automation) I would like to test it and employ in production.

HighTower's picture

I'll write all of this up separately in an article.  I'll update this thread when i have it finished.

svillar's picture

HighTower,

I am moving from WSUS to Altiris as well.

The way I understand it, I can create 3 plugin policies for my servers based on their patch windows:

Let's say:
Policy1 - Saturday 1:00am - 100 Servers - Reboot
Policy2 - Saturday 3:00am - 100 Servers - Reboot
Policy3 - Saturday 5:00am - 200 Servers - No Reboot

Now if I create a software update filter called "All Servers" and enable a patch distribution policy for July's patches, won't all three groups of servers patch on their own schedule?

I am asking because on your original description of your process you stated that you changed the patch distribution policy "payload". Or is that only for testing? Couldn't you create 2 distribution policies? "Test" and "Production"?

HighTower's picture

You should only have one Plug-In Policy applied to any group of computers.  The Plug-In Policy dictates the computer's patch schedule, reboot policy, and agent behavior (notfications, pop-ups, etc).  If you have multiple Plug-In Policies applied you will have unpredictable results.

My "Payload" policy contains a month's worth of bulletins.  In there I target groups of computers.  And... you're correct.  I do have an "All Servers" and an "All Workstations" filters that I eventually wind up targeting.  It's simply for housekeeping or sanity's sake, though, and doesn't affect the way it works.  The Payload policy simply tells the system which computers are eligible for a given update and now how the agent is going to behave.

I'll be writing all of this up separately as part of an Article as i don't think that I'm doing all of this justice here. 

svillar's picture

One other question. I have been told that our policies should be one bulletin at a time, because more than 50 packages causes problems. We are on CMS7.1 SP2.

Thanks!

HighTower's picture

I've heard something similar but it was 100 instead of 50.  That said, I haven't encountered any problems but I do try to keep total bulletins per update policy to about 100-125.  Usually I can account for an entire month's worth of security bulletins in one policy and a separate policy for non-security updates.

svillar's picture

Sorry for not being clearer in my example.  What I am saying is that I have 400 servers divided into 3 groups.  I apply 3 different policies, but when I push out patches, I push them to all 400 servers at the same time - 1 target list - "My Servers".  The servers will remediate themselves according to the plug-in policy assigned assigned to that server, correct?

I'm trying to simplify this approach.

Thank you for answering my questions.  I look forward to your other posts.

MJammer's picture

Looking at your screenshot above, does this work on any workstation as soon as it needs to? I noticed in Package Options Run is not checked off. For my policies I check off Run and either ASAP of Schedule if I wanted to schedule when I want a policy/bulletin to run. But yours is blank; so it still runs ASAP?

Last week I finally got mine to run but only on one workstation out of five. My Altiris server admin corrected som settings under All Settings > Software > Patch Mgt. > Windows Settings > Windows Patch Remediation Settings.

HighTower's picture

Patch policies don't work the same way as SWD policies in that they only run when scheduled instead of "when scheduled or as soon as possible thereafter".  So, my workstation patch policy globally has computers configured to try to install patches at 0300, 1100, and 1700.  We figure that most of our computers will be on at one of those times as we're a 24/7 business.

I've toyed around using AeXPatchUtil.exe to run from an SWD policy to trigger the patching events even more randomly but have not had to go that far.

Finally, I've ONLY used the "Run ASAP" option once and that was when we determined that a particular patch needed to apply immediately and not wait for the next patch window/schedule.  That setting overrides any schedule that's been configured.  The KEY point here is that there needs to be a schedule assigned via the Plug-In Policy in order to make a computer understand that it's time to actually apply the patch.

MJammer's picture

So the Patch Rem Center bulletins and polcies are dependent upon the Software Update Policy schedule? There are two polcies for Software Update Plug-in: 'Software Update Plug-in Install' and 'Default Software Update Plug-in Policy'. My Altiris Admin has setup settings for this but first he cloned them. there are schedules set to run so any new workstation that receives the agent will get plug-ins immediately. So this will aslo affect my bulletins and it's policies? I cannot just setup a bulletin and policy and get it running as soon as I need it to? Seems like much more about this that I do not understand.

svillar's picture

HighTower,

Can you further explain what happens when machines aren't on?  If I set my Software Update Plug-in to kick off patches at 3:00am and my machines aren't on, what happens when the machine comes online?

HighTower's picture

At some point you should probably start your own thread for these questions :)

Patch policies don't work the same as SWD policies in that SWD policies basically are "run at xx:xx time, or as soon as possible thereafter, unless set to only run at xx:xx time".  Patch policies only run at the scheduled time.  So if you have a patch policy set for Saturday night at 10:00pm and your computers are turned off on Friday evenings you'll never wind up patching.

For this reason I've played with running AexPatchUtil.exe in a SWD to trigger patching events in an SWD manner along with having my workstation patch policy attempt to run 3x/day as I work for a 24/7 company.

JeanWilson's picture

HighTower,

Let me know which strategy is better.

We are patching several servers with different times.  example Server Group 1 - @10pm, Server Group 2 - 2@11PM.

Is it better to create one Software Update Policy with separate Software Update Plug-in Policy for each group and define the start/end time there?

or

Create several Software Update Policy, define start/end time there with one Software Update Plug-in Policy for all groups?

 Thanks

HighTower's picture

Personally I create a Software Update Policy per month for Security Bulletins and one for Windows Updates.  If I were doing third-party patching with the tool I'd probably create separate policies per vendor, I suppose.  The end result is that each bulletin only exists in one policy and that SUP eventually gets applied to "all" managed systems excluding our "Patch Never" computers.

The only scenario that I could see creating multiple SUPs would be if you were trying to target different groups of computers with different patch payloads.  I'd imagine that this would get really complicated really fast and I try to avoid complicated.

To sum it up:

July's Bulletins > July's Software Update Policy > 15 Software Update Plug-in Policies > 15 Computer Group Filters

I have the different SUPiPs defined for scheduling purposes.

MJammer's picture

An FYI Hightower, I am going to walk away from Patch Remediation for now. But I would like to get back to it one day. I feel as though Patch Remediation is not well suited for the way I want to patch our third party software. For now I am going back to SWD, a little mor work for myself but that works exactly how I need it to. Thank for you time.

HighTower's picture

No worries.  Start another thread or just come back to this one when it's time to revisit patching.