Targeting groups: excluded SmartGroups are not being excluded from policies being deployed

ryan_s
New Contributor II

Quick backstory: we're making a new policy in our organization that says all corporate-owned devices need to be enrolled with the appropriate agent-software - for the case of this discussion we are enrolling approximately 300-400 additional Macbooks, user-initiated via Safari.

We already have over 300 machines enrolled and have been pushing out various policies to these machines without any real issue. As soon as a machine is enrolled, our JSS pushes a handful of policies to the machine, which is expected behavior since previously the only individuals enrolling a machine was done by our Help Desk who is also imaging the new machine.

So now, our organization is prepping sending communication around the new policy which will have a lot of extra Mac-based end-users (300+) enrolling themselves in Casper via Safari and agent download. Because it is a fair handful of people, and not necessarily "IT minded", we're wanting to roll everything out in phases. Phase 1 (which is what we are talking about for this discussion) is simply getting the agent on the users' machine, updating JSS inventory, and enabling an admin account as a backup administration account on the machine (in the event a user leaves the machine with Help Desk, we do not need the end-user to provide us their password).

So what we have done is this:

  • Created Smart Computer Group name "user-initiated enrollment"
  • Added criteria of "Packages installed by Installer.app/SWU" has com.jamfsoftware.osxenrollment
  • Added criteria of "Last Enrollment" is after 01-01-2015

We currently have 74 policies in our organization that are being pushed based on Smart Computer Group membership as well as 2 static computer groups (our 2 test groups). What we did was applied the above SmartGroup as an exclusion in the scope of the policies we do not want pushed. However, what we are seeing now is that even though the members of "user-initiated enrollement" SmartGroup are excluded from the policies, they are still being pushed to these machines.

As an example here is how we have Adobe Reader set:

  • Options: 1 package (reader.dmg), update inventory
  • Scope: Targets="Systems w/out Adobe Reader" group, Limitations=none, Exclusions="User-initiated enrollment" group
  • Self-Service: Available

It seems like the exclusions group doesn't seem to be excluded. Adobe Reader is pushed, after manual-enrollment from web (client-side) and a restart, even though it shouldn't be (this and other policies as well)... Any ideas?

7 REPLIES 7

Kaltsas
Contributor III

While at a glance I would expect that should work, I usually just do some fancy bracketing and and/or statements in the smart group. I've used the limitations function in policy scope before and while I don't doubt it was some logic error on my part it seemed spotty.

You've got your Systems w/out Adobe Reader Group and your User-initiated enrollment group. I would make a third group (Auto Install Adobe Reader or something) that calculates as member of Systems w/out Adobe Reader and not member of User-initiated enrollment. This should target all the required systems.

ryan_s
New Contributor II

Thanks for the idea Kaltsas. We currently have 61 smart groups, so there would be some work to be done there. Our end goal is to have the "self-enrolled" users stay static for a little while, and then we'd remove the exclusions from the policies we want to push; meaning, this smart group is more of a temporary solution for now.

Is there maybe an alternate way we can filter policy vs exclusions perhaps?

ryan_s
New Contributor II

Any ideas as to why an exclusion group is still receiving policies from our JSS? Thoughts are welcomed...

davidacland
Honored Contributor II
Honored Contributor II

It could be a bug if the devices are all in the right groups. I've had issues in the past where I forgot to run an inventory update at the right time so Casper "thought" a particular Mac didn't have something installed.

As a possible workaround, assuming software like Adobe is deployed to all the Macs that currently need it, could you disable the policy? Then switch it back on when you are ready?

davidacland
Honored Contributor II
Honored Contributor II

One more thing...

The Management tab of the inventory record shows the policies that the Mac is in scope for, and the groups it is a member of. Could be worth checking, even if it is more info for JAMF support.

ryan_s
New Contributor II

So I think I may have made some progress -- if I enroll the machine manually, policies I don't want are get pushed to my test machine (most of them after initial reboot). However, if I do a manual "recon" of the machine immediately after enrolling it, the policies are NOT pushed. The ones that auto-install on enrollment (joining an SSID for instance) are reverted backward.

@davidacland][/url: I see in the JSS that the applied policies goes from 37 to 8 after on my test machine.

Now I need to figure out if there is a way we could push a manual recon as the last step of enrolling... or perform something along those lines so we can minimize user interactiion.

ryan_s
New Contributor II

Does anyone have other ideas here? I am very confused since enrollment of a machine includes Recon...so why is it that a second Recon after enrollment seems to 'fix' the exclusion group?