JAMF Site split into 2 additional new sites

[tcandela]

I have an existing site (call it site1) and created 2 new sites ( site2 & site3). I don't want to create duplicate policies, smart groups, etc...  for site2 & site3 since all 3 sites will basically use all the same.  Is this possible?

Basically macs from Site1 will be moved/assigned to Site2 and Site3

Example:

Site1 currently has Self Service policy1. Can I use that same policy1 in site2 & site3 without having to create the same policy for both new sites?

Site1 currently has Smart Group 'has zoom version 17'  Can I use that same smart group in site2 & site3 without having to create the same smart group for both new sites?

[mm2270]

Hey @tcandela , unfortunately no, if a Smart Group was created for a specific Site, it can only be used for that Site and not others. It will only capture machines that are part of that Site and not any others.

The only solution I know of for what you're looking to do, is to create a Smart Group as a global admin (Jamf account that can see all computers and all sites) and not assign the group to any Site. That group can then be used as scope for any machines in any Site, assuming the policy / patch policy is also created in a global manner. I have a number of Smart Groups like this, primarily used for patching since, though we have multiple Sites, we tend to patch all devices across the org at the same time.

Now, if you have 3 Sites and wanted a Smart Group to only capture Macs in 2 of those 3 Sites, the only way I know of to achieve that is to use some other criteria to help tease out the specific machines. For example, if each site uses a unique naming convention for the Computer Names, something that is partially the same across all devices in that Site, then you could use the Computer Name criteria and a regex pattern to grab just those devices. The regex can potentially capture whichever ones you want, and exclude others, if it's done right.

It would be nice if accounts in Jamf Pro could be Site admins for multiple sites, not just a single one. Then, potentially that account could create groups, policies and other objects in Jamf that could apply to those multiple Sites. But it doesn't work that way.

Anyway, hope the above helps.

[tcandela]

@mm2270  there are so many things JAMF can do to improve the product starting with the limitations I'm running into here. 

I'm site administrator for all 3 and it would be great like you said to have multiple sites to a single admin. Looks like you have to be a global admin for this, then you have access to ALL sites!!

[jamf-42]

its a workaround.. but you can create a policy in each site that writes out a value 'site name one' 'site name two' and that will only run on that site. You can capture that value via an EA and then use that value in a smart group as global admin to scope to 'sites' ... if thats what your after? 

[jamf-42]

EDIT.. another would be to use Configuration Profile variables .. this includes: 

$SITENAME	Site Name
$SITEID	Site ID

very old link https://docs.jamf.com/9.97/casper-suite/administrator-guide/macOS_Configuration_Profiles.html

[dennisnardi]

If you are trying to separate machine visibility and IT admin amongst internal teams, separate sites, like what you did will work. 

If you are trying to create inherit scoping separation (ie. scope to everything in Site 1 & Site 2 but not Site 3), I'd recommend using some kind of extension attribute, and create groups based on that. There are a variety of strategies around this, both automated or manual. You could also potentially use the department field. 

If you do need separate sites, like others mentioned, the best thing to do is to create policies and groups at an admin (None or Full Jamf) level. This level of policy/group can see and interact with every device in Jamf. If you have a distributed IT setup, like many in higher ed, this is fairly common (this is what I do in my environment). The admin/full Jamf/none site has all required policies for all my distributed IT groups, along with policy triggers that distributed IT/site admins can call for their own policies, without having to fully recreate policies. 

If you go the separate site routes, it will require more logic to generally put into place to handle accommodations and exclusions. A strategy I employ is allowing site admins to create or modify a smart group, and then I nest that smart group in my admin/full Jamf/none site smart group for items. That way distributed IT, who are only site admins, can control membership and thus can control either inclusion or exclusion from certain policies.