Best Practices Question: How do you prevent newly imaged Macs from running older policies?

[themacdweeb]

So just a quick polling here for the masses:

We've got plenty of older Macs on our network that still require some patching. And we've got plenty of new computers which we image that already have those patches. My question is: what methods do you all use for keeping those newly imaged Macs from running older polices? I've experimented with re-scoping policies to smart groups containing only those Macs that haven't run the policy yet, but it seems cumbersome to do so for each policy.

Thoughts and real world experiences?

Cheers (and beers...)

[rtrouton]

I generally scope my policies to smart groups, to help avoid the issue you're seeing.

[cbrewer]

Create smart groups to narrow down which computers need the patch or software update. For instance, if I'm going to deploy Firefox 19, I create a smart group that looks for a missing Firefox.app or Firefox.app which does not match version 19. Then my Firefox policy is scoped to that smart group.

[themacdweeb]

Smart groups are well and fine. But suppose you have a policy that does something non-application related, such as replacing a link in a web browser or dropping a shortcut onto a desktop? You can't create a smart group for those kind of things.

As for the Firefox 19 example, if I create a smart group that searches for v19 being present, when v20 comes out in 1.5 days from now and half my network goes out and grabs it, I'd be replacing Firefox v20 with Firefox v19 because my smart group is only searching for the version I'm suggesting. There's no "higher than" or "lesser than" options made available in Casper. Unlike Munki there are no real dependancies.

[rtrouton]

For non-application cases, I'm generally scripting what I want to do and then setting a "Once per computer" policy.

A good example of this is when I recently wanted to update server bookmarks in the Connect to Server window. I wrote a script that searched for the specific file I wanted and did an internal search and replace:

http://derflounder.wordpress.com/2013/01/10/updating-server-bookmarks-in-com-apple-sidebarlists-plis...

[themacdweeb]

Right, Rich. Which is what we're doing. Only we don't need for NEW Macs to have this policy run because we've already changed that in the image. So how are you preventing the new Macs from running this policy, say, 4 months after it's been running.

Also, thanks for the post: I've just been tasked with doing exactly the same thing here. Brilliant.

[cbrewer]

As for the Firefox 19 example, if I create a smart group that searches for v19 being present, when v20 comes out in 1.5 days from now and half my network goes out and grabs it, I'd be replacing Firefox v20 with Firefox v19 because my smart group is only searching for the version I'm suggesting.

Job security.

Seriously though, sometimes I'll add the next coming version of a software package to the smart group for that reason. Check for version 19 and version 20. Buys you a little time before you have to update your smart group.

[rtrouton]

As I see it, you've really got three options then:

1. Writing an extension attribute that checks to see if change X has been applied, using the EA's output to set up a smart group for "Macs without Change X", then assigning the policy to that smart group.

2. Set up a smart group with the criteria to exclude the Macs you want without using an extensive attribute (this will likely be painful to get right.)

3. Stop running that policy.

[rtrouton]

Forgot one:

1. Writing the script so that it checks if change X has been applied and exiting if it has.

Number four won't prevent the policy from running, but it will mean that the script handles the issue of the change already being there.

[nkalister]

use an extension attribute that reports the version number as an integer. create a smart group based off of the extension attribute and you'll get the ability to specify less than or greater than the version number.

[Josh_S]

I don't know if this is best practice, but you could also place an empty file in a location, such as "/Library/Application Support/JAMF/Receipts" because it seems like a logical choice, on the drive when you run your policy, or build your image that already has these settings in place, and then make an extension attribute to check for the presence of that file.

For example:

touch "/Library/Application Support/JAMF/Receipts/com.companyname.has.rsadesktopshortcut"

Then your extension attribute could do something like (warning, untested code ahead):

#!/bin/bash

SAVEIFS=$IFS
IFS=$'
'
result=''
for i in $(ls -1 "/Library/Application Support/JAMF/Receipts/com.companyname.has."*); do
    string=$(echo "$i" | awk -F. '{print $4}')
    if [ -n "${result}" ]; then
        result="${result},${string}"
    else
        result="${string}"
    fi
done
IFS=$SAVEIFS

printf "<result>${result}</result>"

This would make an extension attribute with a comma-separated list of things that this computer already has. And then you could just have a smart group for computers that this extension attribute is "not like" rsadesktopshortcut

It won't really help for the computers that already have this deployed. But, going forward, it would be pretty easy to mark computers that a certain policy has been run on, and not be dependent on the status of a specific policy.

[jarednichols]

I lay down the Miles Leacy special: the dummy receipt.

Basically, I have a dummy receipt that's just called what my configuration was called so that I can scope in or out those particular builds from a policy through its associated smart group.

For instance, I may have Graphics build 1.0. To create the dummy receipt, at some point I run

touch /Library/Application Support/JAMF/Receipts/Graphics-1.0.pkg

This creates a fake piece of installed software that will show up in the "Installed by Casper" area. So, let's say Graphics build 1.1 has a new Dock layout. But, I want to roll the new Dock layout out to the old builds too. "Roll them up" for instance. My smart group will include an entry for Packages Installed by Casper does not have Graphics-1.1.pkg

This way, my policy is not going to hit any machines that already have the payload that I am now including in the new image. Follow?

[JPDyson]

