organization best practices

[Krytos]

Hello everyone,

I'm having a hard time finding some best practices for site/building/etc organization.

I work at a university where we want a pretty strong centralized presence, but also the ability for each department to manage some of their own policies.

Whats the best way to do this....right now we've setup each department as their own site -- which is fine for each department. Until you look at our full JSS and realize a TON of work has been duplicated by different organizations....how do you all avoid this?

[pat_best]

I would like to hear any input on this question as well, just a little bump!

[kturnbeaugh]

So, to each their own and it's personalized for every environment, but here's mine.

I am the Casper Lead for the University I work at. We have a lot of different schools within our University. I manage the JSS and have each site set to a membership based on an LDAP group. If someone needs access to more than one site we add them to the membership of the LDAP group. I manage the basic Universal packages, Office, Chrome, Firefox, OS, java, flash, as well as our universal software applications like Adobe Pro. I update the JSS and manage creation and deployment of quick-add packages, and also manage creating the configurations in Casper Admin for each school.

The techs at the other schools that are trained and feel comfortable doing so, create ONLY the packages that are needed to deploy specific software applications. They then upload the created pkg or dmg to an SMB share and I import it into Casper Admin/JSS.

Any policies that they'd like to deploy, they can create but must be restricted to their site, and some level of testing must be done by scoping it to test machines prior to deploying it out to their base. I manage the Universal policies, and any duplicates are what they are at this point. I wish there was a way besides setting the site to NONE that we could scope policies to multiple sites without having to recreate it. Here's the feature request that is the closest match to this request. https://jamfnation.jamfsoftware.com/featureRequest.html?id=1401

Our problem so far is VPP and DEP. I have no advice for working around that issue.

[pat_best]

thanks for the reply!!

[rdwhitt]

JAMF FOR THE LOVE OF ALL THAT IS DECENT, PLEASE GIVE SITES SOME LOVE! Sites were a nice idea, but they haven’t improved at all since they were first introduced. Please please please!

Now that we have that out of the way, here’s the gist of what we do.

I’m not too concerned with duplication of software policies since I want site admins to choose how and when they deploy software. However, I want to avoid duplication of software packages themselves. We provide many common software packages for things like Creative Cloud, Office, Flash, Java, and much more as long as it either uses our institutional licensing or is freeware. We use naming conventions to ensure that admins know what they can and can’t use. If something has a prefix of “GLOBAL_softwareTitle.pkg” there are no customizations and any site can use it. If it has a site prefix on the software then only that site should use it.

Each global software package we maintain also gets a corresponding Self Service policy that sites can opt to have scoped to their devices. For many of our sites, rather than creating software policies, they just opt in to this and point their users to Self Service.

We also didn’t want to be the keeper of all Casper objects and we strive to provide our admins with as much access as we can without negatively impacting other sites. With that in mind we developed tools using the API (and extra mojo) that allow site admins to upload their own software, scripts, and printers, while enforcing the site naming conventions.

We have a mirrored test environment that sites are placed in first. We provide a day of training (kind of a mini jumpstart) to sites and emphasize all of the rules they need to follow in our environment. Once they have setup everything in test and are comfortable, we move them into production. They continue to have access to our test environment, which allows us to test Casper upgrades and have site admins verify their workflows before we upgrade the production environment.

Communication is always key, so no matter what you do just be upfront with your admins and allow them to provide input.