AirWatch only keeps a record of the devices currently enrolled user, if the device is re-enrolled by/for someone else the details are overwritten.
Worse is that if your devices are not supervised, it’s trivial to unenroll a device. This then leaves a device record on AirWatch but with no user information.
To counter this, I’ve written the below API script that will add the enrolment users information to the devices notes. A new note is created with each scripts run, meaning that if a device is enrolled by another user, we’ll have a record & these notes are not deleted when a device is unenrolled.
This is detailed below.
We’ve started to look at enabling “Compliance Policies” within AirWatch.
However, these are scoped to “Assignment Groups” (was “Smart Groups”, another thing that seems to be mid-rename) & “Assignment Groups” do not have criteria for a devices “Enrolment Status”.
Below is an API script that I am using to automate device deletion if a device meets certain conditions & the method to the madness.
As mentioned in my previous post, I have been doing some work with AirWatch’s REST API & at the same time I have been learning Python.
This post is to show how you can access AirWatch’s REST API with Python to return devices information, as well as serve as a template for the scripts I use to access AirWatch’s REST API.
I’ve recently been doing some work with AirWatch’s REST API.
One call required me to pass the LocationGroupId for an Organization Group, this is not readily available & the below are some methods that can be used to get the LocationGroupId for an Organization Group.
I’ve blogged a few times about how to not only create, but also deploy & update “Safari Extensions”.
With the release of Safari 9 Apple have stopped all automated deployment methods, & I’m partly to blame.
This issue of “AD users losing Admin rights when off the Domain” is a wee head scratching moment that comes up from time to time.
Having recently updated the script I use workaround this issue, I decided it was time for a blog post.
The script, an explanation of the script & the issue itself are detailed below.
For a number of years, OS X VMWare Fusion VM’s either hosted locally or on ESXi have supported NetBoot. Rich Trouton has covered this before here & here.
(Incidentally whilst this post refers to VMWare OS X VM’s, you can also NetBoot Parallels OS X VM’s & Kyle Bareis has a post on NetBooting VM’s created with that here.)
On occasion, the odd question still pops up on how to do this. So I’m posting this in the hope of rebroadcasting the message for any that have missed it.
For a number of years now I have used the icons found within the CoreTypes.bundle for dialogs, scripts, slides & Self Service.
I thought it was common practice to use them, but after a few conversations at JNUC2015 it appears I was wrong.
So the below is a quick write up on them.
As blogged here, here & here I’ve had some fun deploying & creating Safari Extensions.
Recently I needed to update our deployed Extension Bar & like a daft person I didn’t follow Apple’s advised Extension update method..
However, past me was not that daft & had already discovered that all that is needed to “update” an existing Extension is to replace it. Which is pretty much what the below script does.
Many thanks to Peter Bukowinski & Erik Berglund for helping me with this in the #bash channel in the macadmins Slack.
See below for the script
Sophos’s Enterprise Anti-Virus 9.2.x has been blogged about a few times & in the Mac Admin space most prominently by Gilbert Palau & Rich Trouton, but here comes another tale & post on the same subject.
Our saga with Sophos Enterprise Anti-Virus 9.2.x started on Feb 27th, which incidentally was the day after they change their installed to an app bundle which Rich had blogged about & at the time Sophos did not have any deployment articles on.
So what did they change & why the pitchforks & stink eye from the Mac Admin community?