One of the things I want to be able to do in our new deployment is detect devices that are "out of spec" and make sure that the users find their way back to me for ... ah ... re-education.
Most "out of spec" things can be dealt with by the MDM server itself. If a device checks in with a missing configuration profile or a missing app, the server will automatically take care of that.
Sometimes, though, we want to check for other conditions and make sure that these situations don't go on for too long. To achieve this, I have designed a "lockout protocol" for our deployment.
The Configuration Profile
We have a configuration profile that can be applied to any supervised iPad that essentially “locks out” the user from doing any work. It’s really quite simple.
The first payload is a Restrictions payload which I use to only allow one app: The JAMF Self Service app.
The second payload is a Home Screen Layout payload. This puts the Self Service app into the Dock, so that people can find it easily.
That’s all it is but, because the devices are supervised and in DEP, there’s nothing the user can do to get out of this situation except to come and see me for help.
The Criteria for Lockout
To detect these anomalous conditions, I have a smart device group in our MDM that captures devices based on the following conditions:
- The device inventory is more than 10 days old (i.e. it’s not communicating with the server properly) OR
- The JSS “Jailbreak Detected” field is “yes” OR
- The “Location Services for Self Service” is “Not Enabled/Unknown”.
- The iOS version is less than the current release version of iOS.
Now, I normally give a grace period for iOS updates of about a week before I update the criteria for the smart group so it’s not too draconian.
I haven’t yet had a device where the inventory alone was stale. I suspect this condition is probably redundant given that, if the device can’t supply inventory, it’s unlikely to be able to receive the new profile either.
When a new iOS update comes out, the first thing I do is push a notification to Self Service. To be fair, about half the students respond to this in a timely manner.
After a few days, my new thing is to push a new wallpaper to the devices that puts the message right in the students’ faces.
After a few more days, if the devices still aren’t updated, I update the criteria for the lockout protocol and the shutter comes down until everything comes into line.
Even when locked out, the device will still be able to be updated as Settings is the one app that can’t be hidden.
Once the anomalous situation is resolved, the user will likely need to come and see me. Devices update their inventory typically once a day to the JSS, but an administrator can force an inventory update manually. That would cause the device data to be updated and the restrictions lifted.