Starting with Jamf Pro 10.3, user-initiated computer enrollment now has two modes:

• macOS High Sierra: Uses an MDM profile to enroll the Mac, with the Jamf Pro agent being installed once MDM enrollment is complete.
• macOS Sierra and earlier: Uses a QuickAdd installer package to enroll the Mac, with MDM enrollment and installation of the Jamf Pro agent being handled by the QuickAdd package.

However, it is still possible to get a QuickAdd installer package to enroll a Mac running macOS High Sierra. For more details, please see below the jump.

In order to obtain a QuickAdd package from user-initiated enrollment from a Mac running macOS High Sierra, you will need to enroll using the address shown below:

https://server.name.here:8443/enroll/?type=QuickAdd

Note: The Q and the A in QuickAdd are case-sensitive and must be capitalized.

To enroll with a Jamf Pro using a QuickAdd package on macOS High Sierra, please use the procedure shown below:

1. Go to https://server.name.here:8443/enroll/?type=QuickAdd
2. Enter your username and password, then click the Login button.

3. Click the Enroll button.

4. When prompted to download and install the package, click the Download button.

5. Verify that the QuickAdd downloads.

6. Run the QuickAdd installer.

Note: Enrolling with a Jamf Pro server using a QuickAdd package does not enable user-approved MDM. If this is necessary in your environment, I recommend using the MDM profile method to enroll the Mac in question.

Starting with Mac OS X 10.7.2, Apple set the iCloud sign-in to pop up on the first login.

In OS X 10.10, Apple added a Diagnostics & Usage window that pops up at first login after the iCloud sign-in.

In macOS 10.12, Apple added another pop-up window for Siri.

In macOS 10.13.4, Apple has added a Data & Privacy pop-up window for their data privacy information.

To stop the Data & Privacy pop-up window from appearing for your home folder, run the command shown below:

defaults write com.apple.SetupAssistant DidSeePrivacy -bool TRUE

Since you normally will be able to run this command only after you’ve seen the Data & Privacy pop-up window, I’ve updated my script for suppressing the various pop-up windows to now also suppress the Data & Privacy pop-up window. For more details, see below the jump.

The script is below and is also available on my GitHub repo.

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/disable_apple_icloud_data_privacy_diagnostic_and_siri_pop_ups

This script is also available as a payload-free package on my GitHub repo, available for download from the payload_free_package directory available from the link above.

For those who prefer to suppress the Data & Privacy pop-up window using a profile, a .mobileconfig file is available via the link below:

https://github.com/rtrouton/profiles/tree/master/SkipDataAndPrivacy

As part of a recent clean-up of my Apple File System-formatted (APFS) boot drive, I deleted a number of files. However, I noticed that deleting files did not free up nearly as much space as I thought it should. When I investigated, I noticed that my boot drive had a number of Time Machine snapshots stored on it.

A quick way to reclaim space from a particular snapshot immediately would be to delete the snapshot using the tmutil command line tool, using the command shown below:

tmutil deletelocalsnapshots snapshot-name-here

However, I didn’t want to delete backups if I could avoid it since I might need something stored in one of them. After some research, I was able to find a tmutil command that did what I needed. For more details, please see below the jump:

The tmutil command line tool on macOS High Sierra includes a thinlocalsnapshots function, which has the options shown below:

tmutil thinlocalsnapshots mount_point [purge_amount] [urgency]

Purge amounts are represented as bytes, so specifying 20 gigabytes of space would be represented by the number below:

21474836480

Urgency levels are 1 through 4, with the default urgency setting being 1.

Urgency level 4

Most urgent: Any current backup processes are stopped and thinning is performed immediately. The largest available backup will be the first thinned, with thinning proceeding through the next largest backups.

Urgency level 1

Least urgent: Current backup processes will be completed before the thinning process begins. The oldest available backup will be thinned first, with thinning proceeding through the next oldest backups.

To free up 20 gigabytes of space from the snapshots stored on the boot drive at maximum urgency, you would use the command shown below:

tmutil thinlocalsnapshots / 21474836480 4

