Separate "staff" and "computer lab" in Jamf

[pandrum]

We have about 300 MacBook Pros for staffs at our university and 100 iMacs for students in computer labs.

I want to have separate policies for these two "groups".

For staff I want to go with the Self Service approach - users download what they want from Self Service.

For labs I want everything to happen silently in the background. No Self Service installed.

For now I am using a lot of exclusions for my scopes but I think it becomes unwieldy pretty quickly.

I've heard some folks that have made sites and divided policies and computers amongst them two. Im thinking of going this direction.

Any tips?

[dsavageED · Accepted solution]

Hi pandrum,

We are just in the process of doing this on our Jamf environment. We have a site for labs which keeps all the config profiles and polices for labs separate, the site can also have its own device enrolment identity so if you are using DEP already (or planning to) you can have the separation. The big advantage over a site instead of a new Jamf instance is you can utilise the same packages and scripts, so you aren't duplicating your effort or maintaining code in two places. Our staff are just in the "Full Jamf Pro" area, this means you can see the labs policies, to keep this relatively tidy I created three categories all starting with xLabs to put them to the bottom.

We haven't created a site for staff as our staff environment is live with over 1300 Macs and around 300 policies, but in retrospect I probably would have preferred to have the staff Macs in a site too, so the full Jamf Pro becomes a single pane of glass to see everything or you can focus in on a particular site.

[davidacland]

We normally use an pop-up menu extension attribute to define the "type" of Mac.

That can be used directly in scoping, or via a smart group.

[dmw3]

We seperate staff and lab computers with policies, lab only policies have a designation "Lab-" in front of the policy name, staff policies do not. We also seperate them out with categories, "Lab", "Staff Only", "Core" (which are applied across every computer).

Also we have AD Security Groups that are assigned to Labs and Staff, so really we can define the policy usage on a number of levels.

[MichaelC]

We've used a site-based approach from the beginning, to separate staff, student and lecture theatre computers, which all have different management requirements. We've since had a few more departments sign on, and have given them each their own site to manage. That way if someone makes a mistake, the divisions between sites help prevent it causing problems outside that person's own area of responsibility.

[pandrum]

@dsavageED I've decided to go with this approach. One site for our staff called "Staff" and one for our labs called "Computer Labs".

This organisational approach makes a lot more sense both for me and for our helpdesk staff when they are working with the JSS. The get the full overview you can just navigate to "Full Jamf Pro".

Also if a misstake gets made it doesn't effect other sites, as you said @MichaelC

[Volker]

We use smart groups based on client hostname, and slightly different naming conventions for staff vs. lab hosts. Works pretty well for us.

[Look]

We are the same as @Volker devices are named by a script call to an asset database on enrollment, then smart grouped based on the name.
If you wanted to get around having an external database I quite like the drop down extension attribute (or pop if you prefer) idea. I have used drop down list EAs before to temporarily assign devices certain roles and they work really well because any grouping etc... is immediate as the change was made on the JSS directly, it's especially good for making items available in Self Service for certain devices basically on demand in response to a user query.

[jhuls]

I'm developing a configuration that might be somewhat similar to @Look systems in that they're named with a script but it pulls data out of a csv that gets accessed from a file share. That csv is currently generated by hand but is getting changed to one that gets generated by our inventory database. The script sets the name, sets admin for a specific user if needed, etc. I've run into a quirk with having the script bind the system to the domain where it appears that the Mac doesn't have something ready to go before it can be named when it's a new system but this is unrelated to the naming portion as far as I know. The naming works perfect.

From there smart groups take over. I can't define offices because it would be ludicrous to enter that many rooms in so I instead define known labs and classrooms along with any specific production areas. The Office Users group then becomes everything else that isn't known but still needs to be in our AD domain.

As for policies it depends on what it is...for applications like Office and Adobe Creative Cloud I'll have separate policies with offices getting one for Self Service but for labs and classrooms those will be configured for automated install. Something like Flash player installs automatically on initial install and then gets scheduled updates so it's one policy.

Quite honestly if it were me I wouldn't touch sites for something like this because I wouldn't want the hassle of revamping things should I need that kind of feature later. Smart groups work really well for this...in my environment at least.

For what it's worth I use to use Categories to break out my policies for Offices and Labs/Classrooms but revamped that a couple years ago as I got tired of searching through similar policies in different areas so I broke categories up into sections like Software, Printers, etc. This made a lot more sense for me since some policies were shared(flash player and others as well as some printers).

Jamf gives you a number of ways to organize things so what's good for one person may not be good for another. Flexibility is nice. If sites makes sense for you, go for it.