While I’m not at Apple’s WWDC conference this year, several other folks in the community stepped up to help crowdsource questions and answers for the Mac admin community. Due to wanting to stay on the right side of Apple’s NDA, the resulting notes have been posted to Apple’s developer forums rather than to here.

To make it easier for Mac admins to access them, I’ve set up a post in the forums where I’ve linking the various forum posts. It’s available via the link below:

https://forums.developer.apple.com/message/234797

To help keep on top of software updates, I’ve been using AutoPkg in combination with AutoPkgr and JSSImporter for a while now to upload new software updates to Jamf Pro. However, I recently ran into a challenge when I wanted to build an AutoPkg recipe for Apple’s Enterprise Connect.

AutoPkg recipes usually rely on the vendor having a publicly accessible way to get downloads via HTTP or HTTPS. Apple does not have a publicly accessible download URL for Enterprise Connect and in fact discourages customers from sharing the download link. The fact that there was a download link meant that I could write AutoPkg recipes but at the same time I couldn’t include the URL needed to download the latest update as part of the recipe .

After some thinking and research into AutoPkg’s functionality, I found a way to create AutoPkg recipes for Enterprise Connect while at the same time not sharing Apple’s download URL. For more details, see below the jump.

The solution is to use an AutoPkg recipe override to store the download URL for Enterprise Connect. Recipe overrides are locally-stored files that allow you to change certain input variables in AutoPkg recipes.

Since the recipe overrides are stored locally on the Mac which is running AutoPkg and not shared with any other resources, Apple’s download URL for Enterprise Connect is only made available to the AutoPkg installation running on that specific Mac.

I have written AutoPkg recipes for Enterprise Connect, which are available from here:

https://github.com/autopkg/rtrouton-recipes/tree/master/EnterpriseConnect

By default, the EnterpriseConnect.download recipe contains a non-functional placeholder value and requires that placeholder value to be overridden before the recipe will work.

To use the Enterprise Connect recipes, you will need to create a recipe override of the desired recipe and enter the URL Apple sends you into the DOWNLOAD_URL value of the override. Here’s an example of using, using AutoPkgr and the EnterpriseConnect.jss recipe.

1. Launch AutoPkgr.

2. If needed, add the rtrouton-recipes repo to AutoPkg.

3. Click on the Repos & Recipes tab and locate the EnterpriseConnect.jss recipe

4. Right-click on the EnterpriseConnect.jss recipe and select Create Override…

5. Give the recipe override a unique name.

6. Go to /Users/username_goes_here/Library/AutoPkg/RecipeOverrides and locate the newly-created recipe override file.

7. Open the recipe override file file in a text editor and locate the DOWNLOAD_URL value.

8. Change the DOWNLOAD_URL value of the override from the non-functional placeholder value to whatever the current download URL is for Enterprise Connect.

When you run the recipe override using AutoPkg, it should use the Enterprise Connect’s current download URL in place of trying to use the non-functional placeholder value.

Note: The download.apple.com URL shown in the example above is also a placeholder. As I mentioned earlier, Apple discourages customers from sharing the download link.

Apple’s download URL for Enterprise Connect may change, so you will need to check and update the download URL as needed in the recipe override when you’re notified by Apple that a new Enterprise Connect version is now available.

The good folks who host the MacDevOpsYVR conference have begun posting the session videos from MacDevOpsYVR 2017. As the session videos are being posted to YouTube, I’ve linked my Storing our digital lives: from MFS to APFS session here:

The other videos from the conference are being posted here:

https://www.youtube.com/channel/UCIZgKKNrG-ty72Bez8b2qHg/videos

VMware recently released VMware Fusion 8.5.8, which according to the release notes includes the following:

Another improvement which is not mentioned in the release notes is that VMware Fusion now includes support for the following:

• Using the macOS High Sierra beta installer as a valid installation source
• Booting macOS VMs from Apple File System (APFS) formatted drives.

For more details, see below the jump.

Advisory

I am not going to be going into details about macOS High Sierra as part of this post due to Apple’s NDA on pre-release software. This is going to focus on VMware Fusion 8.5.8 and any screenshots will be of VMware’s software only.

For those who are participating in the beta program and who have access to the the macOS High Sierra beta installer, you can use the procedure below to install macOS High Sierra into a VMware Fusion 8.5.8 VM:

Pre-requisites

• VMware Fusion 8.5.8 or later
• The macOS High Sierra beta installer

1. Launch VMWare Fusion 8.5.x

2. In VMWare Fusion, select New… under the File menu to set up a new VM

3. In the Select the Installation Method window, select Install from disc or image.

4. In the Create a New Virtual Machine window, click on Use another disc or disc image…