The command may take a while to run, depending on what would need to be done to free up the requested space.

Note: The thinning process may actually free up more than the requested space, but it should free up the requested space as a minimum if the stored snapshots are taking up at least that amount of drive space.

Before snapshot thinning

Snapshot thinning

After snapshot thinning

As part of macOS 10.13.2, Apple introduced the concept of User Approved MDM Enrollment (UAMDM). UAMDM grants mobile device management (MDM) additional management privileges, beyond what is allowed for macOS MDM enrollments which have not been “user approved”.

As of macOS 10.13.4, the only additional management privilege associated with UAMDM is that it allows you to deploy a profile which provides a whitelist for third-party kernel extensions. This profile allows a company, school or institution to avoid the need to have individual users approve the running of approved software.

Without the profile, third-party kernel extensions will need to be approved through the User-Approved Kernel Extension Loading (UAKEL) process. Here’s how that process looks:

1. When a request is made to the OS to load a third-party kernel extension which the user has not yet approved, the load request is denied and macOS presents an alert to the user.

2. The alert tells the user how to approve the loading of the kernel extension signed by a particular developer or vendor, by following this procedure:

A. Open System Preferences
B. Go to the Security & Privacy preference pane

C. Click the Allow button.

Note: This approval is only available for 30 minutes. After that, it disappears until the following happens:

i. The Mac restarts
ii. Another attempt is made to load the kernel extension.

While waiting for the kernel extension to be approved, a copy of the kernel extension is made by the operating system and stored in the following location:

/Library/StagedExtensions

Once approved, another copy of the kernel extension is made and allowed to load.

This process is relatively easy for an individual to manage on their own computer, but it would be very difficult to manage when dealing with more than a handful of Macs. To help companies, schools and institutions, Apple has made a management profile option available to centrally approve third-party kernel extensions. For more details, please see below the jump.

To help whitelist all kernel extensions from a particular vendor or whitelist only specific ones, Apple has made two sets of identifying criteria available:

• Team Identifier
• Bundle Identifier

Team Identifier

A team identifier is a alphanumeric string which appears similar to the one shown below:

7AGZNQ2S2T

It appears to use a developer or vendor’s Developer ID for Signing Kexts certificate identifier. This certificate would be used by a developer or vendor to sign all or most of their kernel extensions.

Whitelisting using the Team Identifier has the advantage of being able to whitelist multiple third party kernel extensions from a specific developer or vendor. This capability allows Mac admins to identify a particular developer or vendor as being trusted in their environment and have all of the relevant kernel extensions be allowed to load by the whitelist.

Note: The UAKEL process appears to use team identity when approving kernel extensions, which potentially allows multiple kernel extensions to be approved at once.

Bundle Identifier

The Bundle Identifier is specific to a particular kernel extension. It is contained in the Info.plist file stored inside each kernel extension.

Whitelisting using the bundle identifier allows the Mac admin to get very granular about which kernel extensions from a specific developer or vendor are approved and which are not. If using the bundle identifier as part of the whitelist, both the Team Identifier and the Bundle Identifier need to be specified in the profile.

To help Mac admins, a community-written Google Doc spreadsheet is available here which lists various team identities and their associated bundle identifiers:

https://docs.google.com/spreadsheets/d/1IWrbE8xiau4rU2mtXYji9vSPWDqb56luh0OhD5XS0AM/edit?usp=sharing

(Hat tip to Contains_ENG for creating the document and developing a script to detect the relevant kernel extension info.)

Using Team Identifier by itself in a third-party kernel extension whitelist profile

If you want to use only the Team Identifier when whitelisting kernel extensions, the profile should be written as shown below:

On the individual Macs which receive the profile, it should show up looking similar to this:

Using Team Identifier and Bundle Identifier in a third-party kernel extension whitelist profile

If you want to use both Team Identifier and Bundle Identifier when whitelisting specific kernel extensions, the profile should be written as shown below:

On the individual Macs which receive the profile, it should show up looking similar to this:

If you’re using Jamf Pro to deploy a third-party kernel extension whitelist profile profile, it should appear as a built-in profile option. Here’s how it should appear if using only team identifiers:

