Starting in 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 white list for third-party kernel extensions. However, I would anticipate that this list will grow over time.

Starting in macOS 10.13.4, you can use the profiles command line tool to determine if a machine is enrolled into a MDM, and if user-approved MDM is enabled. To do this, run the command shown below:

profiles status -type enrollment

Depending on your MDM enrollment status, you may see one of the following statuses shown below:

No MDM enrollment

computername:~ username$ profiles status -type enrollment
Enrolled via DEP: No
MDM enrollment: No
computername:~ username$

MDM enrolled, without user-approved MDM enabled

computername:~ username$ profiles status -type enrollment
Enrolled via DEP: No
MDM enrollment: Yes
computername:~ username$

MDM enrolled, with user-approved MDM enabled

computername:~ username$ profiles status -type enrollment
Enrolled via DEP: No
MDM enrollment: Yes (User Approved)
computername:~ username$

DEP Enrolled

computername:~ username$ profiles status -type enrollment
Enrolled via DEP: Yes
MDM enrollment: Yes (User Approved)
computername:~ username$

Note: If your Mac is enrolled in Apple’s Device Enrollment Program (DEP), it automatically gets user-approved MDM.

To help detect if a particular Mac has user-approved MDM enabled, I’ve written a script. For more details, please see below the jump.

The script first checks the OS on a particular Mac and verifies that it is running macOS 10.13.4 or later. If the Mac is running an earlier OS, the script reports the following:

Unable To Detect User-Approved MDM On, followed by the OS version.

If the script verifies that the Mac is running macOS 10.13.4 or later, the script continues on to determine if the Mac has user-approved MDM enabled.

If the Mac has user-approved MDM enabled, the script reports the following:

Yes

If the Mac does not have user-approved MDM enabled, the script reports the following:

No

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

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/detect_user-approved_mdm

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_user-approved_mdm

One of the changes introduced in Jamf Pro 10.3 is that 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.

Why the difference?

Using the MDM enrollment method on macOS High Sierra will automatically enable User Approved MDM, which is necessary for full management privileges on the Mac in question. The reason is that since the user is installing the MDM profile, the user is also logically approving the MDM management and satisfying Apple’s conditions for enabling User Approved MDM.

For more details, please see below the jump.

The installation of the MDM profile can be configured two ways:

1. The installation of a CA certificate, followed by an MDM profile
2. The installation of the MDM profile only.

The difference between the two depends on if your Jamf Pro server is using a trusted third-party SSL certificate, either directly on your Jamf Pro server or on a load balancer which is handling SSL termination for the Jamf Pro server.

If one of the two conditions mentioned above applies, where your Jamf Pro server is using a trusted third-party SSL certificate, you can set the CA certificate installation to be skipped using the following procedure:

1. Log into your Jamf Pro server using an account with administrator privileges.
2. Go to the management settings
3. Click on Global Management
4. Select User-Initiated Enrollment

5. Check the Skip certificate installation during enrollment checkbox.

If you’re not sure, leave the Skip certificate installation during enrollment checkbox unchecked. This will allow the installation of the CA certificate before the installation of the MDM profile.

Enrolling by installing a CA certificate, followed by an MDM profile

Pre-requisites

• macOS 10.13.0 or later

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

3. Click the Enroll button.

4. When notified that you’ll need to install the CA certificate, click the Continue button.

5. When prompted to install the CA certificate, click the Continue button.

6. When asked to verify that you want to install the CA certificate, click the Install button.

A new CA Certificate profile should now appear in the User Profiles section of the Profiles preference pane.

7. When prompted to enroll the MDM profile, click the Continue button.

8. When prompted to install the Profile Service Enrollment profile, click the Install button.

9. When prompted to configure your Mac using a certificate, mobile device management and SCEP enrollment, click the Continue button.

10. When prompted to enroll the MDM profile, click the Install button.

11. When prompted for admin credentials, provide the username and password of a user with admin credentials.

The profile will install and should appear as verified.

The enrollment page should report that enrollment is complete.

Enrolling by installing an MDM profile

Pre-requisites

• macOS 10.13.0 or later

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

3. Click the Enroll button.

4. When prompted to enroll the MDM profile, click the Continue button.

5. When prompted to install the Profile Service Enrollment profile, click the Install button.

