A issue was opened recently for AutoCasperNBI, where 10.11.2 NBI’s generated for not accessible over ARD or VNC.
Some digging revealed this this only affected NBI’s with the “Reduce Image Size” option selected.
NBI’s for 10.7.x – 10.11.1 work fine over ARD or VNC with that option selected, so some investigation was needed. Below is the investigative work, but you can also skip straight to the resolution.
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.
However, we hit an issue where only a few devices were available within the “Self Service Portal”.
Below is what we found, and how we resolved this issue.
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.
See below for the gory details.
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.
Below are more details on the issue, and the 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 above is this on 10.8.
Below are details on how I set the above, and the issue with Mavericks
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 above
See below for more details