See below on how to block this upgrade with Jamf Pro.
With Jamf Pro 10.6.0, Jamf changed the default storage engine from MyISAM to InnoDB.
Jamf also released a tool to convert the tables with the release of 10.7.0.
However, as the Jamf supplied tools are not available currently available as a standalone download for those of us that do manual installations & as we host our datajar.mobi instances on Kubernetes… we went the manual route.
Below is how we performed these conversions.
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.
Well when Portfolio is struggling to catalog files, it can generate massive amounts of temp files & folders, which if not maintained can fill the Portfolio hosts hard drive.
Not a great situation, so I’ve written the below to help automate the maintenance.
As mentioned in my previous post, we’re currently cataloging around 40TB of data in Portfolio.
However, again as per the previous post, we’ve found some files to be troublesome causing issues cataloging. Once Portfolio attempts to catalog these files, the processes used can hang & get stuck on those files.
Portfolio then spawns more & more processes for the next files it finds until the box running Portfolio eventually runs out of resources.
To maintain the hosts uptime, we’re using the below script to restart the services daily.
As mentioned before, we use Portfolio to archive old projects.
However since moving to Portfolio v1.x (from v11), we’ve had numerous issues. The main one has been getting the 40TB of data we host re-cataloged into Portfolio.
I’ve recently deep dived into Portfolio, & found some files that cause issues & these can be found via the logs. Parsing them allows me to “fix” the troublesome files or delete any corrupt ones.
Below is the how I’m parsing the logs.
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.