If using both team identities and bundle identifiers:

Starting on April 12, 2018, Macs running macOS 10.13.4 will display a one-time alert when 32-bit applications are opened. This alert will appear once per user account on the Mac, when a relevant 32-bit application is opened.

When the Learn More… button in the alert window is clicked, the following Apple KBase article opens in your default web browser:

32-bit app compatibility with macOS High Sierra 10.13.4
https://support.apple.com/HT208436

For those who need to stop this alert from being displayed in their environments, I’ve built a management profile to suppress the warning. It is available on GitHub via the link below:

https://github.com/rtrouton/profiles/tree/master/Disable32BitApplicationWarning

Oracle has started to release Java 10 for macOS, so I’m posting a couple of scripts to download and install the following:

• Oracle Java 10 JDK
• Oracle Java 10 JRE

Oracle has been releasing two separate versions of Java 8 simultaneously and may do the same for Java 10, so these Java 10-focused scripts are designed to allow the user to set which version they want to install: the CPU release or the PSU release.

The difference between CPU and PSU releases is as follows:

• Critical Patch Update (CPU): contains both fixes to security vulnerabilities and critical bug fixes.
• Patch Set Update (PSU): contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems.

For more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

For more information, please see below the jump.

The scripts are available on GitHub via the links below:

Oracle Java 10 JDK: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_oracle_java_jdk_10
Oracle Java 10 JRE: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_oracle_java_jre_10

The scripts are also available as payload-free packages, compressed and stored as .zip files in the payload_free_package directory available via the links above.

Oracle Java 10 JDK script:

The script below will download a disk image containing the latest version of the Java 10 JDK from Oracle and install the JDK using the installer package stored inside the downloaded disk image.

How the script works:

1. Verifies that the Mac is running a Java 10-compatible operating system
2. Uses curl to download a disk image containing the latest Java 10 JDK installer from Oracle’s web site
3. Renames the downloaded disk image to java_ten_jdk.dmg and stores it in /tmp.
4. Mounts the disk image silently in /tmp. The mounted disk image will not be visible to any logged-in user.
5. Installs the latest Java 10 JDK using the installer package stored inside the disk image.
6. After installation, unmounts the disk image and removes it from the Mac in question.

Oracle Java 10 JRE script:

The script below will download a disk image containing the latest version of the Java 10 JRE from Oracle and install the JRE using the installer package stored inside the downloaded disk image.

How the script works:

1. Verifies that the Mac is running a Java 10-compatible operating system
2. Uses curl to download a disk image containing the latest Java 10 JRE installer from Oracle’s web site
3. Renames the downloaded disk image to java_ten_jre.dmg and stores it in /tmp.
4. Mounts the disk image silently in /tmp. The mounted disk image will not be visible to any logged-in user.
5. Installs the latest Java 10 JRE using the installer package stored inside the disk image.
6. After installation, unmounts the disk image and removes it from the Mac in question.

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.

This script checks for the following:

1. If the Mac is running 10.13.x or later.
2. If the boot drive is using Apple File System (APFS) for its filesystem.
3. If FileVault is enabled or not.

If the Mac passes the following checks:

• Running 10.13.0 or later
• The boot drive is using APFS
• FileVault is enabled

Then the following action takes place:

1. The logged-in user is checked to see if it can be determined.
2. If it can be determined and it is not the root user, the sysadminctl tool is used to check to see if the account has the Secure Token attribute associated with it.

If the logged-in user account should have a Secure Token attribute associated with it and does not, the script will report the following:

1

Any other outcome, the script will report the following:

0

The script is available below, and at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/detect_missing_secure_token

A complementary Jamf Pro Extension Attribute is available at the following address on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/detect_missing_secure_token

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.

To upgrade from ESXi 6.5 to 6.7 using esxcli

1. Shut down all VMs running on your ESXi host machine.

2. Enable SSH on your ESXi server, if it is not already enabled.

3. Connect via SSH.

4. Once logged in, run the following command to enter maintenance mode:

vim-cmd /hostsvc/maintenance_mode_enter

