Possible use case I can think of:
You have an umbrella organisation that has a central IT and smaller teams allocated to each member organisation.
You could use a site per company under the umbrella, and use this to limit access for IT admin staff to their dedicated area and then give the central IT overall access.
Or even still use sites with a single central IT but to limit the management and policies to certain member companies to prevent 'site wide' push outs.
Most people seem to use them for geographical reasons. Then again, JAMF provide you the option, and if it doesn't suit your setup, you don't have to use it : )
Hope that helps!
Thanks guys. I am in a K-12 District and am looking to have site based admins and separate profiles.
Is it possible to be able to have 1 VPP account for all sites though? Could I push out profiles for everyone and not have to do separate profiles per site?
And then, if I were to implement sites, would I be able to keep Computer Based Self-Service and all other policies as global if I want to?
Others, please feel free to correct me if I get anything wrong below.
@usher.br, if you don't assign a site to a policy, profile, etc, then it is technically global and applies to all sites.
Where this can be annoying though is lets say you have 4 sites, and you have a config profile that you want to apply to 3 out of those 4. To make that work you can't assign the same profile to multiple sites. You can only either be global, or strictly assigned to one site. So that config profile would need to be re-created 3 times for each site.
Weirdly, you can't exclude or include a Site in the Scope pane of a policy, but you can in the General pane which Site you want the policy active in.
We have a global organization with many different network segments in Europe, the Americas and the Pacific. Scoping policies by building or network segment when we have different VPN policies, or software distribution policies for different continents is tedious. Much easier to divide the logical boundaries for such things among sites.
@donmontalvo They can but they'll have to be added to a group with Full JSS permissions and have the Casper Admin rights. It's a little "wonky" as I'd call it. They will first have to change from their site in the pull down menu of the web interface and select Full JSS. Otherwise they'll get errors trying to update the information in the database. It's not a well designed method at this point. :-(
@donmontalvo Well if they are a top level (Full JSS) admin, then technically they're an admin of all sites. Not sure how to explain how we've elected to setup security and keep it brief. We use AD security groups and this is basically what we've done.
Full JSS Admins - AD security group Casper-Full-JSS-Admins (these people can create sites, assign permissions, create distribution points, etc.
Department-A-Admin - AD security group the department sets up. (these folks are full "site" admins for the department A site)
Department-B-Admin - Same scenario, they are full admins for their department B site.
The Department-A-Admins (and B) by default do not have the ability to run Casper Admin and upload packages. This is a feature we feel our admins should have. So they can create their own custom packages and upload them. Also create AD binding, Imaging Configurations, and so forth.
So to accommodate them, we create a Packaging-Configuration group and have a corresponding AD group that we put both Department-A-Admins, and B admins in. That group when added to the JSS gets Full JSS but "custom" privileges. In custom we only give them Casper Admin. In selecting that it will give them Create Packages, Create Configurations, and a couple other JSS functions. But they don't have access to another sites computers, policies, etc. So this is how we twist the security to work. But the reason I called it "wonky" is that depending on the Casper tool you're using you have to switch the web interface between Full JSS and your site in order to work. So if you need to upload a package or create a configuration, you have to log into the JSS and select the Full JSS from the drop down. Then you can use Casper Admin. However, if you want to run Casper Remote you have to log into the JSS and choose your site before you can see your computers and perform actions.
Like I said, not ideal, but the only way we've found short of creating multiple ID's for admins to use the various features.
Hope this makes sense.
@donmontalvo In addition the above, I have 2 ID's in our active directory environment. My "tech" ID is a Full JSS admin. My day to day work ID is in a couple different AD security groups for site admin access. So that single ID can switch between sights and see machines and policies in different sites. This is handy to admin at the sight level without multiple IDs.
So if you need to upload a package or create a configuration, you have to log into the JSS and select the Full JSS from the drop down.
Thanks for confirming. Looks like @dlondon has a feature request in already. I voted it up:
Allow Site Admin to use Casper Admin
Hi, better late than never, we having just taking over a primary school under our umbrella and as such have not had need of sites until now, if i create a new site for this primary school would i need to to create new policies for it or could i copy existing ones and apply these to the new site.
The word "site" when this feature was released was really a poor choice. "Delegation" would have been better.
As IT administrators, we think of sites as physical locations (buildings, cities, etc.). As such, we begin thinking we can use Sites in Jamf Pro to organize and group objects in the JSS. That's not what the Sites feature does. The Sites feature is about delegation not organization.
A Jamf Site would allow you to assign one or more Jamf Pro administrators responsibility over objects you assign to that Site. Site administrators can create their own groups, create their own policies, apply profile and software restrictions, etc., to the devices you allow without giving them access to other Sites.
If you're a school administrator, you could define a Site for an elementary school, middle school and high school and give each building technician full control over objects in his or her own building but not the others. Or by applying the correct settings in JSS Users & Groups, you could assign one person control over the elementary and middle schools but not the high school.
Or you could define each Site as "K-2", "3-5", "6-8" and "9-12" and assign technicians per grade band. Site doesn't have to reflect a physical location.
Unless you have a real need to delegate responsibilities in your JSS to specific people, avoid using Sites. They can be difficult to untangle and cause a lot of confusion.