/build/static/layout/Breadcrumb_cap_w.png

Managed Installations and Patching conflicting

Apologies for the wall of text, I've tried to give as much detail as possible.

Up until now we’ve used a WSUS server for our patching. As we’ve had the K1000 for a few years but never tried the patching engine we thought we’d take a look, given that WSUS only allows us to patch the OS, we’re keen to see what the Application Patching in the K1000 can do for us.

However, I’ve encountered a situation which I haven’t seen covered in any KKE’s and certainly wasn’t covered in my training (which was a few years ago now on v5.1!).

We are using Managed Installations to install nearly all our software. Any large applications like CS5.5 or Office at installed as part of the K2000 installation leaving any remaining applications like Adobe Reader, Flash and departmental applications to be installed via the K1000 Agent.

These Managed Installations are assigned to workstations via LDAP labels for each departmental OU in our Active Directory which works quite nicely. As long as the Computer Account goes into the correct OU, the K1000 will always deploy the correct software.

This has worked without any issues since I set it up over a year ago.

However, now that we’ve begun patching I’ve stumbled on a problem relating to software that can be patched via the K1000 Patching Engine.

For example, Adobe Flash Player.  We currently have a Managed Installation for Flash setup to deploy v15 to the LDAP Label for the root OU that contains all our non-server computer accounts.

This has worked fine and all the machines we wanted to get v15 now have it.

As I’m testing patching at the moment I setup my test machine so it falls under this same label scope. As expected it gets all its software via the MI’s and is ready for its patching run which ran overnight last night.

This morning I checked the logs and can see that the patching run was successful and all OS and Application patches were applied, but there are now Failures under the Managed Installations.

As Adobe Flash Player has been updated to v16, the Managed Installation can see that v15 is missing and tries to install it but can’t, so it fails.

This happens with all software that the K1000 can patch – Flash, Reader, Shockwave, Java, Audacity, Notepad++ and Paint.net to name a few.

Obviously the simple solution (and how we used to patch in the past) would be to update the Managed Installation, however I can’t keep up with Java and Flash releases and I’d never get anything else done! The Managed Installations will be updated to newer version during our next Holiday Period (Half-Term), but until that point my reports will keep showing Failed Installations.

The only solution I can think of at the moment would be to use a Smart Label for these installations so that the machines are removed from the Managed Installation scope after the software has been installed and setting the Software Inventory record to only install on Windows 7 and 8 to prevent installation on Servers.

Something like…

SELECT MACHINE.NAME AS SYSTEM_NAME, SYSTEM_DESCRIPTION,
MACHINE.IP, MACHINE.MAC, MACHINE.ID as TOPIC_ID FROM MACHINE  WHERE ((not exists  (select 1 from SOFTWARE, MACHINE_SOFTWARE_JT
where MACHINE_SOFTWARE_JT.MACHINE_ID = MACHINE.ID AND SOFTWARE.ID = MACHINE_SOFTWARE_JT.SOFTWARE_ID
and SOFTWARE.DISPLAY_NAME LIKE 'Adobe Flash Player%')) )

Which is fine for the Software which is going to be Site Wide (excluding servers) but what would be the best way to deploy software which needs to be installed on user workstations but only in a certain OU. For example, Audacity in just the ICT Suites.

Would a Smart Label that checked for LDAP Label Membership AND Software the most efficient?

 Something like…

SELECT MACHINE.NAME AS SYSTEM_NAME, SYSTEM_DESCRIPTION,
MACHINE.IP, MACHINE.MAC, MACHINE.ID as TOPIC_ID FROM MACHINE  WHERE ((( exists  (select 1 from LABEL, MACHINE_LABEL_JT where
MACHINE.ID = MACHINE_LABEL_JT.MACHINE_ID AND MACHINE_LABEL_JT.LABEL_ID =
LABEL.ID  AND LABEL.TYPE <>
'hidden' and LABEL.NAME = 'OU: Computers - Main School - Desktops - Suites -
ICT')) ) AND (not exists  (select 1 from
SOFTWARE, MACHINE_SOFTWARE_JT where MACHINE_SOFTWARE_JT.MACHINE_ID = MACHINE.ID
AND SOFTWARE.ID = MACHINE_SOFTWARE_JT.SOFTWARE_ID and SOFTWARE.DISPLAY_NAME
LIKE 'Audacity%')) )

Forgive the perhaps messing SQL, I tend to hack my way through most queries. These were made with the Smart Label editor then tweaked by hand.

Would it be better to use the LDAP Label ID rather than its name just in case the Label gets renamed?

Any help or guidance on Best Practice for this sort of setup would be most appreciated.

If using LDAP Labels for MI targeting isn’t the best solution I’m quite open to alternative suggestions.

In the past we did use breadcrumbs on the machine which added them to smart labels for MI targeting, but I’ve found the OU route much cleaner in the long run.


0 Comments   [ + ] Show comments

Answers (2)

Answer Summary:
Posted by: SMal.tmcc 9 years ago
Red Belt
2

Top Answer

You can create a CIR for that software, such as adobe and java that checks for the software to exist not the one version.  Upload the software to the CIR tie the MI to that. If that software does not exist the MI will install it and patching will keep it up to date after.

Comments:
  • Note: It will take to the next patching cycle to get the software up to date. - SMal.tmcc 9 years ago
Posted by: rockhead44 9 years ago
Red Belt
0
I use smart labels for managed installs that need to stay at a certain version, such as Java. That way I control the version. I do not patch Java using the K1000. 
I have a MI for Flash that deploys version whatever (in my case it's old and I need to update it from version 12) using a smart label to target machines that do not have Flash installed, period. From there patching takes over and handles my version updates and my MI is no longer involved on those machines. 
Admittedly, I don't use LDAP Labels at all and do everything with Smart Labels. 
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