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 22.214.171.124 lead to our scripts failing.
Below is a little post with the resolution.
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.
On January 29th, Microsoft released Outlook for iOS and Android.
This release has caused somewhat of a stir due to some reported security issues with the app which existed before it’s rebranding from “Accompli”
I’ll be honest, I found a number of the posts on this app to be somewhat alarmist, but a post with the somewhat alarmist title: Warning – Microsofts Outlook app for iOS breaks your company security raised a point that caused me some concern.
This point was: “Shared Exchange ActiveSync ID and device type”
This post will explain why the concern, my findings & how to block “Outlook for iOS and Android” via Exchanges Allow/Block/Quarantine List.
We use AirWatch as our Mobile Device Management platform, & recently we launched the “Self Service Portal” to our user base.
This also coincided with restructuring our AirWatch SaaS instance, after which we noticed that devices could only be seen that we enrolled into the new organisation group. But we only had 20 devices in this new structure, with 500 enrolled on the old. So those that were on the old structure would see the below when logging into the “Self Service Portal.”
After a couple of weeks of troubleshooting, which verified that we had all setup correctly, AirWatch support pointed us to a simple solution.