Patch Management Group

Settings - Software - Patch - Windows - Windows Patch Remediation Settings there is a setting under software update options to set a default resource target used by software update policies so when a new policy is created a default resource target is set.

It's a nice time saver when creating policies to have my test group show up as the default policy target.

The problem is - that setting keeps disappearing on me.  I'll set it and then notice in 2 months when I go to stage new policies it's blank again.  Anyone else seen this?  Will put a ticket in but don't expect to get far with that.

It's not 100% reproducable either like if I set it today, the setting will be there tomorrow, so I can't say for sure when it disappears but it has happened when I haven't touched SIM or done any updates or changed any filters.  I just notice it the next time I go to push out a patch and the default target is empty again.

Sally5432,

A colleague of mine wrote a tool to install patches to your test group or dummy fire them as you see fit. Any PM admin should be looking at this. It would workaround your issue since the filter target for testing is set in stone on the command line in your scheduled task.

https://www-secure.symantec.com/connect/downloads/cwoc-patch-automation-full-test-life-cycle

If you find it useful let him know.

Regards,

Thanks for replying Michael.  I've seen that post before and it's impressive, but I prefer less automation until my trust with the product builds.

Inevitably, if I compare what Symantec remediation center says I need to what win updates says, it doesn't match.  A few times Remediation Center says my machines are vulnerable for patches that Win Update doesn't say I need (seemingly happening more lately than a year ago when I don't think this was happening to me at all).  In those cases, I side with Microsoft & don't install the patch.  

Also, each month there are patches that MS says I need that Symantec's PMImport doesn't include until I put a ticket in (or post an idea sometimes).  Or worse a patch is available but fails to install properly because of wrong command line in the PMImport, or the patch didn't download the latest version2, etc.

I'm lucky that I can devote the time to really troubleshooting patches as they become available, I don't even close to trust PM enough that after X days it moves policies to production for me.  I have tickets in with Patch team for patches not installing/reporting properly for months unfortunately.

here's one of my prior threads as an example

https://www-secure.symantec.com/connect/forums/cms-7x-patch-mgmt-support-frustrations-it-just-me

I hear you. I've noticed a few instances last year where Microsoft re-issued patches which causes chaos. Symantec will update the PMimport file as soon as it can but Microsoft reserves the right to change their software without notice also ;)

There was a .NET installer that didn't install correctly due to this - because the detection check was looking for a different software that had been superseeded. When customers are half way through rollouts it is confusing to resolve and ends up looking bad on the delivery mechanism instead of the originators.

I noticed a shift in Microsoft behaviour with Patch releases last year, a few clangers to say the least and the first MS Bulletin that didnt contain any security release and customers asking how they can deploy it!

Heads up though, first patch Tuesday down and we are only providing 6 out of 7 critical patches because MS13-003  refers to SQL queries being required. http://www.symantec.com/business/support/index?page=content&id=TECH201498

2013 will be interesting. Remember to keep those PMimports fresh and full ;)

The results will never be the same 100% of the time as the two products use different data sources for the underlying applicability and detection rules and things are not black and white when it comes to such matters. 

For example, the descrpitive text for some KB articles may indicate that a particular vulnerability applies to computers that meet certain conditions and which are domain controllers. However, the section of the KB article providing the information on how to determine whether an update is applicable may not contain any information suggesting that it should be verified that the computer is a domain controller.  In such cases, the information provided by Microsoft in the KB article is inconsistent and contradictory.

While Windows Update may choose to only show such updates as applicable in cases involving domain controllers based on the descriptive text in the KB article, other products may show the update as applicable in cases involving computers that are not domain controllers because of the fact that the section of the KB article listing the conditions to be checked to verify applicability did not contain ay information suggesting that it was necessary to verify that a computer is a domain controller. 

As a result of such inconsistencies in the information provided by the vendor (i.e. Microsoft), other products may choose to err on the side of caution by showing such updates are applicable to computers that are not domain controllers.  As much as people would like to think that such matters are entirely black and white, that is not the case.

It should also be noted that the Patch Management Solution does not distribute updates that have packages that cannot be downloaded in an automated manner from the vendor (e.g. some update packages can only be downloaded from Microsoft after accepting a EULA on Microsoft's web site), or updates that require manual intervention to install. (e.g. some Microsoft updates require the end user to accept the EULA and do not provide a commned line switch for automating the acceptance of same).

Hi Sally5432,

Do you use different roles for working with NS Console (especially with target that disappears sometimes)? As idea,  this issue may be related to different permissions for different roles, for example when one role modifies target and then modified target becomes hidden for another role due to specific settings of  permissions.

Thanks,

Roman

I only use the symantec admin role, Roman.

View KM: HOWTO79488, for it details the owner of the targeted filter must be the Application Identity. You may create an empty filter with those user credentials logged in and apply it to the Windows Patch Remediation Settings.

I have found that implementing under Apply to > 'Quick apply' and type in the name of the custom filter; select the dropdown arrow and it should be listed, and select 'Apply,' and Save Changes. This will apply to that 'Target' as apposed to a single computer filter.

Next, run the 'NS.Complete Resource Membership Update' SMP scheduled task and see if the filter is still present on the policy when this process is complete.

Additionally, as an added precaution; ensure that filter is no updated via ADImport or other automated filter update processes outside Altiris.

@Joshua - thanks for this.  I updated the policy while logged in as CMS notif user on the server last week and so far it has stuck.  I'll report back in a few weeks if it stays.

Sally5432,

If you find the filter for the Patch Remediation Settings policy is still getting cleared; review
KM: TECH204204, for it details a Known Issue with this process.

Note: this is not necessary if the App ID ownership resolved the issue, but I wanted to provide all data to assist with this problem.

@Joshua - it did clear itself again.  Checking out the other TECH article now

@Joshua, I followed the other tech article and it's blank again today.  I give up :(

Hello Sally/Joshua, does this stored procedure work correctly?

I am also planning to implement a custom filter in my environment for patches, please respond if there is any issue.

Regards,

Atif Shafique

@atif - see my last post in July.  No, it didn't work.  I wonder if this is fixed in 7.5

Reviewed the SQL script; found it is in order. That script stops the deletion of any Patch Management (PM) related Targets.

To clarify, when a Filter is targeted by a PM Policy; that filter becomes associated with Patch Management, and in conjunction with the creating user's permissions; becomes a Target.

The process that is performed by the default Stored Procedure (SP) is to clean up unused Targets. The updated SQL script from TECH204204 allows for the process to clear unused Targets to complete, but excludes any related to PM. Note: the Filter is not deleted; merely the unused Target(s).

Keep in mind that a Database rollback, repair of the product, or any other restore process which would affect this SP will put the default SP back in place, and the updated SP will need to be reimplemented.