Early today people launching some Mac App Store purchased apps where greeted with errors upon launching them.
This has been pretty widely reported, & after reading a few other articles I started to panic. After which I wanted to try see how this would affect us Mac admins & if I could help detect affected apps.
When trying to bring 10.11 support to AutoCasperNBI & AutoImagrNBI I stumbled across an odd issue.
On the flight to JNUC2015 I loaded up my 10.11 GM VM & figured it out.
Incredulous, I double checked this with James Ridsdale, Darren Wallace & David Acland. All of whom were located near me on the flight & all had their various MacBooks out running Keynote, Terminal &/or were running VM’s (spot the IT Crowd).
Below is what I found, steps to reproduce & a link to the bug on Open Radar.
Recently we found that the JSS was setting our clients Software Update Catalog URL to http://:/index.sucatalog.
Well, as detailed previously, we moved from using Software Update servers to Caching.
The move to caching servers actually meant I shot myself in the foot some & caused my own issue. JAMF Support got me things sorted & below is how & my guess work as to what was happening.
We recently replaced a the certificate on one of out Citrix Access Gateways, everything went well connecting to the CAG via a PC worked fine, but from a Mac we got the below error message.
Luckily for us, Citrix not only have a solution posted on this issue but also give detail as to why it can occur. The solution can be found here.
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.
Earlier today we started to tighten up one of our wireless networks, moving from PEAP to EAP-TLS authentication. In testing on 10.9.x & win7 clients, all worked well. But when deploying the same config profile that connected the 10.9.x clients to a 10.8.x Mac, the device failed to authenticate.
The 10.8.x clients console log didn’t show much information, so I took a look on the NPS servers logs (which are not a pretty sight) & after a time we came to a solution.
We updated our JSS from 8.73 – 9.22 back in January, we thought all was well until we needed to deploy some large packages.
This lead to our network guys not being to happy as Mac clients were downloading a 200MB installer across our MPLS irregardless of the distribution points assigned in our network segments.
After a few calls with JAMF support we discovered that the issue was due to the v8-v9 upgrade not updating a MySQL table, below is the how to check if your affected & what to do to fix.
UPDATE: My fork of ADPassMon has now been merged with main & many changes have been made, for more information follow this link.
Over the past few Mac OS revisions, you’ve been able to alert users to impending password expiry. Shown below is this on 10.8:
We’ve been supporting iDevice clients for a few years now, but recently ran into an issue that even a Cisco TAC call & the ever helpful resources of JAMFNation & MacEnterprise we not able to resolve.
Our users authenticate to the wireless using their AD credentials, after a password change they should be prompted to enter their new password. Once done they should reconnect to the wireless.
Oddly, after a password change the iDevices started to be offered a blank cert such as that below:
Several months after going launching our BYOD scheme, we started getting reports from people that their iOS devices would fail to connect to our Exchange servers for company email.
They would fail with an error like that shown below;