5. After putting ESXi into maintenance mode, run the following command to set the correct firewall rules for the httpClient:

esxcli network firewall ruleset set -e true -r httpClient

6. Next, run the following command to list the ESXi 6.7 updates available. You want the latest one that ends in -standard for your version of VMware.

esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep ESXi-6.7

7. Once you’ve identified the correct version of VMware (as of 5-18-2018, this is ESXi-6.7.0-8169922-standard), run the following command to download and install the update.

esxcli software profile update -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml -p ESXi-6.7.0-8169922-standard

Note: It is very important that you run esxcli software profile update here. Running esxcli software profile install may overwrite drivers that your ESXi host needs.

8. Once the update has been installed and prompts you to reboot, run the following command to restart:

reboot

9. After your ESXi host restarts, connect via SSH and run the following command to exit maintenance mode:

vim-cmd /hostsvc/maintenance_mode_exit

At this point, your ESXi host should be upgraded to ESXi 6.7.0.

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.

I’ve adapted Randy’s original script into two scripts, one for deleting computers and the other for deleting mobile devices. Both scripts work with a text file of Jamf Pro IDs, and also include error checking to make sure that the text file’s entries contained only positive numbers.

To use these scripts, you will need four things:

1. A text file containing the Jamf Pro computer or mobile device IDs you wish to delete.
2. The address of the appropriate Jamf Pro server
3. The username of an account on the Jamf Pro server which has the necessary privileges to delete computers and/or mobile devices.
4. The password to that account.

The test file should contain only the relevant Jamf Pro IDs and its contents should appear similar to this:

Once you have the text file and the other prerequisites, the scripts can be run using the following commands:

To delete computers:

/path/to/delete_Jamf_Pro_Computers.sh /path/to/text_filename_here.txt

To delete mobile devices:

/path/to/delete_Jamf_Pro_Mobile_Devices.sh /path/to/text_filename_here.txt

For authentication, the scripts can accept manual input or values stored in a ~/Library/Preferences/com.github.jamfpro-info.plist file.

The plist file can be created by running the following commands and substituting your own values where appropriate:

To store the Jamf Pro URL in the plist file:

defaults write com.github.jamfpro-info jamfpro_url https://jamf.pro.server.goes.here:port_number_goes_here

To store the account username in the plist file:

defaults write com.github.jamfpro-info jamfpro_user account_username_goes_here

To store the account password in the plist file:

defaults write com.github.jamfpro-info jamfpro_password account_password_goes_here

It is also possible to simulate a run of the script, to make sure everything is working before running the actual deletion. To put the script into simulation mode, comment out the following line of the script.

To take it out of simulation mode, uncomment the line.

In simulation mode, you can test out if the script is reading the text file properly and the authentication method. For example, the following output should be seen in simulation mode if the text file is being read properly and manual input is being used.

The following output should be seen in simulation mode if the text file is being read properly and the needed values are being read from a ~/Library/Preferences/com.github.jamfpro-info.plist file.

The scripts are available below, and at the following addresses on GitHub:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/delete_Jamf_Pro_Computers

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/delete_Jamf_Pro_Mobile_Devices

delete_Jamf_Pro_Computers.sh:

delete_Jamf_Pro_Mobile_Devices.sh:

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.

In my own shop, the directory service used by Jamf Pro has far more than five thousand users and groups. With the Use Wildcards When Searching setting enabled, lookups usually take a minimum of five seconds and a maximum of seven seconds.

With the Use Wildcards When Searching setting disabled, lookups now take between 0.03 and 0.001 seconds.

The downside to disabling wildcard searching is that you will need to search your directory service using the exact user or group name you want as your search criteria. Any result which is not an exact match will not be returned by the search. That said, the performance improvement usually makes this a worthwhile trade-off for losing the ability to search using wildcards.

To disable wildcard searching, use the following procedure:

1. Log into Jamf Pro.
2. Go into your Jamf Pro management settings:

Settings: System Settings: LDAP Servers: Your Directory Service Name Here (substitute your actual settings for Your Directory Service Name Here.)

