What are your software policy Scopes based on?

I'm using LDAP user groups as limitations for policies. These are policies that are available via Self Service. Policies that are more like admin maintenance tasks (Flash and Java updates), I just scope to all computers and are not visible to the end user.

I'm pretty new to Casper Suite, so I'm still working out what's best for our environment, but the above seems to work for me for now.

I use Departments for scope as well. I created a Smart group that looks if the department field is empty and I have it in my dashboard. I recommend my entire team to have it in theirs as well, so anyone can quickly see if department was forgotten.

We primary use Smart Groups (Static Groups for pilot testing). We utilize a standard naming convention, so we have this Smart Group as our core standard in other Smart Groups... From there, we add other criteria such as package receipts (or lack of) and/or application and version information.

We generally use a mix of smart groups and static groups. We would like to have the utopia of a completely automated system but static groups are always more reliable and creating a complex systems of EAs and smart groups can be a recipe for trouble.

@davidacland sparked something - I would love to be able to strictly use Static Groups for 'push-only' deployments/policies, but without being able to copy and paste SQL code in to create that group, its really a lot of work to manually select machines one-by-one. We are thus kinda stuck using Smart Groups...

Most of ours are one way or another based on a combination of the following.

Smart groups based on current machine configuration.
Smart groups based on machine name (we have a naming convention and automagically naming and renaming of machines when they are reimaged or moved).
AD groups of the current user or known owner.

We use smart groups. All machines imaged with Casper get a dummy receipt based on position and/or department, so we use those dummy receipts to scope policies if/when needed. For scoping in Self Service, we use LDAP groups.

@davidacland - Utopia is being able to plonk a machine on a desk and image it with nothing more than a Base OS and then sitting back and watching the extension attributes do their thing :) 8/21 minutes reimage time (ssd vs. sata) and within 2 hours (check-in every hour) I'm 99% confident that all machines that are on have their software installed. The occasional "failed" lines in the logs are what I work out of now.

I use extensions attribute for each piece of software I need to version control/update. eg.

#!/bin/bash
extAttr="/Applications/Skype.app/Contents/Info.plist"
xmlTag="CFBundleVersion"
if [ -e $extAttr ]; then
    echo "<result>$( defaults read $extAttr $xmlTag )</result>"
else
    echo "<result>not installed</result>"
fi

Followed by a smart group, in this instance named "Updates - Skype", where the extension attribute is NOT-LIKE "x", where x is the version you'd like as your standard.

A policy runs as an ongoing targeting the "Updates - Skype" smart group, once installed an Inventory report shows the version matching "x", therefore it's no longer in the group. There's something satisfying about watching a group-count head toward zero.

There's another dozen or so apps that I do this for that are spread across a number of faculties, but most software goes into its own policy (categorised by Faculty) so that I can easily report on success/failed installs.