Client Management Suite

An item of feedback which I've been trying to push to PMs on Patch Management is the issue of vendor patches not always being patches. This can cause headaches when you find full product installs being pushed down as a patch.

To illustrate, let's take the classic and must loved Adobe Reader. Let's assume we have in our environment Adobe Reader 9.1.2 which we've released as a SWD package. We've crafted the transform to,

1. Not put that useless shortcut on the desktop
2. Not to update. Why put the lovely icon in the systray to update adobe reader when the user's are locked down and will only get errors...
3. Remove Digital Editions.

Now enter Patch Management. It rightly sees an out-of-date Adobe Reader and thus schedules the following 'patches' to come down,

1. APSB09-15 AdbeRdr920_en_US.exe
2. APSB10-02 AdbeRdr930_en_US.exe
3. APSB10-21 AdbeRdr940_en_US.exe
4. APSB10-28 AdobeRdrUpd941_all_incr.msp

The top three, not being patches, just uninstall Adobe Reader and re-install the latest version as if installed directly from the web. The result is we've lost all our customisations the moment the first patch comes down.

I can live with the shortcut coming back, and even digital editions. But having user's being nagged about updates they can't install is a bit of a problem.

At the moment this problem is limited to Adobe Reader. As the vendor pool opens up though with Altiris Patch Management this will get worse.

Is this a problem for anyone else, or is it just me?

This is the behaviour for Adobe patching in Altiris. What we have done is to incorporate all of those settings on a different job and execute the job when the system is not in compliance.

This is what we do here too, we patch our systems by our own compliance checking followed by software delivery if required.

So we replicate in software delivery what patch does.

It just seems just a shame that Patch doesn't seem to understand that desktop teams who are managing vendor patch releases across their environments will want at the very least the vendor auto-update components disabled.

This issue will get become more frustrating as patch increases it's vendor scope. It's only frustrating because here is a product which very, very nearly does what we want, and looks great, but we can't use it.

I understand though that the extra features which would enable us to customise patch (or for the patch teams to modify the vendor packages) are not in scope for the product.

I am experiencing the same problem, and was considering just using software delivery each time however..

I am currently playing with the idea of using the adobe patch mangement to deploy the updates, but using software management policies to disable the auto udpater and enforce our chosen configurations.

So far, I have disabled the adobe updater from running and also turned off the auto udates for adobe reader using a managed delivery policy with compliance checking.

As the auto updater executable and the auto updates settings are controlled via registry keys, the compliance check runs each day and at computer start up. If they have been changed, they are reset.

This still leaves flash player to test, however I have just noticed that it can be controlled via a config file on the machine (see http://kb2.adobe.com/cps/167/16701594.html)

which again should be easy to enforce using a manged delivery policy.

I've seen the Symantec view elsewhere on Connect (no link at the moment) which says, essentially: we hate this too.  But it's the software vendor's fault, and we can't be expected to fix their shortcomings.

Isn't almost the whole point of a tool like Altiris to fix other software vendor shortcomings? That their software needs updating frequently and the tools they vendors provide are inadequate?

Another view would be that it exists to provide leverage or automation.  Do more or do it faster, but not necessarily anything different than you could provide manually.

Whatever my viewpoint, I am in the crowd wishing for a little help from Symantec on the Adobe issue, though.