4. Click the Edit button to edit the Your Directory Service Name Here settings.
3. Scroll to the bottom and locate the Use Wildcards When Searching setting.

4. If the setting is checked, uncheck it.

5. Click the Save button to save your changes.

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.

The fix was to add the following section to the script:

This section helps identify if Apple’s softwareupdate command line tool has returned more than one Xcode command line tool installation option. If more than one is available, the script will identify the last one listed and install that one.

Note: It is possible that a future release by Apple could result in the latest Xcode command line tool installer not being the one listed. This design decision was based on observation of past results.

The updated script is available below. It’s also available from my Github repo from the following link:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_xcode_command_line_tools

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.

As part of its paid plans, Slack includes an app integration called Email. This Slack app will give you an email address to send to and allow you to select a channel where the emails should appear.

As an example, you may want to set up a channel in your team’s Slack instance named #jamfpro-notifications and then configure the Email app so that it provides an email address associated with the #jamfpro-notifications channel.

Any emails sent to the specified address would appear in the #jamfpro-notifications channel. You can also configure a specific icon to be associated with the posted messages.

Once you have the Slack email address, you can then set up a local user in Jamf Pro to send the notifications. This user account can have no account privileges at all, as no privileges are needed to receive email notifications. To set up the user, please use the procedure below:

1. Log into your Jamf Pro server using an account with administrator rights.
2. Go into Management: System Settings: Jamf Pro User Accounts & Groups

3. Click the New button.

4. Select Create Standard Account and click the Next button.

5. Set up a new account, with the email address from Slack as the account’s email address.

Note: No account privileges need to be assigned to this account.

6. Once the new account has been set up and configured as desired, click the Save button.

7. Log out of your Jamf Pro admin account and log into the newly-created account.

8. If no privileges were set for the account, verify that everything is coming up as Access Denied.

9. Click the account drop-down menu and select Notifications.

10. Select your desired notification options. Once finished, click the Save button.

11. Log out of Jamf Pro.

Once that this has been configured, you can go to your Slack channel and see the notifications appear.

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.

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?

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.

The problematic sections are highlighted below. When the script backed up the AD mobile account’s password and then restored it, it was adding single quotes to the beginning and end of the password hash string.

The password hash string should have looked like this:

Instead, it looked like this:

The odd part of the situation is that macOS Sierra was seemingly OK with the extra characters in the password string. It wasn’t until the macOS High Sierra installer re-checked and altered the account plist that the problem occurred.

To fix the migration process, I’ve updated the script to better handle the account password backup and restoration process. The backup process is now querying dscl for the correct XML output and restoring it, which should address the problem with the script.

In my testing, the password hash is now appearing correctly in the account’s plist file.

Testing

This script has been tested and verified to migrate AD mobile accounts to local accounts on the following versions of macOS:

• macOS 10.13.5

In that testing, I did the following:

Testing on logged-in AD mobile user account:

1. I set up an AD-bound VM and created an AD mobile account with admin privileges.
2. I logged into the AD mobile account and ran the script while logged in as that account.
3. Once the account had been migrated, I rebooted and verified that I could log in at the OS login window.
4. I changed the password for the local account to a new one and rebooted.
5. I verified that I could log in at the OS login window with the new password.

Testing on logged-out AD mobile user account:

1. I set up an AD-bound VM and created an AD mobile account with admin privileges.
2. I logged into the VM using a local account which was not the AD mobile account and ran the script while logged in as that account.
3. Once the account had been migrated, I logged out and verified that I could log in at the OS login window with the just-migrated account.
4. I changed the password for the newly-migrated local account to a new one and rebooted.
5. I verified that I could log in at the OS login window with the new password.

Note: I did not test with FileVault-enabled accounts.

Advisory: Older versions of OS X and macOS were not tested and I have no idea if the script will work on those older OS versions.

Warning: I was able to test in my shop’s AD environment and verified that everything worked. That does not guarantee it will work in your environment. Test thoroughly before deploying in your own AD environment.

The updated script is available below, and also available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/migrate_ad_mobile_account_to_local_account

