Skip to main content

Hello everyone,



I'm hoping to create a policy that's scoped to the Macs that still haven't installed Security Update 2014-002. My preference would be to use a smart group for this, since I'm sure I would use it again for future software updates. But "name of software update" is not among the smart group criteria.



I can think of a few workarounds for this, but none of them feel right:



1) Collect names of software updates in an extension attribute, and create a smart group based on that. But this seems redundant, since Casper's inventory already knows which software updates are available for which Macs.



2) Run a script on every computer, and have that script call a custom trigger if it determines a eligible update is available. Messy because it forces us to update the script each time a new software update is deemed "critical."



3) Use the inventory to look up which computers need the update, and then create a static group from those computers. Not ideal because the way our policy handles user deferrals requires it to be removed from the scope after the update is installed, which a static group would not do.



Any ideas from the hivebrain?



Elliot

Elliot,



The way I handle this is to scope a smart group to "Packages Installed By Installer.app/SWU" and the criteria for this specific need would be has or doesn't have:



com.apple.pkg.update.security.10.7.5.11G1097.2014.002 - for 10.7
com.apple.pkg.update.security.10.8.5.12F1039.2014.002 - for 10.8
com.apple.pkg.update.security.10.9.2.13C1021.2014.002 - for 10.9



Thanks,
Shaun

Thanks, Shaun. That's very helpful, and seems to get me closer to what I want. I've created smart groups for each of the OSs and packages you mentioned.



However, I compared the results of those smart groups to the results of my inventory search for software updates with name "2014-002", and I got differing results. The inventory search reveals that there are 25 computers that need some flavor of the 2014-002 update. But the three smart groups contain a combined 85 members.



Is it possible that some computers who legitimately don't need the 2014-002 update also lack the com.apple.pkg.update.security.* files?

I think I've found a workable solution to this, thanks to Shaun's tip and some trial-and-error.



I configured the Smart Groups as follows (suggestions welcome, if you think the logic could be streamlined):



Critical update needed: Security Update 2014-002 for 10.9
( Operating System like 10.9
and Packages Installed by Installer.app/SWU does not have com.apple.pkg.update.security.10.9.2.13C1021.2014.002 )
and Number of Available Updates more than 0



Critical update needed: Security Update 2014-002 for 10.8
( Operating System like 10.8
and Packages Installed by Installer.app/SWU does not have com.apple.pkg.update.security.10.8.5.12F1039.2014.002 )
and Number of Available Updates more than 0



Critical update needed: Security Update 2014-002 for 10.7
( Operating System like 10.7
and Packages Installed by Installer.app/SWU does not have com.apple.pkg.update.security.10.7.5.11G1097.2014.002 )
and Number of Available Updates more than 0



Upon doing this, the sum of the computers in the smart groups was 49. But the computers listed as having the *2014-002* updates available in the inventory search was only 23. I think I know why:



The "available updates" data in the inventory search is only updated when computers run a recon (inventory update), which includes an Apple software update check. So the extra 26 computers in the smart groups DO need the 2014-002 update, but just don't know it yet because they haven't run recon since the update came out. Those are the computers that are unused or in storage, I think.



So these smart groups seem like a stable platform from which we can scope an automatic update policy that specifically targets computers for which a critical update is available, without bothering those that only need minor updates. I'll roll it out and report back.



Elliot

Elliot,



Glad you found my post helpful



I think some of the initial issue could have been could (and this is speculation) the SWU packages it lists OS by build so your packages may be slightly different.



Machines recon'ing in and other factors could certainly be involved but sounds like you basically have the solution working!



Shaun

Reply


Terms & ConditionsCookie settings