During JNUC2023, not only was I invited to speak on a panel but I also delivered a talk, titled: Extracting data from Jamf Pro: Hints, Tips and Tricks.
See below for a link to the video, the GitHub repo with all of the links as well as PDF of the slides, and lastly a link to the JNUC2023 playlist.
Continue reading
When looking into the issue in my last post, I found I could no longer access Airwatch’s online API documentation.
Heading to Ask Airwatch & looking for the API documentation revealed why.
With the 8.3 release, Airwatch have started a process of refactoring & remotion of the Uniform Resource Identifier (read: URI) used for API calls.
See below for more information on these changes.
As mentioned before we have some scripts that access Airwatch’s REST API.
Sadly a recent update to our SaaS instance to 8.3.1.0 lead to our scripts failing.
Below is a little post with the resolution.
As mentioned before, when using Box with ADFS for SSO there are more than a few limitations.
In an attempt to overcome them, I took on Box’s API. The first hurdle was trying to connect to it as Box uses OAuth2 which massively differs from other API authentication for other API’s I’ve access such as Airwatch.
However, I’ve a method & in I’ve detailed it below. This method is used throughout all my Box API scripts.
After being nerd sniped by @unknown_err in a channel on the MacAdmins.org Slack, I started writing some client side API scripts.
This lead to an issue with 10.8.x clients connecting to my JSS.
The below is why I saw these SSL errors & a two resolutions, one client side & another server side.
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.
Continue reading