As part of working with the Jamf Infrastructure Manager (JIM), I wanted to see if I could find a least-privileged way to enroll a JIM with a Jamf Pro server. As it turns out, it’s pretty straightforward. For more details, please see below the jump.

To set up a JIM, three account privileges are required:

Jamf Pro Server Objects: Infrastructure Manager Instances: Create, Read, Update

To set up a user account with the specified privileges, please use the procedure below:

1. Log into your Jamf Pro server using an account with administrator rights.
2. Go into Management: System Settings: Jamf Pro User Accounts & Groups

3. Click the New button.

4. Select Create Standard Account and click the Next button.

5. Set up a new account with the following account privileges:

Infrastructure Manager Instances:

Create, Read, Update

6. Once the new account has been set up and configured as desired, click the Save button.

The account should now be available to help set up new Jamf Infrastructure Manager instances.

As part of a project, I needed to build an automated setup process for a Jamf Infrastructure Manager (JIM). Thanks to the help of some folks at Jamf, I have a process which runs non-interactively and which does the following on Red Hat Enterprise Linux 7.x:

1. Installs the JIM software
2. Enrolls the JIM with a Jamf Pro server

For more details, please see below the jump.

The key information I needed from Jamf was how to run an non-interactive enrollment of the JIM with a Jamf Pro server. This can be done with the following command:

/path/to/jamf-im enroll --hostname jim_hostname_goes_here --jss-url https://jamf.pro.server.here --password jamf_pro_account_password_goes_here --username jamf_pro_account_username_goes_here

This does require placing a password in the clear, so I recommend setting up an account on your Jamf Pro server which only has the required rights to enroll a JIM.

Once you’ve enrolled, you should be able to check /var/log/jamf-im.log and verify that enrollment has been successful. If it was successful, you should see log entries similar to what’s shown below:

You should also see the new JIM appear listed in your Jamf Pro server. To check this, use the following process:

1. Log into the Jamf Pro server using an admin account.
2. Go to Management: Server Infrastructure and select Infrastructure Managers.

3. You should see the new JIM listed there.

To help automate the process, I’ve written a script for CentOS 7.x / RedHat Enterprise Linux 7.x which does the following:

1. Checks to see if Java is installed and installs OpenJDK 8.x if it isn’t.
2. Checks for the JIM installer at a defined location
3. If the JIM installer is available, installs the JIM software.
4. Verifies that the JIM software has been installed.
5. Enrolls the JIM with a specified Jamf Pro server, using credentials provided in the script.

Pre-requisites

• A JIM installer .rpm file for CentOS / RedHat Enterprise Linux stored in the location defined in the script.
• Credentials for the specified Jamf Pro server

When successfully run, the output of the script should appear similar to that shown below:

The script is available below, and also available on GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Scripts/jamf_infrastructure_manager_automated_setup

About two weeks ago, I noticed I had an SSL error cropping up with one of my AutoPkg recipes:

[Errno socket error] EOF occurred in violation of protocol (_ssl.c:590)

When I investigated what it meant, I wound up at this lengthy issue opened for Python’s requests module. In the end, it seemed to boil down to four issues:

1. I was running AutoPkg on macOS Sierra 10.12.6.
2. The recipe I was running used a processor which called Python’s urllib2 library.
3. Python’s urllib2 library was calling the OS’s installed version of OpenSSL to connect to a server using TLSv1.2 .
4. The version of OpenSSL included with 10.12.6 does not support TLSv1.2 for the urllib2 library.

When I looked into the situation on macOS High Sierra 10.13.5, Apple had addressed the problem by replacing OpenSSL with LibreSSL. Among other improvements, LibreSSL allowed Python’s urllib2 library to be able to connect to servers using TLSv1.2. Problem solved!

Until I ran into another problem.

I had been using AutoPkgr as my way of managing AutoPkg and scheduling AutoPkg runs. However, when I set up AutoPkgr on a 10.13.5 VM and scheduled my AutoPkg nightly run, nothing happened except my CPU spiked to 100% and AutoPkgr locked up with the pinwheel of patience.

OK, maybe it was something with my VM. No problem, set up a new macOS 10.13.5 VM.