6. When prompted to configure your Mac using a certificate, mobile device management and SCEP enrollment, click the Continue button.

7. When prompted to enroll the MDM profile, click the Install button.

8. When prompted for admin credentials, provide the username and password of a user with admin credentials.

The profile will install and should appear as verified.

The enrollment page should report that enrollment is complete.

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

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:

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 the 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 Apple 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

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

Keeping up on Apple developer betas and other developer software releases is a necessary part of many Mac admins’ regular routine. It’s especially important during the period between WWDC in June and the annual OS release in the fall. Fortunately, Apple provides a way to help tracking developer releases easier by publishing a notification to the following address:

https://developer.apple.com/news/releases/

This publicly-accessible notification doesn’t discuss what’s included in the newly-released software and you will still need an Apple Developer Connection account in order to get the details. For many Mac admins though, having an easy and quick way to track if the latest developer beta has been released is valuable information in itself.

To make it even more convenient, Apple also offers a RSS feed for the Developer Releases page:

https://developer.apple.com/news/releases/rss/releases.rss

You can add this feed into your RSS reader and it’ll keep you up to date. If you use Slack, another approach is to use Slack’s ability to post content from an RSS feed to a Slack channel. For more details, please see below the jump:

To enable Slack to post from the Developer Releases RSS feed to a Slack channel, you’ll need to enable the RSS application on your Slack.

The procedure on how to do this is linked below:

https://get.slack.help/hc/articles/218688467-Add-RSS-feeds-to-Slack

Once you have the RSS application installed for your Slack instance, follow the procedure below:

1. Set up a channel in Slack to receive the content from the RSS feed.

For this example, I’ve set up a channel named #apple-developer-feed.

2. In the RSS application, click the Add RSS integration button.

3. In the Feed URL blank, enter the following URL:

https://developer.apple.com/news/releases/rss/releases.rss

4. Select the channel you want the RSS feed’s content to post to from the Post to Channel drop-down menu.

In this case, it’ll be posted to the #apple-developer-feed channel.

5. Once the RSS feed and channel have been properly set up, click the Subscribe to this feed button.

The RSS feed will now show as being posted to the selected channel.

Once this is configured, Slack will now post any new content from the RSS feed to the specified Slack channel.

In late 2017, Apple released the iMac Pro. Along with the new Secure Enclave protection provided by Apple’s T2 chip, the iMac Pro brought another notable development: It did not support booting from a network volume, otherwise known as NetBoot.

The one exception was Apple’s Internet Recovery, where Apple is providing a NetBoot-like service to provide access to macOS Recovery. The iMac Pro is still able to boot to Internet Recovery, which provides a way to repair the Mac or reinstall the operating system in situations where the Mac’s own Recovery volume is missing or not working properly.

With NetBoot not being available for the iMac Pro but still available for other models, it wasn’t yet clear if NetBoot-based workflows for setting up new Macs or rebuilding existing ones were on the way out. However, Apple’s release of of T2-equipped MacBook Pros in July 2018 which also could not use NetBoot has made Apple’s direction clear. As Apple releases new Mac models equipped with T2 chips and Secure Enclave, it is unlikely that these future Mac releases will be supporting NetBoot.

For Mac admins using NetBoot-based workflows to set up their Macs, what are the alternatives? Apple has been encouraging the use of Apple’s Device Enrollment Program, which leverages a company, school or institutions’ mobile device management (MDM) service. In this case, you would need to arrange with Apple or an Apple reseller to purchase Macs that are enrolled in your organization’s DEP.

When a DEP-enrolled Mac is started for the first time (or started after an OS reinstall), it is automatically configured to use your organizations’ MDM service and the device checks in with the MDM service. The MDM service then configures the Mac as desired with your organization’s software and configuration settings. A good example of what this process may look like can be seen here.

What if you don’t have DEP, or you don’t have MDM? In that case, you may still be able to leverage Recovery-based deployment methods, which would allow you install the desired software and configuration settings onto the Mac’s existing OS, or install a new OS along with software and configuration settings. For more details on these methods, please see below the jump.

To help facilitate deploying software and settings from the Recovery environment, Greg Neagle has released a couple of tools:

bootstrappr: https://github.com/munki/bootstrappr
installr: https://github.com/munki/installr

Both bootstrappr and installr can run in the macOS Recovery environment and work in similar ways. The main difference between the two is the following:

• bootstrappr: Installs one or more packages onto a target volume
• installr: Installs macOS and one or more additional packages onto a target volume

As an example of how bootstrappr works, please see below. In this case, I’ve set up a disk image using the instructions provided at the bootstrappr GitHub repo and copied it to an external drive named Provisioning.

On the disk image, I’ve included one installer package named First Boot Package Install, which was generated by my First Boot Package Install Generator tool.

1. Boot to macOS Recovery

2. Launch Terminal

3. Run the following command:

hdiutil mount /Volumes/Provisioning/bootstrap.dmg

The bootstrap disk image mounts as a new volume named bootstrap.

4. Run the following command:

/Volumes/bootstrap/run

5. Select the volume to install on (in this example, the volume is named Macintosh HD.)

The First Boot Package Install package included in the disk image is installed.

6. Once installation is completed, select the option to restart.

On restart, the First Boot Package Install package is able to run its own workflow, which is able to suppress the Apple Setup Assistant and run its assigned installation task. In this case, I’m only having it check for and install all available Apple software updates but it could be installing any desired package. This could include all software needed to set up a particular Mac, or installing a management agent to handle software installation and configuration.

Apple Remote Desktop (ARD) is a screen sharing and remote administration tool that just about every Mac admin uses at some point. Configuring access permissions for it can be done in several ways:

1. Using System Preferences’ Sharing preference pane to configure the Remote Management settings.
2. Using the kickstart command line utility to grant permissions to all or specified users
3. Using the kickstart command line utility to grant permissions to members of specified directories.

The last item may be the least-known method of assigning permissions, but it can be the most powerful because it allows ARD’s management agent to be configured once then use group membership to assign ARD permissions. For more details, please see below the jump.

As documented in the Apple Remote Desktop administrator guide, Apple’s directory-based permissions model looks like this:

In the past, these rights could be assigned via Apple’s Workgroup Manager using MCX, using a configuration like the one shown below:

However, this MCX-based method does not seem to work on macOS High Sierra. I have not yet been successful when assigning them using a management profile.

A secondary method using local groups on the Mac still works as of macOS High Sierra.

To configure ARD permission management via assignment to a local group, the following procedure should be used:

1. Create the following groups on your Mac:

com.apple.local.ard_admin
com.apple.local.ard_interact
com.apple.local.ard_manage
com.apple.local.ard_reports

2. Add the desired user(s) or groups to the relevant com.apple.local.ard_ group.

3. Configure ARD using the kickstart utility to recognize and use directory-based logins.

For example, the command shown below will enable the ARD management agent and configure it to use directory-based logins:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -clientopts -setdirlogins -dirlogins yes

Once configured, ARD permissions can be assigned by adding and removing from the relevant com.apple.local.ard_ groups. For example, adding a local user account named Administrator to the local com.apple.local.ard_admin group produces the following results.

Without any other configuration, the Administrator account now appears listed in the Remote Management settings.

The account also has the following ARD permissions assigned, with the permissions grayed out so that they can’t be changed:

• Generate reports
• Open and quit applications
• Change settings
• Copy Items
• Delete and replace items
• Send messages
• Restart and Shut down
• Control
• Observe
• Show being observed

Adding a local user account named User Name to the com.apple.local.ard_interact group produces the following results.

Without any other configuration, the User Name account now appears listed in the Remote Management settings.

The account also has the following ARD permissions assigned, with the permissions grayed out so that they can’t be changed:

• Control
• Observe
• Show being observed

To assist with creating these groups and assigning user accounts to them, I’ve written the following script. It does the following:

1. Allows a username and group to be specified for ARD permissions
2. Verifies that the username exists on the Mac
3. Creates all four ARD permissions management groups
4. Adds the specified user account to the specified management group
5. Turns on ARD’s management agent and configures it to use ARD’s directory-based management to assign permissions

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

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

As part of the pre-release announcements about macOS Mojave, Apple released the following KBase article:

Prepare your institution for iOS 12 or macOS Mojave:

https://support.apple.com/HT209028

As part of the KBase article, Apple included a Changes introduced in macOS Mojave section which featured this note:

You can allow apps to access certain files used for system administration, and to allow access to application data. For example, if an app requests access to your Calendar data, you can allow or deny the request. MDM administrators can manage these requests using the Privacy Preferences Policy Control payload, as documented in the Configuration Profile Reference.

