Building an SAP GUI installer for macOS

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.

Creating Privacy Preferences Policy Control profiles for macOS

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.

Using directory membership to manage Apple Remote Desktop permissions

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.

The T2 Macs, the end of NetBoot and deploying from macOS Recovery

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.

Updated MigrateADMobileAccounttoLocalAccount script now available to fix migration bug

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

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

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

— Per Olofsson (@MagerValp) June 15, 2018

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

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

— Per Olofsson (@MagerValp) June 15, 2018

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

Updated Xcode command line tools installer script now available

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

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

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

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

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

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

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

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

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