Do you have the labs broken up into static groups or do you have them differentiated some other way?

For example, we have ours in static groups that get populated by a script that runs after the machine is imaged based on the machine name (we use something like T802-M02 for machines) and software policies that are just scoped to whatever groups require them.

We also have things broken down with dummy receipts that we call "cohorts." It's just a hidden text file that has the machine "type" like LAB, SMART-CLASSROOM, STUDIO, etc. so when we make policies we also can scope to the larger groups if needed. We actually have a few more dummy receipts that get dropped for various things...it's really useful because that information doesn't change even if someone renames a computer.

I also use the static group approach but I'm very interested in the dummy receipt you speak of. Can you share a copy of your text file or script with us?

Sure.

#!/bin/sh

# Creation functions for each cohort
lab () {
    echo "LAB" > /Library/JAMF DM/Cohort/RECEIPT-LAB.txt
}

studio () {
    echo "STUDIO" > /Library/JAMF DM/Cohort/RECEIPT-STUDIO.txt
}

suite () {
    echo "SUITE" > /Library/JAMF DM/Cohort/RECEIPT-SUITE.txt
}

smart_classroom () {
    echo "SMART-CLASSROOM" > /Library/JAMF DM/Cohort/RECEIPT-SMART-CLASSROOM.txt
}

music () {
    echo "MUSIC" > /Library/JAMF DM/Cohort/RECEIPT-MUSIC.txt
}

# Get room number from system name
roomNumber=`scutil --get ComputerName | awk 'BEGIN {FS="-"} END {print $1}' | tr "[a-z]" "[A-Z]"`

# Arrays for all of our different types of rooms
labNumber=(A309 A615 A626 A728 AB9 AM11 M707 T1113 T1212 T1213 T1219 T1223 T1328 T1402 T1421 T1423 T1425 T1506 T802 T907)
TsmartClass=(T1014 T1049 T1053 T1102 T1106 T1121 T1202 T1703 T202 T511 T602 T604 T608 T702 T704 T706 T710 T712 T714 T716 T806 T831 T833 T902)
AsmartClass=(AB16)
GsmartClass=(G405 G408 G410 G411 G415 H312)
StudioT=(T1404 T1408)
StudioA=(A315 A316 A317 A318 A319 A231 A220 A716 A723 A725 A726)
suiteVoice=(T612 T614 T616 T618 T620 T700 T709)
suiteGen=(T1112 T1403 T1405 T1407 T1409 T1410 T1412 T1414 T1415 T1416 T1513) #generic suites
suiteDragon=(T1403 T1405 T1407 T1409)
suiteDragonUM=(T1421A T1421B T1425B T1425C)
editBay=(T1108 T1109 T1111 T1114 T1115 T1116 T1117 T1118 T1119)

# Make "JAMF DM" directory and hide it
mkdir /Library/JAMF DM
mkdir /Library/JAMF DM/Cohort
chflags hidden /Library/JAMF DM

# Automatically choose the appropriate Cohort based on room number.
if [[ " ${labNumber[@]} " =~ " ${roomNumber} " ]]; then
    lab

elif [[ " ${StudioT[@]} " =~ " ${roomNumber} " ]]; then
    studio

elif [[ " ${StudioA[@]} " =~ " ${roomNumber} " ]]; then
    studio

elif [[ " ${suiteVoice[@]} " =~ " ${roomNumber} " ]]; then
    suite

elif [[ " ${suiteGen[@]} " =~ " ${roomNumber} " ]]; then
    suite

elif [[ " ${suiteDragon[@]} " =~ " ${roomNumber} " ]]; then
    suite

elif [[ " ${suiteDragonUM[@]} " =~ " ${roomNumber} " ]]; then
    suite

elif [[ " ${editBay[@]} " =~ " ${roomNumber} " ]]; then
    studio

elif [[ " ${TsmartClass[@]} " =~ " ${roomNumber} " ]]; then
    smart_classroom

elif [[ " ${AsmartClass[@]} " =~ " ${roomNumber} " ]]; then
    smart_classroom

elif [[ " ${GsmartClass[@]} " =~ " ${roomNumber} " ]]; then
    smart_classroom

else
    echo "$roomNumber does not match any public spaces. No cohort will be added."
    exit 1

fi

It works because all of our machines follow the same naming method, and you can customize this to make any type of receipt.

We use a script like to to also deploy public printers..same basic idea except the functions call a jamf policy to add a printer.

This would be a perfect situation for using the buildings/departments settings under "network organization".

Depending on how your wanting to organise things, a possible better solution than static groups is a drop down list EA.
You could have a drop down called something like "Lab Environment" with "None", "Music 1", "Music 2", etc... Then make smart groups based on this value.
This gives you control directly from the JSS as to what a machine is and the changes are immediate because they happen directly in the DB so no waiting for Inventory Update.
Personally we are using a naming convention based on room number for most of this, but I sometimes use the above approach for assigning devices temporary roles (like running presentations etc...).

Taking a slightly different route, we add custom triggers to all soft are deployment policies, and group them in deployment scripts that (amongst other things), call the relevant policies via jamf policy -event.

We make the deployment script available via a self service policy. This removes the need for smart groups or complex scoping as the tech just has to run the relevant deployment policy.

In my case we setup different smart groups...one smart group to each lab and if a piece of software is to be scoped to multiple labs (say media lab 1 and media lab 2). I declare two targets.

I formulate the groups by declaring location information for each device (for example in our case Jefferson High School Art Lab 1 would have a building of JHS and a room number of say 105 and a department of All Art Labs). My smart group criteria would then be Building = Jefferson, Department = All Art Labs, Room = 105 and I would name the smart group "Jefferson High School Art Lab 1".

Say Adobe Creative Cloud goes in both Jefferson High School Art Labs...I would simply create a policy to install Adobe Creative Cloud (and any ancillary packages that go with it) and scope it to both "Jefferson High School Art Lab 1" and "Jefferson High School Art Lab 2". I guess I could create another smart group that contains all members of Jefferson High School Art Lab 1 or Jefferson High School Art Lab 2 but I really don't want to have more smart groups created than are necessary.

@jmahlman @blackholemac Do you have the software policy simple scoped with the trigger "once per computer"?

@pandrum Yep!

@jmahlman @Look @davidacland I am enrolling around 100 iMacs that already has a bunch of software installed and that comes from another software management system.

Take for example Firefox.

I was toying with the idea that you first have a static group called "Lab 1". Then a smart group called "Install Firefox" with the criterias "Application title IS NOT Firefox.app AND Computer group member of "Lab 1".

This way you still get the benefit of selective deployment, but also the logic with the smart group. My concern is however that this creates more overhead...

Thoughts?

That would technically work, we used to do something like that with our antivirus on staff laptops. It can cause problems (say if installs keep failing) but for the most part it worked well enough.

On our labs, people can’t remove software, so once per computer is fine.

That would technically work, we used to do something like that with our antivirus on staff laptops. It can cause problems (say if installs keep failing) but for the most part it worked well enough. On our labs, people can’t remove software, so once per computer is fine.

This is also true for me. Good point.

One way to help that is to make the policy run once per day, that way if something goes wrong you don’t run it every 15 minutes.