5. Select the macOS High Sierra beta installer

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the macOS High Sierra beta installer is selected, then click the Continue button.

7. In the Choose Operating System window, set the OS to the folllowing then click the Continue button.

• Operating System: Apple OS X
• Version: macOS 10.12

8. In the Finish window, select the Customize Settings button if desired.

Otherwise, click the Finish button.

9. VMware Fusion will convert a copy of the macOS High Sierra beta installer into a VMDK file that it can boot from.

10. Save the VM file in a convenient location.

11. Start the VM.

The VM should boot into the macOS High Sierra beta installer. To convert the VM’s boot drive to use APFS, use the APFS conversion option when it appears as part of the macOS installation process.

I’ve moved on from a role where I needed to support Clarivate Analytics’s EndNote bibliography software, but I noticed that my colleague Rusty Myers is now deploying it in his environment.

As part of his work, Rusty discovered that it was possible to bypass the activation process by adding the AcceptedENX7.2EULA key to /Library/Preferences/com.ThomsonResearchSoft.EndNote.plist:

In Rusty’s case, the key is being added by running the following commands with root privileges:

/usr/bin/defaults write "/Library/Preferences/com.ThomsonResearchSoft.EndNote.plist" "AcceptedENX7.2EULA" -string "1"

Reading through Rusty’s post, I wondered if you could apply this setting via a management profile instead of writing the necessary values to /Library/Preferences/com.ThomsonResearchSoft.EndNote.plist. With some testing, I verified that it’s possible to also bypass the activation process with a management profile.

For those who want to bypass EndNoteX8’s activation process using a management profile, I’ve created a .mobileconfig file and posted it here on Github:

https://github.com/rtrouton/profiles/tree/master/ActivateEndNote/EndNoteX8

I’ve also created one for EndNoteX7, since it appears that the setting has not changed since EndNoteX7’s release. However, I do not have access to that version of EndNote and can’t test it to make sure.

If you’re still deploying EndNote X7, please give it a try and let me know. The .mobileconfig file for EndNoteX7 has been posted here on Github:

https://github.com/rtrouton/profiles/tree/master/ActivateEndNote/EndNoteX7

As part of some work I’ve been doing with Amazon Web Services, I needed to enable object versioning on all S3 buckets in an account.

However, I had three issues that I needed to accommodate for:

1. There were a sufficient number of S3 buckets that enabling versioning via the S3 web console would be inconvenient.
2. Some of the S3 buckets in the list already had object versioning enabled, while others in the list did not.
3. I had forgotten which ones already had versioning enabled, so I’d have to check each one.

To address all three issues, I’ve written a script that uses the aws command line tool to detect which S3 buckets do not have object versioning enabled and enable it on the detected S3 buckets. For more details, see below the jump.

The script is designed to do the following:

1. Check the object versioning status of all S3 buckets associated with an AWS account
2. Enable object versioning on any S3 buckets where object versioning is not enabled.

It does this by using the following command to download and format a list of all the S3 buckets associated with a particular AWS account:

aws s3api list-buckets --query 'Buckets[*].Name' | sed -e 's/[][]//g' -e 's/"//g' -e 's/,//g' -e '/^$/d' -e 's/^[ \t]*//;s/[ \t]*$//'

Once it has the list, the script loops through each bucket individually to check if the S3 bucket’s object versioning is reporting the following status:

Enabled

• If the S3 bucket is reporting an Enabled status, the following output is displayed:

The Bucket_Name_Goes_Here S3 bucket has object versioning enabled.

• If the S3 bucket reports any other status than Enabled, object versioning is enabled and the following output is displayed:

The Bucket_Name_Goes_Here  S3 bucket does not have object versioning enabled. Enabling object versioning on the Bucket_Name_Goes_Here S3 bucket.

The script is available below. It is also available on GitHub via the following link:

https://github.com/rtrouton/aws_scripts/tree/master/enable_s3_versioning_for_AWS_S3_buckets

I’ll be speaking at Penn State MacAdmins Conference 2017, which is taking place in State College, PA from July 11th – 14th, 2017. My session will be an overview of Apple’s past and present filesystems, with an introduction to Apple File System (APFS) and a discussion of its current state of development. For those interested, my talk will be on Wednesday, July 12th.

For a description of what I’ll be talking about, please see the Storing our digital lives: Mac filesystems from MFS to APFS session description. You can see the whole list of speakers here on the Speakers page.

In a number of Mac-using environments, there is often a need for IT staff to remotely connect to a Mac’s screen using Apple’s Remote Desktop application and work with the person on the other end to resolve a problem. However, there can be several technical and human-centric issues with enabling remote assistance:

1. Authentication – To enable access using a username and password, that user account must be granted access rights by belonging to a group or by explicitly granting rights to a local account.
2. Password rotation – If you’re enabling screensharing via granting access to a local account, the security requirements in most environments mandate that those passwords be changed on a regular basis. However, securely changing the account password on multiple remote Macs can be a management challenge on its own.
3. Access privileges – A lot of folks don’t like the idea that someone they don’t know can take over access to their keyboards and screens without the remote customer saying it’s OK for them to do so. Frankly, I’ve been on both sides of this fence and I don’t like it either.

However, there is a way to enable screen sharing using Apple’s Remote Desktop Client and Apple’s Screen Sharing.app which does the following:

• Removes the need for any account to be enabled for screen sharing access
• Mandates that all screen sharing access be approved by the logged-in user
• Does not allow screen sharing access if no user is logged in.

For more details, see below the jump.

To configure Apple’s Remote Desktop Client to allow only explicitly-permitted screen sharing access, use the following procedure:

1. Log into the Mac in question
2. Open System Preferences
3. Select the Sharing preferences

4. Check the Remote Management box to turn on the Remote Desktop Client

5. In the Allow access for: section, select the Only these users: option, but do not select any users.

6. Click the Computer Settings… button.

7. Select the Anyone may request permission to control screen option, then click the OK button.

8. Close System Preferences

You may also configure the Remote Desktop Client using Apple’s kickstart utility. To set the above configuration using the kickstart utility, run the command shown below with root privileges:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -allowAccessFor -specifiedUsers -setreqperm -reqperm yes

Once the Remote Desktop Client is configured this way, the Remote Desktop Client should not allow any remote user to authenticate successfully, but will allow the logged-in user to permit screen sharing requests from remote users.

To screen share with a remote Mac configured this way, use the following procedures:

Sending a screen sharing request

1. Open the Screen Sharing application
2. Under the Connection menu, select New…

3. In the Connect To: blank, enter the DNS name or IP address of the remote Mac then click the Connect button.

4. When prompted to log in, select By requesting permission.

5. Once By requesting permission is selected, click the Connect button.

6. Wait for the response.

Accepting a screen sharing request

1. On the remote Mac’s screen, a Share Screen Request prompt will appear to the logged-in user.

2. If all appears OK, click the Share Screen button.

Once the request has been accepted, the remote Mac’s screen should appear in the Screen Sharing application.

With this Remote Desktop Client configuration, there must be a logged-in user in order for a screen sharing connection to take place. If no user is logged in, then the By requesting permission option will not appear in the login prompt.

This method only enables the following functions: 

1. Screen sharing
2. The ability to copy files from the remote Mac, by dragging and dropping the file from its location on the remote Mac to a location outside of the Screen Sharing window.

None of the Remote Desktop Client’s other features will be enabled, including the ability to copy files to the remote Mac, pull reports from the remote Mac, or the ability to run commands on the remote Mac. 

As part of preparing for macOS High Sierra, I need to file bug reports to report problems that I’m finding with the beta releases. As part of this, I’ve started using a tool named Brisk. It helps streamline the process by filing bug reports via a native app on my Mac, rather than having to go through this process:

1. Open a web browser.
2. Go through the process of signing into bugreport.apple.com
3. File a bug report Apple’s bug reporting web interface

Brisk also makes it easy to cross-post the submission of a bug report to OpenRadar. Since bugreport.apple.com is not publicly searchable and only allows developers to see their own bugs, OpenRadar is a way for developers to share their own bug reports and keep both themselves and their colleagues up-to-date on the status of various bugs filed with Apple. For more details, see below the jump.

To get started with Brisk:

1. Download a copy of the Brisk drag-and-drop application from the GitHub release page and copy it somewhere convenient.

2. Launch Brisk. You should see a new icon appear in your menubar.

3. You should be prompted to enter an Apple ID. Enter the Apple ID username and password that you normally use to sign into bugreport.apple.com

4. Select New Radar

5. A window will open with the appropriate bug report fields.

6. Enter your bug report. Once complete, click the Submit button.

7. Brisk will file the bug report with bugreport.apple.com.

You may also want to make application settings adjustments in the General section of Preferences, or register an OpenRadar account, but that’s up to you.

If an OpenRadar account is registered, a copy of your bug report will be submitted to bugreport.apple.com and automatically cross-posted to OpenRadar.

Among Brisk’s features is the ability to file a duplicate bug report. For folks not familiar with how Apple’s bug reporting works, the idea of deliberately filing a bug report that duplicates someone else’s bug report may seem redundant. It’s reporting the same problem, right? Doesn’t Apple already have that information?

