Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

A couple of years back, I wrote a script to assist with migrating AD mobile users to local users. In my testing in 2016, everything seemed to work right and I didn’t see any problems with it on OS X El Capitan.

Fast forward a couple of years and a colleague of mine, Per Oloffson, began running into a weird problem with upgrading Macs from Sierra to High Sierra. When he upgraded Macs from macOS Sierra to macOS High Sierra, he was finding that Macs that had been migrated from AD mobile accounts to local accounts were having those same accounts break.

We had users who couldn't log back in after upgrading to High Sierra, as it turns out due to superfluous quoting in the AD unbinding script.

— Per Olofsson (@MagerValp) June 15, 2018

After a considerable amount of troubleshooting, he was able to narrow it down to the macOS High Sierra installer changing the password hash on those accounts. But why was it changing them?

The kicker was that they could log back in after unbinding to AD back in February. It was a ticking time bomb though, which blew up after the High Sierra upgrade.

— Per Olofsson (@MagerValp) June 15, 2018

In short, it was changing them because of a bug in my original MigrateADMobileAccounttoLocalAccount.command interactive migration script. Sorry, Per. For more details, please see below the jump.

Sending Jamf Pro notifications to Slack

One of the features offered by Jamf Pro is the ability to send notifications of various events to specified email addresses. Any Jamf Pro user account can be set up to receive these emails, so they’re a convenient way to be notified about events affecting your Jamf Pro service.

These notifications include the following:

• An instance of the Jamf Pro web application in a clustered environment fails
• An updated patch reporting software title is available
• Computer is enrolled using PreStage
• Database backup fails
• Database backup succeeds
• Error occurs during imaging
• Error occurs when policy runs
• Jamf Pro account is locked out because of excessive failed log in attempts
• Jamf Pro fails to add file to JDS instance or cloud distribution point
• License limit is exceeded
• One or more Memcached Endpoint(s) are not reachable
• Restricted software violation occurs
• Smart computer group membership changes
• Smart mobile device group membership changes
• Smart user group membership changes
• SSL certificate verification is disabled
• Tomcat is started or stopped
• VPP token is approaching expiration date

That said, I get enough emails on a daily basis that I’d prefer to have these notifications go to a channel in Slack. That way, my whole team can be notified about issues and there’s a searchable log of when events occurred.

There are solutions for sending notifications directly to Slack, but I wanted to avoid using middleware in favor of using the built-in notifications in Jamf Pro. Fortunately, there’s a way to do that using tools available from Slack. For more details, see below the jump.

Updated Xcode command line tools installer script now available

A while back, I developed a script that will download and install the Xcode Command Line Tools on Macs running 10.7.x and higher.

Most of the time it works fine. However, starting with macOS Sierra and continuing on with macOS High Sierra, I occasionally ran into an odd problem. Apple would sometimes have both the latest available Xcode Command Line Tools installer and the just-previous version available on Apple’s Software Update feed.

The original script was written with the assumption that there would only be one qualifying Xcode Command Line Tools install option available at any one time. When more than one is available, the script isn’t able to correctly identify which Xcode Command Line Tools it should be installing. The result is that the script ends without installing anything.

Apple usually removes the previous version from the Software Update feed within a few days, which allows the script to work normally again. But when it happened this time, I decided to update the script to hopefully fix this issue once and for all. For more details, please see below the jump.

Disabling Jamf Pro LDAP wildcard searches to speed up user and group lookups

When setting up Jamf Pro, one of the options you have is to integrate it with your company, school or institution’s LDAP-based directory service. Connecting Jamf Pro to LDAP allows you to query your organization’s directory service for information and also allows the use of your existing user accounts and groups when requiring logins or scoping policies.

When setting up Jamf Pro to connect to a directory service, there’s a Use Wildcards When Searching setting with the following description:

Allow partial matches to be returned when searching the LDAP directory

What this setting does is that it allows Jamf Pro to use wildcards when making LDAP searches of your directory service. That allows Jamf Pro to return search results that may only partially match what you told it to search the directory service for.

For directory services with fewer than five thousand user accounts and/or groups, having this option enabled is usually fine. However, once the directory service is larger than that, disabling the Use Wildcards When Searching setting may dramatically speed up user and group lookups. For more details, please see below the jump.

Using the Jamf Pro API to mass-delete computers and mobile devices

Periodically, it may be necessary to delete a large number of computers or mobile devices from a Jamf Pro server. However, there is currently a problem in Jamf Pro 10 where trying to delete multiple devices can fail. Jamf is aware of the issue and has assigned it a product issue code (PI-004957), but it has not yet been resolved and remains a known issue as of Jamf Pro 10.4.1.

To work around this issue, you can delete computers and mobile devices one at a time. This does not trigger the performance issues seen with PI-004957, but this can get tedious if you have multiple devices to delete. To help with this, I’ve adapted an earlier script written by Randy Saeks to help automate the deletion process by using a list of Jamf IDs and the API to delete the relevant computers or mobile devices one by one. For more details, please see below the jump.

Upgrading from ESXi 6.5 to ESXi 6.7 via SSH and esxcli

Following VMware’s release of ESXi 6.7, I upgraded my ESXi 6.5 server to ESXi 6.7 using SSH and esxcli. For those interested, see below the jump for the details of the process I used.

Detecting if a logged-in user on a FileVault-encrypted Mac has a Secure Token associated with their account

A challenge many Mac admins have been dealing with is the introduction of the Secure Token attribute, which is now required to be added to a user account before that account can be enabled for FileVault on an encrypted Apple File System (APFS) volume.

In my own shop, we wanted to be able to identify if the primary user of a Mac had a Secure Token associated with their account. The reason we did this was:

1. We could alert the affected help desk staff.
2. We could work with our users to rebuild their Macs on an agreed-upon schedule where their data was preserved.
3. We could hopefully avoid working with our users on an emergency basis where their data could be lost.

To help with this, we developed a detection script. For more details, please see below the jump.