What’s all this mean? For more details, see below the jump.

As part of macOS Mojave, Apple introduced new controls for accessing data in the individual user home folders. For more details about these changes, I recommend that you check out the following video and blog posts. Don’t worry about me, I’ll wait:

• Better Apps through Better Privacy: https://developer.apple.com/videos/play/wwdc2018/718/
• Apple Events Usage Description: https://indiestack.com/2018/08/apple-events-usage-description/
• macOS Mojave gets new APIs around AppleEvent sandboxing – but AEpocalyse still looms: https://www.felix-schwarz.org/blog/2018/08/new-apple-event-apis-in-macos-mojave
• A Looming Mac Automation Apocalypse?: https://sixcolors.com/link/2018/08/a-looping-mac-automation-apocalypse/

Back? OK, now that you’re familiar with what Apple was talking about with that section of the KBase, let’s discuss this section:

MDM administrators can manage these requests using the Privacy Preferences Policy Control payload, as documented in the Configuration Profile Reference.

What this means is that you may be able to whitelist your most common interactions and prevent them from displaying dialogs. Unfortunately, as of this date, Apple has provided only the following as documentation:

https://developer.apple.com/enterprise/documentation/Configuration-Profile-Reference.pdf (see the Privacy Preferences Policy Control Payload section.)

Apple refers to these as Privacy Preferences Policy Control Payload profiles, with a com.apple.TCC.configuration-profile-policy payload type. TCC stands for transparency consent and control and was discussed as part of the How iOS Security Really Works session at WWDC 2016:

https://developer.apple.com/videos/play/wwdc2016/705/?time=674

These profiles can only be deployed to macOS Mojave and must be deployed by an user-approved MDM solution.

While the current documentation doesn’t provide a lot of detail, based on my research, here is how the whitelist appears to work:

1. The item being whitelisted must be code-signed

As part of the profile, there is an entry for code signature so that the OS can verify that the whitelist entry matches up against the app requesting the action. How do you find out what the code signature of a particular app is? Run the following command against the application or other item that you want to whitelist:

codesign -dr - /path/to/Application.app

That said, there’s two ways that you can do this for third-party applications. As an example, if you’re using Jamf Pro 10.x to manage your Macs, the following application should be installed on your Mac:

/Library/Application Support/JAMF/Jamf.app

If you run the following command, you should get the code signature for the app:

codesign -dr - "/Library/Application Support/JAMF/Jamf.app"

There’s two ways you can add this information to the profile:

Example A:

identifier "com.jamf.management.Jamf" and anchor apple generic

Example B:

identifier "com.jamf.management.Jamf" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"

Example A should be considered the least secure as it is very generic in how it reads the code signature, while Example B is the most secure because the full code signature is specified.

However, if Jamf ever needed to fundamentally change the code signature it was using for Jamf.app, Example A’s code signature would continue to match while Example B’s would not. Code signature fundamentals don’t change that often, but it is something to be aware of when creating the profiles.

One other thing to watch out for is multiple lines being returned by the code signature check, as I ran into this when checking an application produced by McAfee.

codesign -dr - "/Library/Application Support/McAfee/MSS/Applications/Menulet.app"

The needed code signing is what’s listed on the designated => line of output:

identifier "com.yourcompany.Menulet" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = GT8P3H7SPW

2. The whitelist covers the parent process which is performing the action

Note: Here we’re heading off into territory that I can’t get confirmation about yet from Apple’s documentation. My research has lead me to the belief that the information below is right, but I don’t know for sure. Deploy appropriate levels of skepticism.

When creating the whitelist, you’re likely going to need to do a lot of testing to figure out what is actually calling an action that needs to be permitted by the user via a dialog window which appears. In many cases, you’ll need to whitelist the parent process which is asking for X, which in turn is running Y, which is executing Z and Z is what is actually causing the dialog window to appear.

A good example is when using Jamf’s Self Service to install software. A Self Service policy might include the following:

1. The policy which installs the software.
2. A notification that tells you “Hey, the software’s installed”
3. A script that pops up its own dialog window to say “Hey, we’ve installed this software but it’s unlicensed and we need you to now enter the license code you got from the help desk.”

Jamf has a couple of applications involved in this process to help it go smoothly:

/usr/local/jamf/bin/jamf
/usr/local/jamf/bin/jamfAgent

The notification and dialog window may trigger a dialog window which asks you if you want to allow a particular thing to happen. Depending on which application triggered it, you may see a notification that jamf (or jamfAgent) is the one requesting it. However, it may seem senseless: that “Hey, the software’s installed” notification is clearly an AppleScript dialog; why isn’t AppleScript the one being referred to as the requester?

The reason is that whichever application was named was the process that started the chain of events going. If jamfAgent is the one referenced, that means that the jamfAgent process is the process that asked AppleScript “Hey, mind showing that to my friend sitting between the keyboard and chair? Thanks.” So in this situation, even though it’s ultimately an AppleScript dialog window that appears, you would need to whitelist /usr/local/jamf/bin/jamfAgent.

3. There are filesystem permissions and there are application permissions

There are a number of dictionary keys available to the whitelist profiles:

• AddressBook
• Calendar
• Reminders
• Photos
• Camera
• Microphone
• Accessibility
• PostEvent
• SystemPolicyAllFiles
• SystemPolicySysAdminFiles
• AppleEvents

For whitelisting things like dialog messages and allowing access to data, there are two that seem to matter most:

• SystemPolicyAllFiles
• AppleEvents

SystemPolicyAllFiles allows the whitelisted application access to all protected files. As an example, your antivirus software may pop up dialog messages like crazy because it’s trying to scan areas of your home folder that Apple has now marked as protected. Once you identify the process which is actually running the scan and whitelist it using SystemPolicyAllFiles, the scans should now succeed without dialog messages because the scanning process has now been authorized by the whitelist to go into those areas.

AppleEvents allows the whitelisted application the ability to send an AppleEvent to an otherwise restricted application. For example, you may have a script which includes the following command:

osascript -e 'display dialog "Hey there!" with title "Hello"'

You may get a dialog window requesting permission to let osascript control the Finder. If you add an entry to your whitelist for /usr/bin/osascript, to authorize it to be able to send AppleEvents to com.apple.Finder, now you won’t get the permission request because now osascript is authorized to send requests to the Finder.

Creating the profiles

When creating my own profiles, I found a great tool created by Carl Ashley:

https://github.com/carlashley/tccprofile

This tool allowed me to plug in what I needed to whitelist and generated a profile for me. For example, I wanted to generate a profile for McAfee Endpoint Security with the following criteria:

Full Disk Access:

/Library/Application Support/McAfee/MSS/Applications/Menulet.app
/usr/local/McAfee/fmp/bin/fmpd

Note: /usr/local/McAfee/fmp/bin/fmpd is the McAfee file scanner

Able to send restricted AppleEvents:

/Library/Application Support/McAfee/MSS/Applications/Menulet.app – Send AppleEvents to SystemEvents, SystemUIServer and Finder

I was able to use the following command with the tccprofile tool to generate the profile I needed:

However, there was a problem with the profile because of McAfee’s extra code-signing line.

Once the profile was edited to remove the extra code signature information, the profile was ready to go.

Reference Examples

Since this is a new area for Mac admins, I’ve posted several profiles for reference at the following location:

https://github.com/rtrouton/privacy_preferences_control_profiles

All were generated by the tccprofile tool and I’ve included README files that describe the individual profiles and the commands used to create the profile in question.

Since I’ve started working for my current employer, my colleagues and I have occasionally received the following question from various Mac admins:

“I’m using SAP in my environment. How do I deploy the Mac software for SAP?”

When we’ve followed up for more details, the “Mac software for SAP” usually means the SAP GUI software. SAP GUI comes in two flavors:

• SAP GUI for Windows
• SAP GUI for Java

SAP GUI for Java supports the following operating systems:

• openSUSE
• Fedora
• macOS
• Microsoft Windows
• AIX
• Ubuntu

The SAP GUI for Java is what’s available for macOS, so how to get it and deploy it? For more details, please see below the jump.

Pre-requisite

SAP GUI is a Java application, so Java must be installed before proceeding further. As of October 11, 2018, I recommend installing the latest Oracle Java 8 JDK for macOS.

The Java JDK can be downloaded from the following website:

https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

Getting the SAP GUI for Java software

1. Go to the following link:

https://support.sap.com/en/my-support/software-downloads.html