Miles is a wizard; the dummy receipt takes the round. It's the best way to tell yourself you've already done something.

[hkim]

That's pretty hackalicious. I wonder if JAMF will implement it more thoughtfully into next releases though, using that logic.

[mm2270]

While the dummy receipt is indeed brilliant and is still very useful, JAMF sorta kinda replaced it with Extension Attributes. You can drop literally any kind of file or folder onto a system into any location you want, and then pick it up with a simple script based EA that looks for it and reports back a Yes or No. We do that here for a number of things. I kind of prefer that method because there are some rare cases where the Receipts folder can be cleared out to address issues on a Mac, and then the dummy receipt goes out with it, breaking the method you've set up. Its less likely a hidden file or folder in /private/var/ or some other place will get deleted.

[bajones]

The way I handle this process is by scoping the policy to include all the computers that need the installation. Then I immediately open the status page of the policy and create a static group at the bottom of the page (Computers waiting to run...) and change the policy scope to only include that newly created group. I then proceed to modify the Casper Admin configurations to include the new package being installed by the policy.

This way only existing computers will run the policy and new computers will have the package already integrated in their image. When/If the policy ever fully completes running on all scoped computers I can then just delete the new static group.

[SeanA]

+1 on creating an Extension Attribute and using it as a basis for a smart group

[Chris_Hafner]

There is another option here that I love. First, I come at the smart groups a little differently. First I create a "software license" for each of the packages I patch/distribute etc. Then I can run checks against the licensed software which seems to be a lot easier than hoping an inventory will detect each and every version number variance (the reason we can have < or > in sorting app version numbers).

In this way, you can set your smart groups NOT to show anything outside you're installed software base. Lets use firefox version 19 as an example (applicable to the thread).

Assume that we're starting from scratch:
1) Lookup all the approved versions of Firefox.app that you have installed and created a licensed software "item" for each specific version. (i.e. firefox 17.0.1 and 17.0.2 and whatever). I have something like 20 versions defined, based on my user base).

2) Created a smart group called "Upgrade Firefox". In this list set, at a minimum, the following.

Under "Software Information"
"has" then choose "Licensed software" and choose each and every version of Firefox you've created a license for separated by "or".

In this way, only the users that are on versions you expect to upgrade from will be included in this group. Anyone outside of these versions will not be included and hence, not presented the policy in self service or anywhere else. That way, if you've got users that have admin access and have gone their own way, at least they will remain on their own.

This is my preferred method for keeping various groups of computers form being pummeled by other policies. The mention above about creating blank receipts is a good one as well. Particularly for policies that don't install software or detectable updates.

[JPDyson]

Yeah, an EA is useful for things you need to be able to display in a report, especially.

[themacdweeb]

guys,

thanks for all of the amazing experiences and suggestions. My initial thoughts for whatever it's worth...

Extension Attributes: simple idea, great to leverage on occasion, but maybe not used in conjunction with each and every single deployment?! That creates another long list of something else to manage. Yes, I know: it's my job to manage data but why create extra data if you don't need to?

Dummy Receipts: also simple and kind of brilliant. One central spot to manage and track the work that I've done that Casper can also track and leverage for me. The downside: that info is stored on the client, not the server, so if the computer is manipulated in any way, that data can be compromised. Chances of that happening are slim (?!?), but it's still important to consider.

Immediately Creating a Static Group on Policy Launch: nothing to track locally OR on the server = simple in the long run. Just takes a little bit extra at the start of a launch.

[themacdweeb]

As a follow-up,

When a casper policy runs, it creates a pkg in the receipts folder. So, at least for deployments of packages (not scripts) , you could scope the policy to run only a smart group that's determined by that pkg NOT being present. No extra files to create, nothing else to manage.

[mm2270]

@themacbweeb,

Good overall synopsis of the suggestions on this thread.

Just a point of clarification though. With both Extension Attributes and dummy receipts the data is stored on and being pulled from the client. The primary differences between the 2 are that
Dummy Receipts can be tracked natively in Casper using the Receipts tracking mechanism. Downside, as you mentioned is that the receipt files are stored in a standard, somewhat known location and can be removed by various troubleshooting tools, or intentionally removed by an end user if they have the rights to do so.

With EA's you have the flexibility of placing a dummy file/folder/whatever in virtually any location you want. You can obscure it with different methods, or bury it deep within the OS, or put it into a locked location (/Library/Application Support/JAMF/bin/) or whatever else you can think up. The downside is you have to write up a script to detect the file and report on it.

I think one good option to consider would be to script touching a receipt file into the /Library/Application Support/JAMF/Receipts/ folder rather than the OS native location. Its very unlikely anything from that folder would be removed unless the management framework was removed or the Mac was re-imaged. Maintenance tools probably would also leave that alone as its unlikely they'd be aware of it at all.

[glutz]

A standard policy creation we have is to first scope using smart groups but to also create dates that policies are active. This encourages us to review our policies frequently to ensure they are up to date or even if they are still valid and should be removed.

With that said the more complex you make things the more complex your management will become. It is easy to be over run with extension attributes and dummy receipts. With the pending but fairly certain features in JSS 9 and the ability to exclude in smart groups you will have the ability to create some very elaborate smart groups. I say this because it shows as "Planned" under FR.