iBeacon Policy Executes Only When Entering Range

[majedian21]

Running Casper Suite 9.62

I am experimenting with using iBeacon to promote a user in the iBeacon range to an admin and then demote the user when they are out of range. The documentation I'm using can be found here.

I see in the jamf.log that when the device has entered the iBeacon region, the policy executes.

jamf[13806]: Entered iBeacon Region 1
jamf[18281]: Checking for policies triggered by "beaconStateChange"...
jamf[18281]: Executing Policy Adjust Admin Rights...

However, when the user exits the region, the event triggers, but the policy does not execute.

jamf[13806]: Exited iBeacon Region 1
jamf[19034]: Checking for policies triggered by "beaconStateChange"...

I don't see a place in the JSS to specify to only run on entry/exit/both. Is that a configurable option? If not, why does it only run when entering an iBeacon region?

Ideally, I would love to run promoteAdminUser.sh when entering. Then run demoteAdminUser.sh when exiting. However, if that's not an option, I'll just have to run one script with enough logic to do the proper promotion/demotion.

Secondly, what is the maximum amount of time a client device could be expected to report to the JSS that it has entered or exited a region? I'm seeing up to 1-2 minute delays before the computer reports to the JSS that it has either entered or exited a region. Why is the delay even there?

[majedian21]

Bump. Anyone using iBeacons like this?

[Chris_Hafner]

Not yet. However, I'll be watching this post for just such info. There are some great uses out there but I'm still unconvinced in the general reliability of the iBeacon state change. Rather, the tim differential you're speaking of. Right now, we've got great policies in place and our users know how to use Self-Service so I don't gnat to lull them into relying on iBeacons until I can see rock solid performance... and get some more time to play with them. Regardless, it ought to provide some truly unique abilities once all fleshed out.

[BrysonTyrrell]

I'm just starting to mess around with iBeacon based policies as well.

What is the scope of your exit policy? For the one that triggers upon entering the iBeacon region I imagine it looks something like this:

• Assigned to: All Computers, Limited to: iBeacon Region 'X'

Your exit policy's scope should be the inverse of that. Something along the lines of:

• Assigned to: All Computers, Exclude: iBeacon Region 'X'

If the scopes are the same (the first example) then the exiting policy will never trigger because your computer is out of scope by not being in the region anymore.

[majedian21]

@brysontyrrell thanks for the suggestion - it got me thinking in a different way than I originally was. However, with your proposed exit policy, I am thinking that ANY device outside a particular iBeacon reporting a 'beaconStateChange' would fall within that exclusion scope. When I begin adding more iBeacons around our organization for different purposes, devices exiting those iBeacon regions will also (inadvertently) execute this iBeacon's exit policy.

Am I missing an element of your exit policy that would restrict the policy execution to only devices exiting that particular iBeacon's region?

[BrysonTyrrell]

@majedian21 That was just an example. You would need to evaluate the scopes for your policies to prevent just that sort of behavior.

[Matthew_Ramsay]

@majedian21 A bit of a necropost here, but did you ever find a solution for your initial question?