Same problem.

Maybe it was because I was trying to run the VM on VMware’s ESXi? Set up a new VM running in VMware Fusion. Same problem.

Maybe AutoPkgr was getting confused by Apple File System? I set up a 10.13.5 VM which used an HFS+ boot volume. Same problem, replicated on both ESXi and Fusion.

No matter what I tried, trying to run recipes using AutoPkgr on macOS 10.13.x resulted in the following:

• The VM’s CPU spiking to 100%
• AutoPkgr locking up with the pinwheel of patience
• My AutoPkg recipes not running

I was able to eliminate AutoPkg itself as being the issue, as running recipes from the command line using AutoPkg worked fine. With that information in mind, I decided to see if I could replicate what I most liked about using AutoPkgr into another form. In the end, my needs boiled down to three:

1. I wanted to be able to run a list of AutoPkg recipes on a scheduled basis. These recipes would be .jss recipes for uploading to a Jamf Pro server.
2. I wanted to be able to post information about those AutoPkg recipes to a Slack channel
3. I wanted all the error messages from an AutoPkg run, but I didn’t care about all the information that came from a successful AutoPkg run.

With that, I decided to draw on some earlier work done by Sean Kaiser, a colleague who had written a script for managing AutoPkg in the pre-AutoPkgr days. For more details, please see below the jump.

Sean’s solution relies on a script and LaunchDaemon running on a Mac, where it runs hourly and is set up to only send him emails if the AutoPkg logs are different from previous runs. The email notifications are a diff against the previous logs, so only the true differences get sent.

For those interested, Sean’s script is available from here:

https://github.com/seankaiser/automation-scripts/tree/master/autopkg

I was more focused on a once-daily run, so I didn’t want to use the diff methodology. After some more research, I found that my colleague Graham Pugh had written pretty much exactly what I needed: An AutoPkg post-processor named Slacker which could be used with an AutoPkg recipe list of .jss recipes to post the results to a Slack channel.

I forked a copy of the Slacker post-processor and (with Graham’s help) made some edits to it to have the output appear exactly the way I wanted it to.

New package message:

No new package message:

Along with the Slacker post-processor, I also found a script for sending multiline output to a Slack channel. This would allow me to send the complete error log from an AutoPkg run to a specified Slack webhook.

Using all of this, I wrote a script named autopkg-conductor which is designed to do the following:

1. Detect a list of AutoPkg recipes at a defined location and verify that the list is readable.
2. If the AutoPkg recipe list is readable and available, run the following actions:

A. Verify that AutoPkg is installed.
B. Update all available AutoPkg repos with the latest recipes.
C. Run the AutoPkg recipes in the list.

The AutoPkg run has all actions logged to ~/Library/Logs, with the logfiles being named autopkg-run-for- followed by the date.

If the optional slack_post_processor and slack_webhook variables are both populated, any AutoPkg .jss recipes should have their output sent to the Slack webhook specified in the slack_webhook variable.

If only the slack_webhook variable is populated, all output from the AutoPkg run is sent to the Slack channel. No filtering is applied, everything is sent.

If neither the slack_post_processor or slack_webhook variables are populated, no information is sent to Slack. All AutoPkg run information will be in the logs stored in ~/Library Logs.

For scheduled runs, I recommend the following:

1. Set up a user account named autopkg to run AutoPkg in.
2. Copy the autopkg-conductor script to /usr/local/bin/autopkg-conductor.sh and set the autopkg-conductor.sh script to be executable.
3. Set up a LaunchDaemon to run /usr/local/bin/autopkg-conductor.sh at a pre-determined time or interval.

For this example, the LaunchDaemon shown below will run /usr/local/bin/autopkg-conductor.sh as the autopkg user once a day at 2:00 AM.

The autopkg-conductor script is available below. It’s also available from GitHub using the following link:

https://github.com/rtrouton/autopkg-conductor

For those who want a copy of the documentation talk given by myself and my colleague Nikki Lewandowski at the Penn State MacAdmins 2018 conference, here is a link to the slides in Keynote format.