Yes, they do but Apple also uses duplicate bug reports as a way to judge how many folks are impacted by a particular issue and can use that information when deciding the best way to assign resources to fixing a problem. A million people reporting a particular problem via duplicate bug reports gives Apple information about that problem’s scope that they wouldn’t necessarily have if they just had one person reporting the problem. A duplicate bug report may also include new information about the problem which wasn’t captured in the initial bug report.

To help streamline the process of duplicating an already-submitted bug, Brisk includes the Duplicate Radar function. This function works with OpenRadar to download the original bug report’s contents from OpenRadar and create a copy of the bug report in Brisk.

To submit a duplicate bug report:

1. Click on the menubar icon and select Duplicate Radar

2. A Duplicate Radar dialog window will appear

3. Enter the ID number of the bug report that you want to duplicate.

4. A new window will open with the contents of the original bug report.

Note: In some cases, all of the original bug report’s information may appear in the Description: field. Cut and paste into the different fields as appropriate.

5. If desired, add additional information. Once complete, click the Submit button.

6. Brisk will file the duplicate bug report with bugreport.apple.com and (if applicable) with OpenRadar.

For those who wanted a copy of my filesystem talk at the Penn State MacAdmins Conference 2017 conference, here are links to the slides in PDF and Keynote format.

PDF – http://tinyurl.com/psumac2017pdf

Keynote – http://tinyurl.com/psumac2017key

As part of a recent discussion, a colleague posted in the MacAdmins Slack that they needed to deploy printers as part of a DeployStudio workflow. DeployStudio doesn’t natively include this functionality, so that meant developing a way to deploy the desired printers to the appropriate Macs via one of the following methods:

• Using a script
• Using a management profile

As part of the conversation, I pointed to Nick McSpadden‘s PrinterGenerator tool:

https://github.com/nmcspadden/PrinterGenerator

Nick’s tool is designed to create printer configurations for deployment via Munki. However, my colleague wasn’t using Munki in this case and didn’t plan to deploy it. So even though there was a tool that could have solved the problem, adapting it to work for my DeployStudio-using colleague’s needs was going to take some time and effort.

The discussion got me started thinking about the problem of printer deployments and ways to solve it that could work for the vast majority of deployment solutions. After some research and testing, I’ve developed a solution that may work for most deployment needs. For more details, see below the jump.

My solution was to build a script named payload-free_package_printer_generator.sh, which does three tasks:

1. Accept printer configuration input.
2. Use that input to generate a script which uses the lpadmin tool to create printers with the provided configuration information.
3. Generate a payload-free package to run the script.

Running the script

Usage

/path/to/payload-free_package_printer_generator.sh -n -l -d -a -p -1 -2 -3 -4 -5 -6 -7 -8 -9 -c

Options:

• -n: Name of the print queue. May not contain spaces, tabs, # or / characters. (required)
• -l: The physical location of the printer. Examples may include Reception Desk, Librarian’s Office or Second Floor, Room 2C456 (optional)
• -d: The printer name which is displayed in the Printers & Scanners pane of System Preferences, as well as in the print dialogue boxes. (required)
• -a: The IP or DNS address of the printer. Protocol must be specified as part of the address (for example, use lpd://ip.address.goes.here or lpd://dns.address.goes.here for LPR printing.) (required)
• -p: Name of the driver file in /Library/Printers/PPDs/Contents/Resources/. This must use the full path to the drive (starting with /Library). (required)
• -1: Specify first printer option. (optional)
• -2: Specify second printer option. (optional)
• -3: Specify third printer option. (optional)
• -4: Specify fourth printer option. (optional)
• -5: Specify fifth printer option. (optional)
• -6: Specify sixth printer option. (optional)
• -7: Specify seventh printer option. (optional)
• -8: Specify eighth printer option. (optional)
• -9: Specify ninth printer option. (optional)
• -c: Name of the Apple Developer ID Installer certificate being used to sign the payload-free package. Certificate name should be formatted like Developer ID Installer: Your Name or Developer ID Installer: Your Name (F487797D). (optional)

Note: This script needs to be run with root privileges.

Examples

To create an unsigned payload-free package using only the required printer configuration options, run the command shown below with root privileges:

/path/to/payload-free_package_printer_generator.sh -n PrinterQueueGoesHere -d PrinterNameGoesHere -a lpd://ip.address.goes.here -p /Library/Printers/PPDs/Contents/Resources/PrinterDriverPPDHere.gz

The script’s output should appear similar to that shown below:

The script will generate a postinstall script that looks like this:

Once the postinstall script has been created, a payload-free package will be generated using the script. Once the package has been generated, a new Finder window will appear to show the completed package’s location.

If you need to sign the payload-free package, that is possible using the -c option. For example, you may need to create a signed package that sets up a printer with the following settings:

Printer Queue Name:  ReceptionDeskBrotherLaserPrinter
Printer Location:  Reception Desk
Printer Display Name:  Reception Desk Brother Laser Printer
Printer Address:  lpd://192.168.1.186
Printer Driver:  /Library/Printers/PPDs/Contents/Resources/Brother HL-2170W series CUPS.gz

To create an signed payload-free package which can create this printer, run the command shown below with root privileges:

/path/to/payload-free_package_printer_generator.sh -n ReceptionDeskBrotherLaserPrinter -l "Reception Desk" -d "Reception Desk Brother Laser Printer" -a lpd://192.168.1.186 -p "/Library/Printers/PPDs/Contents/Resources/Brother HL-2170W series CUPS.gz" -c "Developer ID Installer: Rich Trouton (XF95CST45F)"

You may be prompted to authorize access to your Developer ID certificate.

Once authorized, the package will be generated.

You can verify that the package is signed by clicking on the padlock icon in the Installer window.

Testing

To test a payload-free package generated by this script, take it to a Mac which does not already have the desired printer set up on it and run the installer package.

Note: The appropriate printer drivers must be installed prior to setting up the printer. If not, the lpadmin tool which is used by the payload-free package to set up the printer will generate an error and the installer package will report a failed install.

The printer should be set up as specified.

The script is available below. It is also available from GitHub at the following address:

https://github.com/rtrouton/payload-free_package_printer_generator

As part of a discussion with a colleague, he said that he needed to build an installer for his shop’s F5 Network’s VPN service but wasn’t sure how. I hadn’t built one of these previously either, so I decided to look into it.

Fortunately, F5 Networks has made the process of creating one a fairly straightforward process, assuming that your VPN administrator can provide the needed config_tmp.f5c configuration file. Assuming that you can get that file, all that’s needed is making sure that the config_tmp.f5c file is located in the same directory as the VPN client installer.

The reason for this is that the postinstall scripts of the F5 VPN client installer are set to look for that file in that location, and will automatically import the configuration file’s contents if the file is found.

Once I had both the config_tmp.f5c config file and a copy of the F5 VPN client installer, I was able to create an installer using this method that handled both the installation and the automated configuration of the F5 VPN client. For more details, see below the jump.

Prerequisites:

• Packages
• The F5 VPN client installer (provided by your VPN administrator)
• The appropriate config_tmp.f5c config file (provided by your VPN administrator)

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

2. In this case, I’m naming the project F5 BIG-IP VPN Client

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 Post-Installation Behavior section, set On Success: to Do Nothing
• In the Options section, check the box for Require admin password for installation.

5. Click on the Scripts tab in your Packages project.

6. Select the F5 VPN client installer and drag it into the Additional Resources section of your Packages project.

7. Select the config_tmp.f5c config file and drag it into the Additional Resources section of your Packages project.

8. The last piece is telling the F5 VPN installer to run. For this, you’ll need a postinstall script. Here’s the one I’m using:

9. Once you’ve got the postinstall script built, run the following command to make the script executable:

sudo chmod a+x /path/to/postinstall

10. Once completed, add the postinstall script to your Packages project.

11. Last step, go ahead and 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 taking it to a test machine that does not have the F5 VPN client and install it. The end result should be that the F5 VPN client installs along with the specified VPN configuration.

The good folks at Penn State have begun posting the session videos from the Penn State MacAdmins Conference 2017. The sessions slides and currently-available videos are all accessible from the Penn State MacAdmins’ Resources page at the link below:

http://macadmins.psu.edu/conference/resources/

As all the session videos have been posted to YouTube, I’ve linked my Storing our Digital Lives: Mac filesystems from MFS to APFS session here:

As part of my Jamf Pro testing process, I will often set up a VM using a production setup workflow then enroll that newly-setup VM into my test Jamf Pro server. However, as part of my production workflow setup, I will usually install my CasperCheck self-repair solution in order to make sure the machine stays enrolled with my Jamf Pro server.

Unfortunately, this can lead to the following chain of events:

1. Test VM is enrolled in the test Jamf Pro server
2. CasperCheck runs on its pre-set schedule and detects that it is not enrolled with the Jamf Pro server specified in the script.
3. CasperCheck runs its repair functions and enrolls the test VM in the production server.
4. I wonder why my test VM isn’t talking to the test Jamf Pro server.
5. I check the CasperCheck log, grumble when I notice that CasperCheck has done its job, and then install the test server’s CasperCheck script on the test VM.
6. Reboot the test VM to trigger the test server’s CasperCheck script to enroll the test VM into the test server again.

This situation happened infrequently enough in the past that I usually just dealt with it on an individual basis, but I finally decided to fix it by writing a Jamf Pro Extension Attribute to help me identify which Jamf Pro server was specified in the installed copy of CasperCheck . For more details, see below the jump.

The Jamf Pro Extension Attribute needs to have the file path to the CasperCheck LaunchDaemon defined. Once this is done, the Extension Attribute is designed to do the following:

If the defined LaunchDaemon is not installed, script returns the following:

CasperCheck Not Installed

2. If the defined LaunchDaemon is installed but the script is unable to determine the address of the Jamf Pro server, script returns the following:

CasperCheck not configured with Jamf Pro server address

3. If the defined LaunchDaemon is installed and the script is able to determine the address of the Jamf Pro server, the script returns the address of the Jamf Pro server defined in the CasperCheck script. This will be displayed in a similar way to the example shown below:

jamf-pro.domain.com

Please see below for how the Extension Attribute should be configured.

The Extension Attribute is available below. It is also available from GitHub at the following address:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/Casper_Extension_Attributes/CasperCheck/caspercheck_assigned_jamf_pro_server

When testing various security functions, like System Integrity Protection or High Sierra’s new kernel extension functionality, it’s often useful to be able to boot a macOS virtual machine (VM) into the Recovery environment. However, it can be challenging to select the VM and hold down Command+R in time to boot to the Recovery environment. This can result in having to try several or more times before you can successfully boot the VM to Recovery HD.

Fortunately, VMware has a setting that enables a forced boot to Recovery HD. For more details, please see below the jump.

My colleague mosen discovered that you could add the following setting to a macOS VM’s .vmx configuration file:

macosguest.forceRecoveryModeInstall = "TRUE"

Once this setting has been added to the .vmx configuration file, the VM will automatically boot to Recovery HD the next time it is started.

To add the macosguest.forceRecoveryModeInstall setting to a macOS VM:

1. Shut down the relevant VM.
2. Open the VM’s .vmx file for editing.

3. Add the following line to the end of the .vmx configuration file:

macosguest.forceRecoveryModeInstall = "TRUE"

4. Save the changes to the .vmx configuration file.
5. Start the VM.

The VM should boot from the macOS VM’s Recovery HD partition automatically, and will continue to boot to Recovery until the setting is removed from the VM’s .vmx file.

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

• Prepare your institution for iOS 11, macOS High Sierra, or macOS Server 5.4: https://support.apple.com/HT207828

As part of the KBase article, Apple included a Changes coming with macOS High Sierra section which featured this note:

macOS High Sierra introduces a new feature that requires user approval before loading new third-party kernel extensions. This feature will require changes to some apps and installers in order to preserve the desired user experience.

That section in turn links to this KBase article, which describes the behavior in more detail:

• Prepare for changes to kernel extensions in macOS High Sierra: https://support.apple.com/kb/HT208019

To improve security on the Mac, kernel extensions installed with or after the installation of macOS High Sierra require user consent in order to load. This is known as User Approved Kernel Extension Loading. Any user can approve a kernel extension, even if they don’t have administrator privileges.

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

Apple has been trying to discourage third party software developers from using kernel extensions for the past few years. The reason for this has been that kernel extensions are able to plug into the macOS kernel’s space and access low-level resources, like hardware devices. The issue for Apple is that, when kernel extensions aren’t working right, the whole OS has problems that wouldn’t otherwise happen.

As an example of this, if an application which doesn’t use a kernel extension has a memory error, the worst consequence is that the affected application crashes. The rest of the OS is fine though, thanks to the OS’s memory protections. However, if a kernel extension has a similar issue, the kernel doesn’t have similar memory protections. A memory error in a kernel extension can cause a kernel panic, which crashes the whole operating system.

As a result, starting with OS X Mavericks, Apple has been making changes to how third party kernel extensions have been allowed to operate:

OS X Mavericks

Kernel extensions should be digitally signed using an Apple Developer ID for Signing Kexts certificate, but this code signing requirement is not enforced strictly. Unsigned kernel extensions can still be installed into /System/Library/Extensions, which is where kernel extensions have been installed up until OS X Mavericks. However, signed kernel extensions must be installed into /Library/Extensions.

OS X Yosemite

Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. However, it is still possible on OS X Yosemite to enable a kernel extension developer mode which disables the code signing requirement.

OS X El Capitan

Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection, introduced as part of OS X El Capitan, now enforces code signing and explicitly disables the kernel extension developer mode previously available in OS X Yosemite.

macOS Sierra

Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection remains the enforcement mechanism.

macOS High Sierra

Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection remains the enforcement mechanism. Kernel extensions will not load unless authorized to do so by a logged-in user.

Note: This authorized user does not need to have admin rights, so any logged-in user can authorize the loading of a kernel extension.

What are the likely consequences of this change in High Sierra?

• For the individual consumer owner of a Mac, this will likely not be a big deal. Since anybody can authorize the loading of the kernel extension, the individual can go click whatever is needed and continue on with their day. Potentially not a great user experience, but not awful.
• For Mac admins, this change is potentially going to be a huge pain in the neck. A number of third-party applications used in education and enterprise environments use kernel extensions, especially antivirus and other security-focused solutions. Now these kernel extensions are not going to load automatically and it’s going to be up to the individual users who use those machines as to whether or not those kernel extensions get loaded.

That said, Apple has stated that third-party kernel extensions won’t require authorization under the following conditions:

• The third party kernel extension(s) in question were on the Mac before the upgrade to macOS High Sierra.
• The third party kernel extension(s) in question are replacing previously approved extensions.

Apple has also provided a couple of ways that companies, schools or institutions can deal with this issue:

1. Boot into macOS Recovery and use the spctl command line tool.

Note: Apple has not yet specified how this tool should be used in High Sierra’s Recovery environment. The guidance provided is Run the command by itself to get more information about how to use the spctl command. 

Another section of this KBase article also notes that resetting NVRAM will revert the Mac in question back to requiring user authorization to load kernel extensions.

2. Enroll your Macs with a mobile device management (MDM) solution. If a Mac is enrolled with an MDM solution, even if that MDM solution isn’t being used to actively manage the Mac in question, the new kernel extension authorization behavior is disabled and kernel extension behavior goes back to that enforced by macOS Sierra:

Kernel extensions must be digitally signed using an Apple Developer ID for Signing Kexts certificate and installed into /Library/Extensions. System Integrity Protection remains the enforcement mechanism.

Conclusion

Apple is advertising these changes now so that Mac admins can have at least some chance to prepare their environments before macOS High Sierra is released in the fall. For those shops which are already using a mobile device management solution with their Macs, the new kernel extension behavior should be a non-event on High Sierra’s release day. High Sierra should detect that the Mac is enrolled in MDM and revert to macOS Sierra’s behavior of automatically allowing properly signed kernel extensions to load.

For those shops which aren’t currently using a mobile device management solution with their Macs, they currently appear to have the following choices for macOS High Sierra:

1. Allow their user population to handle the new kernel extension authorization process
2. Use the new macOS Recovery-based process of using the spctl tool in the Recovery environment to disable the new kernel extension behavior
3. Get a mobile device management solution and enroll their Macs running macOS High Sierra.

While working with some colleagues, I recently built a management profile that my one colleague requested to be set as non-removable. Normally, this can be accomplished by setting the PayloadRemovalDisallowed key in the profile to a boolean value of true.

I provided the profile to my colleague and he tested it out. However, in the course of testing, he discovered that the profile could be removed by a user with administrative rights using the following procedure:

1. Open System Preferences
2. Select the profile in question.
3. Click the minus button.

4. Be warned about removing a locked profile.

5. Enter admin credentials when prompted.

After entering admin credentials, the profile was then removed.

When I checked Apple’s reference documentation on configuration profiles, the issue came down to how the profile was being delivered. Apple’s documentation includes the following note about the PayloadRemovalDisallowed key:

This profile was being installed by an installer package, so from Apple’s point of view it was being installed manually. That meant that the manual installation behavior, where the profile could be removed by anyone with admin rights, was the applicable behavior here.

Another colleague working with us on this issue suggested adding a removal password to the profile, using Apple’s com.apple.profileRemovalPassword profile payload.

A removal password for a profile is designed to allow the removal of a management profile, even if that profile is otherwise set to be non-removable. For more details, see below the jump:

In our case, we were seeking to block removal rather than facilitate it. However, having the removal password added as a payload worked for our purposes as well because now the profile could not be removed without supplying the password. An example Removal Password payload is available below:

Once the Removal Password payload is added to a profile where PayloadRemovalDisallowed set to true, the removal process for a manually installed profile now looks like this:

1. Open System Preferences
2. Select the profile in question.
3. Click the minus button.

4. Be warned about removing a locked profile and that removal will require a password.

5. Supply the removal password when prompted.

6. Enter admin credentials when prompted.

If the profiles command line tool is being used to remove the profile in question, the -z option can be used to supply a profile removal password.

To show the Removal Password payload in the context of a full management profile, please see below:

As part of preparing for macOS Sierra in 2016, I prepared a smart group that listed Macs incompatible with macOS Sierra. Apple stated at WWDC 2017 that any Mac that can run macOS Sierra can also run macOS High Sierra, so that means that the list of incompatible Macs has not changed. For more details, see below the jump:

Here’s the list of Mac models which are incompatible with macOS High Sierra:

To create a smart group that contains the list of incompatible Macs, I’ve updated the smart group XML file I created last year for macOS Sierra. The smart group XML file is available below:

This smart group can be imported into a Jamf Pro server via the API. To upload it to a JSS server using the API, download the XML file to a convenient location, then run the command shown below (substituting as appropriate):

curl -skfu username:password https://jamfpro.server.here:8443/JSSResource/computergroups/id/0 -T /path/to/filename.xml -X POST;

If the smart group was successfully uploaded, you should next see output similar to that shown below:

A new smart group named Macs incompatible with macOS High Sierra should also now be present on the Jamf Pro server.

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

• Prepare for APFS in macOS High Sierra: https://support.apple.com/HT208018

Apple makes a number of statements about APFS and its effects in this KBase article, but what do they all mean? I’m going to try to clarify while staying on the right side of Apple’s NDA. For more details, see below the jump.

APFS conversion criteria

• Question: What kind of drives will be converted to APFS?
• Answer:

• Question: If the drive qualifies, is the HFS+ -> APFS conversion automatic when I upgrade to High Sierra?
• Answer: Yes

APFS compatibility

• Question: Can you read and write to an HFS+ formatted drive while booted from an APFS formatted drive?
• Answer: Yes

• Question: Can you read and write to an APFS-formatted drive while booted from an HFS+ drive?
• Answer:
  • On macOS High Sierra and later: Yes
  • On older versions of macOS, OS X and Mac OS X: No

APFS and FileVault

• Question: Can a FileVault-encrypted drive be converted to APFS as part of the the macOS High Sierra upgrade process?
• Answer: Yes. If the drive qualifies for the conversion process, the encrypted drive will be converted from HFS+ to APFS as part of the macOS High Sierra upgrade process.
  • As part of the conversion process, the encrypted Core Storage volume will be removed from the drive and the drive will have APFS’s native encryption activated.

APFS and Boot Camp

• Question: Can I run Windows using Boot Camp on an APFS boot drive?
• Answer: Yes. However, Windows will not have the necessary driver support to read or write to APFS formatted drives.

APFS and file sharing

• Question: Can I enable AFP file sharing to share directories stored on an APFS drive?
• Answer: No. SMB file sharing will need to be used.

• Question: What file sharing protocols can share directories stored on an APFS drive?
• Answer: SMB and NFS

APFS and Time Machine

• Question: Do I need to change anything in Time Machine to back up an APFS drive?
• Answer: No.

• Question: Do I need to change anything in Time Machine to back up an APFS boot drive?
• Answer: No.

• Question: Can I use AFP to set up Time Machine share points on an APFS drive?
• Answer: No, AFP file sharing won’t work on an APFS drive. Use SMB file sharing instead.

As part of my testing of macOS High Sierra, I’ve noticed that login behavior has changed for local accounts, in cases where the password of the login keychain is different from the password of the account logging in.

On macOS Sierra, the following behavior occurs when the password of the login keychain is different from the password of the local account logging in:

1. The login process pauses
2. You’re prompted to continue login, create a new keychain, or update the existing keychain password.

3. If you choose to update the existing keychain password, you enter the keychain’s current password (which is usually the account’s former password.)

4. The login process proceeds and the desktop comes up.

On macOS High Sierra, the following behavior occurs when the password of the login keychain is different from the password of the local account logging in:

1. The login keychain with the different password is renamed to login_renamed_number_goes_here.keychain-db and stored in ~/Library/Keychains.

2. A new login keychain is created in ~/Library/Keychains. The new login keychain is named login.keychain-db and uses the password of the local account logging in.

Note: This is behavior I’ve observed for local accounts only. I have not been able to test with network accounts, like Active Directory mobile accounts.

Update 9-26-2017: This behavior was addressed in the betas for Active Directory mobile accounts:

The reason why this behavior is problematic is that anything stored in the former login keychain is not transferred to the new login keychain. Saved passwords, certificates, and any other secrets stored in the now-former login keychain will not be present in the new login keychain. They will need to be manually copied, or re-saved into the new login keychain.

For more details, see below the jump.

I’ve been able to reproduce this behavior in the following ways:

1. Open Keychain Access
2. Under the Edit menu, select Change password for keychain “login”…

3. Change the password of the keychain to be different from the account’s login password
4. Log out of the account
5. Log back in

1. Log in as a different account with administrator privileges
2. Open System Preferences
3. Select Users & Groups
4. Click the lock icon and provide administrator credentials when prompted.
5. Select the relevant account
6. Click the Reset Password button.

7. Change the relevant account’s password.

8. Log out of the different account.
9. Log in as the relevant account.