I’ve been testing out iBeacons to add new IT capability since JAMF Software added support in Casper 9.5. After a bumpy start, now we’re up to 9.7+ things are working well. This blog describes the setup I’m using and some of the functionality that is available.
Support for iBeacons was originally introduced in iOS 7, which has been around for a while now. Although the core technology is just low-energy Bluetooth, the potential applications are quite broad.
Initially, support for the technology was being written into mobile apps. Use cases included retail and events as a way to display content to users as they moved within range of a Beacon.
The interesting twist came when JAMF Software added support for iBeacons into the Casper Suite to deploy configuration profiles and trigger policies. This new functionality has opened up the technology to IT administrators, as we are able to trigger events based on devices entering or leaving iBeacon regions.
A bit of technical information about iBeacons
Just to start off with, I thought it would be worth summarising some of the key technologies I’ll be mentioning in this article. If you are already familiar with iBeacons, BLE, UUIDs, Majors, Minors and ranges, then you can jump straight to the next section.
iBeacon – This is a technology produced by Apple that enables iPhones & Macs (and Android) to perform actions when in close proximity to an iBeacon. They are essentially a “trigger” that tells the device to “do something”, consisting of the user device (Mac or iOS) and a small Bluetooth transmitter. Moving within range of the Bluetooth beacon triggers the event. What that event is depends on what the app developer has programmed into the code.
Bluetooth Low Energy – Bluetooth Low Energy or BLE is, as you may have guessed, a form of Bluetooth that has greatly reduced power consumption compared to traditional bluetooth devices. BLE devices are much cheaper to produce, making technologies like iBeacons possible.
UUIDs, Majors & Minors
Although easily mixed up with other technologies, in this case these are iBeacon specific terms:
- UUID – This is a 128-bit value that is used as an identifier for all of your beacons
- Major – This is a random number that is used to group your beacons together
- Minor – This is a unique number, used to identify a specific beacon
So as the administrator you set these yourself, just make sure you understand the difference between UUIDs, Majors and Minors to avoid issues further down the line.
Regions & Ranging – iBeacons have quite accurate measurement capabilities with regards to how far away a device is. This is determined by the signal strength so as you can imagine, can be skewed by objects in the way, such as walls or other people.
Beacon regions have three options:
- Immediate (within 5-6 inches)
- Near (within 2-3 meters)
- Far (within 10 or so meters)
What can you do with iBeacons and Casper?
So now we’ve got all of that stuff out of the way, let’s get into working with an iBeacon and Casper. We’re going to look at two features, specifically triggering policies and deploying configuration profiles. You might think “is that all I can do?” but you need to keep in mind that with these two options you can do almost anything you like.
Getting your JSS setup with a Beacon
Add your iBeacons to the JSS – There are two key things you need to do to get going. The first is to add your iBeacon to Settings > Network Organisation > iBeacons. There is a decent guide from Two Canoes here as more of a step by step.
Configure the JSS to monitor iBeacon Regions – In the case of Mac OS X management, the second step is to enable iBeacon region monitoring in Settings > Computer Management > Computer Inventory Collection > Monitor iBeacon Regions:
Triggering a Casper policy with an iBeacon
So now that’s set up, let’s get a policy created that can be triggered by an iBeacon.
First off, go to policies and create a new policy. The policy can do anything you like, although for the sake of demonstration, I would suggest something simple and visible, like adding an icon to the Dock.
For the trigger, select “Custom” and enter “beaconStateChange” as the value. Using this value will cause this policy to be run whenever a Mac moves within an iBeacon.
Lastly, we need to ensure the policy only runs when the Mac is in range of the iBeacons you have chosen. In the policy options, click on Scope > Limitations, click “Add” and select your new iBeacon. Make sure that you have also included your test Macs into the scope, otherwise the policy won’t run!
Now you just need to save the policy settings and test. Move a Mac (that is in scope) within range of the iBeacon and watch the magic. When I have tested this there is a short delay (around 20-30 seconds) so be patient. If you are not sure if anything is happening, open up the /var/log/jamf.log file to see what is going on.
Here’s a snippet from my jamf.log that shows when my Mac entered my Beacon region and triggered a policy:
Fri Apr 24 16:28:18 Daves-Mac jamf: Entered iBeacon Region 1
Fri Apr 24 16:28:19 Daves-Mac jamf: Checking for policies triggered by "beaconStateChange"...
Fri Apr 24 16:28:22 Daves-Mac jamf: Executing Policy iBeacon Mac Test...
(In case you wondered, my test policy in the above example is called “iBeacon Mac Test”).
Running a policy if a device leaves an iBeacon region
There might be some scenarios when you want to trigger a policy if a device leaves an iBeacon region. I’ve tested this a little by using exclusions instead of limitations. In theory it is possible, so a device is sitting in range of the beacon and the policy is being blocked. If the device is moved out of range of the beacon, a state change will be triggered and as the exclusion no longer applies, the policy will run.
I’ve tested this a few ways. Firstly by simply moving out of range of a beacon. Sure enough, beaconStateChange kicked in, saw I was no longer being excluded by the particular beacon and the policy ran. Although this worked fine, I couldn’t imagine all users keeping their laptops open as they move away from the beacon so I also tested it by closing the lid to put my MacBook to sleep, moving away from the beacon and waking it up again. The beaconStateChange kicked in again and all worked as it should.
This could prove useful if you have a set of devices that should always be in a particular location. If they are not in that location you could trigger policies or push config profiles to lock, track or disable the device.
These will work in in similar way to policies, although they are also available for iOS devices. All you need to do is create a configuration profile, scope it to the target devices (Mac and/or iOS) and add the relevant iBeacon limitation.
In Casper 9.5, lots of people tested web clips first to see what the behaviour was like. This uncovered a bug that was specific to iBeacons and deploying web clips as part of a configuration profile. I have since tested this in v9.7 and it worked fine on my iOS device (running 8.3 (12F70) in case you wondered).
So hopefully this has given you a bit of an idea for what you can do with iBeacons and Casper. As this is a new piece of technology, I’ve had lots of thoughts pop into my head on how to make use of it.
The possibilities are endless here, but I will point out (probably stating the obvious) that you need to use some caution. Don’t start off deploying the Adobe Creative Suite as your first test. Remember that we’re dealing with Bluetooth, which has been known to have its moments of instability over the years, and bear in mind that what might work in a controlled test with a couple of devices, might fall apart when you’re dealing with a full classroom of student devices or a packed meeting room.
From my perspective, I would consider using iBeacon triggers for the following policies:
- Deploying very small apps – I’m talking under 50MB at this stage, but there could be some cases where you want to deploy a small app or plugin if a device goes into a specific room.
- Dock icons – Always useful and in my testing, using the standard Casper Dock icon options I could add items nice and easily.
- Printers – This is a more obvious one, as they are so often based on geographical location, but you can of course deploy printers based on a device entering an iBeacon region
- Running scripts or commands – As with the other examples, triggering scripts will have its uses
These are a bit more limited compared to policies, but have the benefit of including iOS devices. Some of the options I like the look of are:
- iOS Webclips – Nice and easy to deploy with no user interaction.
- Airplay password – If you had a password protected Apple TV, you could punch a config profile that includes the code to devices that have entered the iBeacon region. This would help reduce the risk that someone connects to the wrong one if you have a few of them
- Restrictions – Possibly for an “exam mode” setup, a set of restrictions could be applied while devices are in range of the specified iBeacon
- Single App Mode – Following the “exam mode” theme of restrictions, you could lock iOS devices into a specific app if they enter a particular iBeacon region
- WiFi – If you have different WiFi networks or SSIDs, you could have the necessary config profile deploy at a building entrance. I could see this being useful for international offices to reduce the use of data roaming.
Interested in learning more about iBeacons and how you can implement this technology within your IT network? Call Amsys today on 0208 660 9999 or email firstname.lastname@example.org.