Keynote slides: https://goo.gl/nHWg3Z

In addition to Apple’s Developer Connection program for developers, Apple also has a program called AppleSeed, which is geared towards working with enterprise customers to help them test new Apple software.

During recent conversations about AppleSeed, I was told that it was better for AppleSeed members to submit bug reports and feature requests through AppleSeed’s Feedback Assistant. This would be in place of sending those bug reports and feature requests through Apple’s regular bug reporting at bugreport.apple.com.

Why? Two reasons:

1. Bug reports and feature requests sent through AppleSeed’s Feedback Assistant are seen and responded to by human beings.
2. There’s a smaller absolute number of items being sent through AppleSeed’s Feedback Assistant, which means that there’s less communication volume for Apple to sort through to get to your issue.

How to join AppleSeed

There’s no cost to join AppleSeed and you will not be asked to pay for anything, but you do need to be invited by Apple. This takes the form of an invitation code that you must provide when registering for AppleSeed.

If your company, school or institution has purchased an AppleCare Preferred, AppleCare Alliance and AppleCare Enterprise support plan, you should be given an opportunity to enroll into AppleSeed. If you haven’t been asked already, contact the Apple rep for your support plan and request an invitation.

What if your shop hasn’t purchased an AppleCare support plan? You are still able to request an invitation. To do so, use the following procedure:

1. Log into the MacAdmins Slack. If you’re not familiar with the MacAdmins Slack, please see this post by my colleague Armin Briegel.
2. Go to the #appleseed channel.
3. Politely ask how you can get an invitation to join AppleSeed.

Note: 

One thing that’s important to know is that discussions about AppleSeed-provided software should not take place in the #appleseed channel. The reason is that AppleSeed software is covered by Apple’s NDA for AppleSeed, where participants in the program agree not to publicly discuss the software or their experiences with it.

As part of building my autopkg-conductor solution for automating AutoPkg runs, I also wanted to automate the setup of AutoPkg and JSSImporter. My colleague Graham Pugh has written a setup script for his environment, which I was able to adapt and extend for my own needs. For more details, please see below the jump.

This script is designed to set up a Mac running macOS 10.13.x or later with the following:

• AutoPkg
• JSSImporter
• The AutoPkg recipe repos defined in the script.

The script checks to see if the following components are installed. If any are missing, they’re installed on an as-needed basis:

• git
• AutoPkg
• JSSImporter

It also installs the following Python tools and modules on an as-needed basis:

• pip
• cryptography
• requests (if not otherwise installed by AutoPkg or JSSImporter)

The script also includes the following features:

• The ability to set JSSImporter to use a Jamf Pro cloud distribution point as the master distribution point

• The ability to install either the latest release of JSSImporter or JSSImporter 0.5.1.

The reason that JSSImporter 0.5.1 is set as a specific install option is that JSSImporter 1.0 does not currently support uploading to a Jamf Pro cloud distribution point. JSSImporter 0.5.1 does support uploading to a cloud distribution point, so while the upload issues are being worked out with JSSImporter 1.x, using the older JSSImporter 0.5.1 is the currently recommended workaround.

Once these tools and modules are installed, the script does the following:

1. Configures AutoPkg to use the recipe repos defined in the AutoPkg repos section.

2. Configures JSSImporter to connect to the desired Jamf Pro server with the correct distribution point settings.

This script should not be run with root privileges or you will receive the following warning:

Instead, the script should be run by an account with sudo privileges, so that entering the account’s password will allow sudo to run specified processes with root privileges. If you try to run this script using an account without sudo privileges, you will receive the following warning:

If the script is successfully run, the script output should look similar to what is shown below.

If a Jamf Pro cloud distribution point is set as the master distribution point:

If a Jamf Pro file share distribution point is set as the master distribution point:

The script is available below. It’s also available from GitHub using the following link:

https://github.com/rtrouton/autopkg_setup_for_jamf_pro

For those who wanted a copy of my Mac management session at at the Penn State MacAdmins 2018 conference, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/PSU2018SAPPDF

Keynote – http://tinyurl.com/PSU2018SAPKeynote