2. Click on Support Packages & Patches

3. Click on Access Downloads

4. Select By Category

5. Select SAP Frontend Components

6. Select SAP GUI for Java

7. Click on the latest SAP GUI for Java

As of October 11, 2018, this will be SAP GUI for Java 7.50

8. Verify that the Items Available to Download drop-down menu is set to MAC OS

9. Select and download the latest available PlatinGUI .jar file.

Building configuration files

Along with the SAP GUI application, you can also prepare a set of pre-configured settings files for SAP GUI. These configuration files are described as part of the documentation for SAP GUI, in the Administration: Configuration Files section

Once you have your connections and settings files configured the way you want them, export them and name them as follows:

Connections: connections.template
Settings: settings.template

If you have additional exported settings, also follow the .template naming scheme.

Once you have your .template files ready, use the following Java command to create a file named templates.jar:

jar -cf /path/to/templates.jar /path/to/filename1.template /path/to/filename2.template /path/to/filename3.template

For example, if I have a settings.template file and a trustClassification.template file stored in my home folder, I would use the following Java command to create a templates.jar file on my user account’s Downloads folder:

jar -cf /Users/username/Downloads/templates.jar /Users/username/settings.template /Users/username/trustClassification.template

The .template files are stored inside the templates.jar file:

If the templates.jar file is in the same directory as the PlatinGUI .jar file when the installation process is run, the .template files will be installed along with the SAP GUI application and stored in SAP GUI.app/Contents/Resources.

When a user launches the SAP GUI application, if they do not already have an ~/Library/Preferences/SAP directory, the settings.template and trustClassification.template files will be copied to the ~/Library/Preferences/SAP directory with the following filenames:

• ~/Library/Preferences/SAP/settings
• ~/Library/Preferences/SAP/trustClassification

Building the SAP GUI installer

Pre-requisites:

• Packages
• SAP GUI for Java installer (this is the PlatinGUI .jar file)
• templates.jar file (optional)

1. Set up a new Packages project and select Raw Package.

2. In this case, I’m naming the project SAP GUI 7.50 rev4.

3. Once the Packages project opens, click on the Project tab. You’ll want to make sure that the your information is correctly set here (if you don’t know what to put in, check the Help menu for the Packages User Guide. The information you need is in Chapter 4 – Configuring a project.)

In this example, I’m not changing any of the options from what is set by default.

4. Next, click on the Settings tab. In the case of my project, I want to install with root privileges and not require a logout, restart or shutdown.

To accomplish this, I’m choosing the following options in the Settings section:

In the Tag section:

Identifier: set as appropriate (for my installer, I’m using com.sap.pkg.SAPGUI750rev4)
Version: set as appropriate (for my installer, I’m using 7.50.04 )

In the Post-installation Behavior section:

On Success: should be set to Do Nothing

In the Options section:

Require admin password for installation should be checked
Relocatable should be unchecked
Overwrite directory permissions should be unchecked
Follow symbolic links should be unchecked

5. Select the Payload tab. Nothing here should be changed from the defaults.

6. Select the Scripts tab. Under the Additional Resources section, add the following file:

The SAP GUI for Java installer (this is the PlatinGUI .jar file)

If you have a templates.jar file, also add that file.

7. The last part is telling the SAP GUI for Java installer to run with the correct options selected. For this, you’ll need a postinstall script.

See below the postinstall script being used for this installer package:

Once created, select the postinstall script and add it to the project.

8. Build the package. (If you don’t know to build, check the Help menu for the Packages User Guide. The information you need is in Chapter 3 – Creating a raw package project and Chapter 10 – Building a project.)

Testing the installer

Once the package has been built, test it by installing it on a test machine which has the following:

• Java installed
• Does not have the SAP GUI client installed

The end result should be that the SAP GUI client installs into /Applications.

If a templates.jar was included with the installer, the SAP GUI configuration template files specified by the templates.jar file should also be installed.

With Java 8 approaching the end of its lifecycle, Oracle has made some changes to the Oracle JDK license that will affect Java 11’s JDK. As of Oracle Java JDK 8, you can use the JDK for free in the following circumstances:

• Development
• Testing
• Prototyping
• Production

As of Oracle Java JDK 11, you can use the JDK for free in the following circumstances:

• Development
• Testing
• Prototyping

Notice that Production has dropped off the list? If you use Oracle Java JDK 11 for production use, Oracle is now expecting payment. For the complete details, please see the license agreement (relevant sections highlighted below):

If you don’t want to or can’t pay Oracle, what are the available options?

1. Keep using Oracle Java JDK 8

Oracle will continue to provide updates for Java 8 until January 2019, so a short-term solution is to keep using JDK 8 until support ends. This is only a short term solution however. If you want to continue using Java 8 past January 2019, you may need to start paying Oracle in order to get access to continuing Java 8 support.

2. Migrate from Oracle Java JDK to OpenJDK

In addition to its commercial offering, Oracle has an open-source Java available named OpenJDK. As of Java 11, Oracle will be providing functionally identical JDK builds to both the commercially licensed Oracle JDK and the open-source OpenJDK. For more details, please see below the jump:

An important difference between Oracle JDK 11 and OpenJDK 11 for Mac admins is the following:

• Oracle JDK: Oracle will provide an installer package for macOS
• OpenJDK: Oracle does not provide an installer for macOS at this time.

OpenJDK builds for macOS are currently available as zip and tar.gz files. The JDK files need to be uncompressed and moved into the following location on macOS:

/Library/Java/JavaVirtualMachines

Once uncompressed into /Library/Java/JavaVirtualMachines, the JDK build should be stored in a directory named for the specific OpenJDK version. The directory and all enclosed files need to have the following permissions set:

macOS should automatically pick up the new Java version once added to /Library/Java/JavaVirtualMachines.

To display information about it, run the following command:

java -version

To help address the current lack of an installer package for OpenJDK 11, I’ve written several AutoPkg recipes:

The .pkg recipe will create an installer package which does the following:

1. Removes any existing OpenJDK 11 builds from /Library/Java/JavaVirtualMachines using a preinstall script
2. Installs the latest OpenJDK 11 build with the correct permissions into /Library/Java/JavaVirtualMachines

The preinstall script used is available below:

For those who wanted a copy of my Mac management talk at at Jamf Nation User Conference 2018, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/JNUC2018SAPPDF

Keynote – http://tinyurl.com/JNUC2018SAPKeynote

When working with configuration profiles on Jamf Pro, I prefer to download and back them up to GitHub or a similar internal source control tool. The reasons I do this are the following:

1. I have an off-server backup for the profiles
2. I can track changes to the profiles

Up until recently, this had been a manual process for me where I would download the profiles in question from the server and then upload them to my source control tool.

My process looked like this:

1. Download the profiles from the Jamf Pro server using the Download button.

2. Remove the code-signing and formatting the profile using a process similar to the one described in the link below:

https://macmule.com/2015/11/16/making-downloaded-jss-configuration-profiles-readable/

3. Move the profile to the correct directory in my source control repo.
4. Review changes and commit to the repo.

However, as I’ve started using profiles more, this process got cumbersome and I wanted to automate at least the download part of the process. After some work, I was able to build two scripts which do the following:

1. Use the Jamf Pro API to identify the Jamf Pro ID numbers of the configuration profiles.
2. Download each profile using its Jamf Pro ID number
3. Decode and format the profile
4. Identify the display name of the profile
5. Save the profile as Display Name Here.mobileconfig to a specified download directory.

For more details, please see below the jump.

I’ve written two scripts for this purpose:

• Jamf_Pro_Mac_Configuration_Profile_Download.sh – This script is designed to download and handle macOS configuration profiles
• Jamf_Pro_Mobile_Device_Configuration_Profile_Download.sh – This script is designed to download and handle iOS and tvOS configuration profiles

For authentication, the scripts can accept hard-coded values in the script, 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

Both scripts run in similar ways, with the main difference being which kind of profiles are being downloaded.

To download macOS profiles:

/path/to/Jamf_Pro_Mac_Configuration_Profile_Download.sh

To download iOS and tvOS profiles:

/path/to/Jamf_Pro_Mobile_Device_Configuration_Profile_Download.sh

When run, you should see output similar to that shown below.

The profiles themselves will be stored in either a user-specified directory or, if no directory is specified, a directory created by the script.

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

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

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

Jamf_Pro_Mac_Configuration_Profile_Download.sh:

Jamf_Pro_Mobile_Device_Configuration_Profile_Download.sh: