As part of my day job, I support some medical research software packages that most Mac admins have likely never heard of. One of these software packages is DNAStar‘s Lasergene software suite. Up until now, this software used an Installer VISE installer, which required me to completely repackage the software for deployment. However, as of Lasergene 13.x, DNAStar has switched to using Bitrock’s InstallBuilder for the Lasergene installer. This tool does not produce standard installer packages, but InstallBuilder installer applications do support installation and uninstallation via the command line. That allows me to run an installation or uninstallation of the Lasergene suite by using the commands shown below:

To install a copy of DNAStar Lasergene which uses a network license server:

"/path/to/DNASTAR Lasergene Installer.app/Contents/MacOS/installbuilder.sh" --mode unattended

To install a copy of DNAStar Lasergene which uses an individual license code:

"/path/to/DNASTAR Lasergene Installer.app/Contents/MacOS/installbuilder.sh" --dnastarProductKey XXXXX-XXXXX-XXXXX

To uninstall DNAStar Lasergene:

"/Applications/DNASTAR/Uninstall Lasergene 13.app/Contents/MacOS/installbuilder.sh" --mode unattended

While this installation method is still not ideal, I can at least script it. That makes it an improvement over the hand-crafted installers I previously had to create for Lasergene.

Unfortunately, there is a quirk of Lasergene’s installation process which carries over from the Installer VISE days, which is that the Lasergene installer assumes that the account running the installation is going to be the owner of the application. So if you install Lasergene as your local admin, that may mean that your users aren’t able to run the Lasergene applications because they may not have permission to run the applications or access one or more of the application data files.

To address both the installation and permissions issues, I was able to create an installer using this method that handles both the installation and then fixing the permissions as a post-installation task. For more details, see below the jump.

In this example, I’m creating an installer package which will install both the DNAStar Lasergene software and the configuration needed to connect to a DNAStar network license server.

Prerequisites:

• Packages
• The latest DNAStar Lasergene installer application
• The appropriate network license files from DNAStar.

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

2. In this case, I’m naming the project DNAStar 13.0.0.0

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 DNAStar Lasergene installer application and associated network license files and drag them into the Additional Resources section of your Packages project.

7. The last piece is telling the Lasergene installer to run, then fix the permissions after the software is installed. For this, you’ll need a postinstall script. Here’s the one I’m using:

Notice that $install_dir in the postinstall script refers to the path to the package’s working directory. That’s where Packages will be storing the Lasergene installer application along with the associated network license files, inside the Package-built installer’s embedded directory where it stores the items defined in the Additional Resources section.

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

sudo chmod a+x /path/to/postinstall

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

10. 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

Once the package has been built, test it by taking it to a test machine that does not have DNAStar Lasergene installed and install it. The end result should be that Lasergene installs with the correct permissions.

One challenge that can crop up for Mac admins is the problem of running a script or other tool with root privileges and using it to launch and run another tool, script or application as if the logged-in user had launched it. An example of this would be installing Dropbox using an installer package, then launching the Dropbox application as the logged-in user as a post-installation task. One reason to do so would be to give the user the opportunity to sign into their Dropbox account.

To accomplish this task, Apple has provided functionality in the launchctl tool.

For 10.9.x and earlier, launchctl‘s bsexec function was used for this purpose. bsexec allows you to start a process like a tool, script or application in a specific context. One way to get the correct context for the logged-in user is to identify the process identifier (PID) for the loginwindow process associated with the logged-in user, which can be accomplished by using the command below:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep logged_in_username_here | grep -v "grep" | awk '{print $2}'

For example, if I logged in with an account named username, running the command shown below should provide the PID for the username account’s loginwindow process:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep username | grep -v "grep" | awk '{print $2}'

Once the PID has been identified, it can be used to identify the context that I want to start a process in. For example, the commands below can be run with root privileges to first identify the correct PID for the username account’s loginwindow process, then launch Safari as the username account using the open command:

ps auxww | grep "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" | grep logged_in_username_here | grep -v "grep" | awk '{print $2}'

launchctl bsexec PID_number_here open "/Applications/Safari.app"

When we check the process list for which account is was launched from, the Safari process should show up as being run by the username account.

If you wanted to automate opening Safari as the logged-in user, you could run a script like the one below with root privileges:

Starting in OS X Yosemite, Apple made a number of changes to the launchctl tool and added a new asuser function. The asuser function is designed to take the place of the bsexec function, in the context of starting processes in the context of a specific user account. This makes it easier, as you now just need to figure out the username and do not have to figure out the PID of the user’s loginwindow process.

You can identify the user by either the user’s account name, or by the account’s UID. One way to identify an account’s UID is to use the id command as shown below:

id -u username_goes_here

To continue with the example of opening Safari, you can run the commands below to first identify the correct UID, then launch Safari as the username account using the open command:

id -u username_goes_here

launchctl asuser username_uid_goes_here open "/Applications/Safari.app"

If you wanted to automate opening Safari using the logged-in user’s UID, you could run a script like the one below with root privileges:

As mentioned earlier, you can also use just the account name with launchctl‘s asuser function. In that case, you can run the command below to launch Safari as the username account using the open command:

launchctl asuser username_goes_here open "/Applications/Safari.app"

If you wanted to automate opening Safari using the logged-in user’s account name, you could run a script like the one below with root privileges:

As part of making sure that XProtect and Gatekeeper are providing up-to-date protection, it can be worthwhile to see when your Mac received the latest updates from Apple for both XProtect and Gatekeeper. As both are background processes, as well as also receiving Config Data updates silently in the background, it’s not always obvious when updates have been applied.

To assist with this, I’ve written a couple of scripts to report the last time that Gatekeeper and XProtect have been updated on a particular Mac. For more details, see below the jump.

XProtect

To check XProtect’s update status, I’ve written the script below. Based on the OS version of the Mac in question, it will take the following actions:

• Macs running 10.5.8 and earlier – The script will display a message stating “XProtect not available for” followed up by the OS version number
• Macs running 10.6.x through 10.8.x – The script will check XProtect’s /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/XProtect.meta.plist file for the file’s last-modified date, then report the date in a human-readable date format.
• Macs running 10.9.x and later – The script will check the installer package receipts for XProtect update installer packages for the relevant version of Mac OS X, then report the installation date of the most recent update in a human-readable date format.

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

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

A Casper Extension Attribute is also available on GitHub at the following address:

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

Gatekeeper

To check Gatekeeper’s update status, I’ve written the script below. Based on the OS version of the Mac in question, it will take the following actions:

• Macs running 10.7.4 and earlier – The script will display a message stating “Gatekeeper not available for” followed up by the OS version number.
• Macs running 10.7.5 – The script will display a message stating “Gatekeeper update status not available for” followed up by the OS version number.
• Macs running 10.8.x and later – The script will check the installer package receipts for Gatekeeper update installer packages for the relevant version of Mac OS X, then report the installation date of the most recent update in a human-readable date format.

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

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

A Casper Extension Attribute is also available on GitHub at the following address:

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

As part of the release of DeployStudio 1.7.3, DeployStudio is now using an unsigned configuration profile to manage binding to an Active Directory domain for Macs running OS X 10.11.x.

This undocumented change currently appears to apply only to Macs running OS X El Capitan. Earlier versions of OS X are still being bound to AD using Apple’s dsconfigad tool. For more details, see below the jump.

The relevant changes are available via the links below:

DeployStudio AD binding script for OS X 10.11.x: https://github.com/timsutton/DeployStudioDiffs/blob/9c0f3a9366995f6371f79c76c10637397d5d1c92/Packages/Admin/DeployStudio%20Admin.app/Contents/Plugins/DSADBindingTask.bundle/Contents/Resources/Scripts/ds_active_directory_binding/ds_active_directory_binding.10.11.sh

Configuration profile header: https://github.com/timsutton/DeployStudioDiffs/blob/9c0f3a9366995f6371f79c76c10637397d5d1c92/Packages/Admin/DeployStudio%20Admin.app/Contents/Plugins/DSADBindingTask.bundle/Contents/Resources/Templates/ConfigurationProfileHeader.plist

Default configuration profile options: https://github.com/timsutton/DeployStudioDiffs/blob/9c0f3a9366995f6371f79c76c10637397d5d1c92/Packages/Admin/DeployStudio%20Admin.app/Contents/Plugins/DSADBindingTask.bundle/Contents/Resources/Templates/PayloadContent.plist

Based on observation, it appears that the configuration profile is assembled from the ConfigurationProfileHeader.plist and PayloadContent.plist files referenced in the above links, then named ds_active_directory_binding_uuid_goes_here.mobileconfig, with the UUID included in the filename to ensure that the profile’s filename is unique.

One thing to be aware of is that the .mobileconfig files generated by DeployStudio 1.7.3 do not appear to set all options for the Apple Active Directory plug-in correctly. I’ve posted about the issue in the DeployStudio forums and also notified the DeployStudio folks via Twitter:

To see what a DeployStudio 1.7.3-generated AD configuration profile looks like, please see the example below:

Hat tip to @tvsutton for discovering this change.

Following the release of DeployStudio 1.7.3, I discovered and reported a problem with the Active Directory binding to the DeployStudio folks.

To address the issue, they released a new version of DeployStudio but didn’t change the version number from 1.7.3. Instead, the new DeployStudio 1.7.3 has a different build number:

• DeployStudio 1.7.3 build 160401 – released April 1st, 2016
• DeployStudio 1.7.3 build 160404 – released April 4th, 2016

If you have already installed DeployStudio 1.7.3, I recommend checking to see which build you have installed. If needed, upgrade both your DeployStudio server and DeployStudio boot sets to DeployStudio 1.7.3 build 160404.

For more details on identifying the different builds of DeployStudio 1.7.3, see below the jump.

In my research, I found three places where you can find the build number:

1. Running the following command on the DeployStudio server:

/usr/bin/defaults read "/Applications/Utilities/DeployStudio Admin.app/Contents/Info" CFBundleVersion

If you have DeployStudio 1.7.3 build 160401, the following string will be returned:

160401

If you have DeployStudio 1.7.3 build 160404, the following string will be returned:

160404

2. The build number is also listed in the DeployStudio installer metapackage’s Important Information window:

3. The other place you can find the build number is in the DeployStudio preference pane:

What changed between build 160401 and build 160404?

When DeployStudio 1.7.3 build 160401 was released, I and others tested it and discovered a couple of things:

1. On OS X 10.11.x, DeployStudio is now using a configuration profile for Active Directory binding.
2. The Active Directory binding worked but not all options were being set properly. Specifically, the Active Directory plug-in’s Use UNC path from Active Directory to derive network home location setting was not being disabled when it should have been.

When alerted to the issue, the DeployStudio folks released DeployStudio 1.7.3 build 160404. This fixed the issue by correctly setting a particular value in the DeployStudio-generated configuration profile.

With the correct value now being set by the configuration profile, the Use UNC path from Active Directory to derive network home location setting is now properly handled.

For those interested in the configuration profile itself, I have an example linked below:

On OS X 10.9.0 – 10.11.x, you can run the following command to verify if a FileVault 2-encrypted Mac is using an institutional recovery key (IRK) as a valid recovery key.

fdesetup hasinstitutionalrecoverykey

If FileVault 2 is using an IRK, this command will return true.

Otherwise it will return false.

As part of the release of OS X 10.11.2, a new function was added to fdesetup‘s hasinstitutionalrecoverykey verb. Now, in addition to identifying whether or not FileVault 2 on a particular Mac has an institutional recovery key, a new -device option has been added which outputs a SHA-1 hash in hexadecimal notation of the IRK’s public key. This helps Mac admins answer two questions about institutional recovery keys:

1. Is an IRK being used as a valid recovery key on this Mac?
2. If an IRK is in use, which one is being used?

The -device option needs to be supplied with an identifier for the encrypted drive in question. This can be in the form of a BSD device name ( /dev/diskX ), the mount path ( /Volumes/Macintosh HD or / ), or a UUID for the Logical Volume or Logical Volume Family of a CoreStorage volume.

To display the hash for an IRK’s public key on the Mac’s boot volume, run the command below with root privileges:

fdesetup hasinstitutionalrecoverykey -device /

It should output the hash of the IRK’s public key in hexadecimal notation.

This value should be consistent across all FileVault 2-encrypted Macs which are using this IRK, so it should help Mac admins identify if a particular Mac is set up with the correct FileVault 2 institutional recovery key (or keys) used by their shop.

To assist with this, I’ve written a script to report the hash of the IRK’s public key. For more details, see below the jump.

The script is designed to check the OS on a particular Mac and verify that it’s running 10.11.2 or later. If the Mac is running an earlier OS, the script reports the following:

Not Available – Unable To Export IRK Public Key Hash On, followed by the OS version.

If the script verifies that it is running on 10.11.2 or later, the script continues on to see if the Mac is encrypted and if it is using an IRK as a valid recovery key.

If the Mac is not encrypted, the script reports the following:

Not Available – Encryption Not Enabled

If the Mac is encrypted but is not using an IRK, the script reports the following:

Not Available – Valid IRK Not Found

If the Mac is encrypted and an IRK is in use as a valid recovery key on the Mac’s boot volume, the script reports the hash of the IRK’s public key in hexadecimal notation.

The script is available on GitHub at the following address:

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

A Casper Extension Attribute is also available on GitHub at the following address:

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

I recently learned that there’s a way to display all the various verbs which can be used with the Casper agent’s jamf binary in one list, including the verbs which are normally hidden from view. For more details, see below the jump.

To access this documentation, go to a Mac which has Casper’s agent installed and run the following command with root privileges:

jamf help -all

You can also run this command without root privileges. In that case, the verbs included with the hidden documentation will not appear in the list.

One of the challenges Casper admins can run into is performance tuning, which can require going into parts of the JSS that you normally go into only when JAMF Support asks you to do so. To help with this process, there are formulas which you can use to calculate if your JSS’s Tomcat and MySQL services are configured for best performance.

Before proceeding further, I want to emphasize that a) check with JAMF Support first and b) you should always, always, always make backups of your JSS before changing settings. I assume no responsibility and bear no culpability if your JSS breaks as a result of anything you implement as a result of reading this post. I am also not responsible for incorrect math, ruining anyone’s weekend, or that long talk you now need to have with your boss about why your JSS is now broken.

One other thing to be aware of is that I’m going to be focusing on Linux and Windows in this post since those are the platforms that I’m most familiar with for hosting a Casper 9 JSS.

For more details, see below the jump:

There are three sets of settings that can be adjusted to improve (or degrade) the performance of your JSS:

max_connections – located in MySQL’s my.cnf config file
maxThreads – located in /path/to/tomcat_directory/conf/server.xml
MaxPoolSize – located in /path/to/tomcat_directory/webapps/ROOT/WEB-INF/xml/DataBase.xml

The formula for calculating the optimum max_connections setting in MySQL’s my.cnf configuration file is shown below:

max_connections=(n X p)+1

This formula sets n to equal the number of webapps (i.e. JSSs) you have connecting to the MySQL database and p equals the value of MaxPoolSize. The reason for the +1 in the formula is to make sure that, no matter how many connections your JSS is making, you have at least one unused and open connection to communicate with your MySQL database.

The value of MaxPoolSize is set by default to 90 in the JSS, so most JSSs should be able to use this formula:

max_connections=(n X 90)+1

The value of MaxPoolSize also affects the maxThreads value. The value of maxThreads defines the maximum number of request processing threads to be created, which therefore determines the maximum number of simultaneous requests that can be handled. The formula for calculating the optimum maxThreads setting in Tomcat’s server.xml configuration file is shown below:

maxThreads=($MaxPoolSizeNumber X 2.5)W

This formula sets W to equal the number of webapps (i.e. JSSs) you have running in Tomcat.

As mentioned previously, the value of MaxPoolSize is set by default to 90 in the JSS, so most JSSs should be able to use this formula:

maxThreads=(90 X 2.5)W

The other thing you can do to affect performance is that you can adjust how much memory is being allocated to Java, which in turn increases how much memory the JSS’s Tomcat webapp is able to use (since both Tomcat and the JSS webapp are Java applications.) If you’ve been installing and/or updating your Casper server using JAMF’s installer, I strongly recommend using the JSS Database Utility for adjusting Tomcat’s memory settings. You can access those settings via the following process:

1. Launch the JSS Database Utility
2. Click on the Utilities menu and select Change Tomcat Settings…

3. Adjust as needed
4. When finished, click the Apply Settings button

5. Restart Tomcat

Note: You can also adjust MySQL’s max_connections settings via the JSS Database Utility by selecting Change MySQL Settings…. and adjusting the Max Database Connections value.

If you installed your JSS using the manual installation process, you may not be able to use the JSS Database Utility for adjusting the Java settings. Instead, you’ll need to set the needed values via alternate means. See below for a description of the attributes used to set Java’s memory values:

• -Xms: Indicates the minimal heap size for memory used by Java (i.e. what’s the minimum amount of memory that Java can use.)
• -Xmx: Indicates the maximum heap size for memory used by Java (i.e. what’s the maximum amount of memory that Java can use.)
• -XX:MaxPermSize: Indicates the maximum memory used for PermGen.
• -Djava.awt.headless: Configures Java to run in headless mode for systems that don’t have displays, keyboards or mice
• -server: Instructs the launcher of the Java application to use the Java HotSpot Server VM.

On Windows, you can set Tomcat’s memory on Windows using the Tomcat7w.exe application located in C:\path\to\tomcat_directory\bin. Once you have it open, click on the Java tab and set the memory options there.

On Linux, you set the memory options with a shell script named setenv.sh which is stored in /path/to/tomcat_directory/bin. Here’s an example of what this script can look like:

#!/bin/sh

export CATALINA_OPTS="-Xms128m -Xmx256m -XX:MaxPermSize=128m -Djava.awt.headless=true -server"

As you can see from the information above, there’s a lot that can go into performance tuning for a Casper JSS. JAMF has tried to set default settings that make sense for most environments, but settings that may have made sense at the initial JumpStart may now need adjustment as the number of Macs managed by your Casper server has grown.

Since different operating systems store MySQL and Tomcat in different places, please see below for a listing of where Tomcat and MySQL (along with their various configuration files) are installed.

MySQL

Here’s where MySQL and its files is located for Windows, Ubuntu and Red Hat Enterprise Linux. My working assumption for these paths is that MySQL Server 5.6 is installed:

Ubuntu:

MySQL – /var/lib/mysql
MySQL configuration file – /etc/mysql/my.cnf

Red Hat Enterprise Linux:

MySQL – /usr/bin/mysql
MySQL configuration file – /etc/my.cnf

Windows:

MySQL – C:\Program Files\MySQL\MySQL Server 5.6
MySQL configuration file – C:\ProgramData\MySQL\MySQL Server 5.6\my.ini

Tomcat and the JSS webapp

If you’re installing and/or updating your JSS using JAMF’s installer for the JSS, here’s where it puts the Apache Tomcat files and JSS webapp files for Windows and Linux (both Red Hat Enterprise Linux and Ubuntu):

Windows JSS installer:

• JSS web application – C:\Program Files\JSS\Tomcat\webapps\ROOT\
• Apache Tomcat – C:\Program Files\JSS\
• JSS Tomcat’s server.xml configuration file – C:\Program Files\JSS\Tomcat\conf\server.xml
• JSS Tomcat’s Java keystore – C:\Program Files\JSS\Tomcat\certs\.keystore
• JSS JSS Database Utility – C:\Program Files\JSS\bin\JSSDatabaseUtil.jar
• JSS Database backup location – C:\Program Files\JSS\Backups\Database\
• JSS Logs – C:\Program Files\JSS\Logs\

Linux JSS Installer (for Red Hat Enterprise Linux and Ubuntu):

• JSS web application – /usr/local/jss/tomcat/webapps/ROOT/
• Apache Tomcat – /usr/local/jss/
• JSS Linux service startup script – /etc/init.d/jamf.tomcat7
• JSS Tomcat’s server.xml configuration file – /usr/local/jss/tomcat/conf/server.xml
• JSS Tomcat’s Java keystore – /usr/local/jss/tomcat/.keystore
• JSS JSS Database Utility – /usr/local/jss/bin/JSSDatabaseUtil.jar
• JSS Database backup location – /usr/local/jss/backups/database/
• JSS Logs – /usr/local/jss/logs/

If you’re installing or updating your JSS using the manual install process, Tomcat needs to be installed separately. Here’s where Tomcat is located for Windows, Ubuntu and Red Hat Enterprise Linux. My working assumption for these paths is that Tomcat 7 is installed:

Windows:

• Apache Tomcat – C:\Program Files\Apache Software Foundation\Tomcat 7.0
• Apache Tomcat’s server.xml configuration file – C:\Program Files\Apache Software Foundation\Tomcat 7.0\conf\server.xml
• JSS web application – C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\ROOT

Red Hat Enterprise Linux:

• Apache Tomcat – /usr/share/tomcat7
• Apache Tomcat’s server.xml configuration file – /usr/share/tomcat7/conf/server.xml
• JSS web application – /usr/share/tomcat7/webapps/ROOT

Ubuntu:

• Apache Tomcat – /var/lib/tomcat7
• Apache Tomcat’s server.xml configuration file – /var/lib/tomcat7/conf/server.xml
• JSS web application – /var/lib/tomcat7/webapps/ROOT

When troubleshooting, you’ll usually need to check the logs. If you installed using the manual process and properly configured where the logs should be going, here’s where they’re stored for Windows, Ubuntu and Red Hat Enterprise Linux:

Windows:

• C:\Program Files\Apache Software Foundation\Tomcat 7\logs\Catalina.date_goes_here.log
• C:\Program Files\Apache Software Foundation\Tomcat 7\logs\JAMFSoftwareServer.log
• C:\Program Files\Apache Software Foundation\Tomcat 7\logs\JAMFChangeManagement.log

Red Hat Enterprise Linux and Ubuntu:

• /var/log/tomcat7/Catalina.date_goes_here.log
• /var/log/tomcat7/JAMFSoftwareServer.log
• /var/log/tomcat7/JAMFChangeManagement.log

Note: You can set the location for the JAMFSoftwareServer.log and JAMFChangeManagement.log logfiles in /path/to/tomcat_directory/webapps/ROOT/WEB-INF/classes/log4j.properties.

For the directory paths in Tomcat’s log4js.properties file, you can use ” / “ for both Windows and Unix-based systems. If you want to use Windows’ ” \ ” for paths, you have to use them in pairs (the first  ” \ ” is for escaping the slash.) Both of the following approaches shown below would work fine:

log4j.appender.LOGFILE.File=C:/path/to/jss.log

log4j.appender.LOGFILE.File=C:\\path\\to\\jss.log

Starting in OS X Yosemite, Apple introduced a new option to log into your Mac using the password associated with an Apple ID. As of OS X 10.11.4, this option seems to have been removed from the Users & Groups preference pane in System Preferences.

OS X 10.11.3:

OS X 10.11.4:

Apple’s KBase article describing how to set up users on OS X El Capitan was last updated on April 13, 2016. It does not include any information on using an iCloud password for a new user account.

This option still appears to be available on OS X 10.11.4 via Apple’s Setup Assistant. If you’re setting up a Mac for the first time and sign into iCloud as part of the setup process, you will be given the option of using your iCloud account to log in.

Apple officially announced on Wednesday, April 6th that the FIPS 140-2 validations for the cryptographic modules used by iOS 9 and OS X 10.11.x have now been completed. This is significant news for folks who want to use FileVault 2 in government and regulated industries (such as financial and health-care institutions.)

For folks who haven’t heard of it before, FIPS 140-2 is an information technology security accreditation program run jointly by the US and Canadian governments. This program is used by private sector vendors to have their cryptographic modules certified for use in US and Canadian government departments and private industries with regulatory requirements for security.

As part of the announcement, Apple has released KBase articles and guidance for security offices who deal with encryption:

Apple FIPS Cryptographic Modules v6.0 for OS X El Capitan v10.11 – https://support.apple.com/HT205748

Crypto Officer Role Guide for FIPS 140-2 Compliance OS X El Capitan v10.11 – https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT205748/APPLEFIPS_GUIDE_CO_OSX10.11.pdf

According to Apple, the OS X El Capitan Cryptographic Modules, Apple OS X CoreCrypto Module v6.0 and Apple OS X CoreCrypto Kernel Module v6.0, require no setup or configuration to be in “FIPS Mode” for FIPS 140-2 compliance on devices running OS X El Capitan 10.11.x.

FileVault 2 is listed as being FIPS 140-2 Compliant as part of the Crypto Officer Role Guide for FIPS 140-2 Compliance OS X El Capitan v10.11 documentation, in the Compliant Applications and Services section.

For more information about the validation certification, please see below the jump.

iOS 9

Module Name: Apple iOS CoreCrypto Module, v6.0
Certificate #2594: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2594
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2594.pdf

Module Name: Apple iOS CoreCrypto Kernel Module, v6.0
Certificate #2609: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2609
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2609.pdf

OS X El Capitan v10.11

Module Name: Apple OS X CoreCrypto Module, v6.0
Certificate #2610: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2610
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2610.pdf

Module Name: Apple OS X CoreCrypto Kernel Module, v6.0
Certificate #2597: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2016.htm#2597
Security Policy: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2597.pdf

A few years ago, I set up my Casper server with an Apple Push Notification Service (APNS) certificate. That by itself is not remarkable, but the way I did it would be frowned upon these days. That’s because I used an Apple ID tied to my work email address to generate it.

The reason that I did this was that back then, you needed to have a paid membership in the Apple iOS Developer Program in order to get an APNS certificate. I was not part of an enterprise team, so the Apple ID I was using to log into my ADC account was tied to my own work email address. Consequently, I generated my initial APNS certificate for my Casper server using an Apple ID tied to my work email address.

Fast forward to 2016 and the world of the Apple Push Certificates Portal, where it’s no longer necessary to have an Apple Developer Connection account to have an APNS certificate. In fact, it’s not a great idea at all because people come and go, but hopefully the Apple ID used to generate your APNS certificate (also known as an MDM certificate or push notification certificate) does not. That’s because you can’t transfer an Apple ID to another email address and only the Apple ID used to generate your initial APNS certificate can generate the new certificate needed for the annual APNS certificate renewal.

For iOS devices, where everything is managed via MDM, changing the Apple ID used to generate your APNS certificate means that you are going to have to re-enroll all of your devices. This is usually a sizable effort and one that should be avoided if at all possible.

For OS X devices, where MDM-only management is still fairly rare, changing Apple IDs (and APNS certificates) is less problematic. You will also need to re-enroll your devices but it should be possible to use alternate means to remove your old MDM profile(s) and make the Mac pull down a new set of MDM management profiles that would incorporate the new APNS certificate for the Mac’s push notifications.

Fortunately, I’m in the situation of having to change out my Apple ID and APNS certificate only on OS X devices. These devices are also managed by my Casper server, so I can automate a fix for the issue using a script like the one below:

However, I still had one issue – identifying which machines had the “old” MDM profiles associated with the APNS certificate which I was trying to move away from. For details on how this was addressed, see below the jump.

APNS certificates have a unique identifier and Casper’s MDM management profiles include this unique identifier in the Topic field of the MDM profile.

The issue was finding a way to pull out this unique identifier from the profile. Apple’s profiles command did not appear to include a way to display this information without outputting to a plist file and then searching the plist file for the needed information. This was not my preferred method because it depended on the output of the plist being consistent and I wasn’t confident in that being the case across different versions of OS X.

After conferring with my colleagues in the #jamfnation channel of the MacAdmins Slack instance, the hive mind figured out a way to use system_profiler to pull out the needed identifier by running the the command below with root privileges:

/usr/sbin/system_profiler SPConfigurationProfileDataType | awk '/Topic/{ print $NF }' | sed 's/[";]//g'

Note: Something to be aware of is that using the system_profiler command can be computationally expensive. Depending on how many MDM profiles you have installed on the machine, it may take a few seconds or longer for the command to run. One of the folks on Slack had 64 MDM profiles on his Mac and the command took about 11 seconds to run.

Using this information, I wrote a script to locate and display the Apple Push Notification Service certificate identifier on OS X. This helps me with the task of changing my MDM certificate by clearly identifying which machines still have MDM profiles associated with the APNS certificate that I’m planning to retire.

The script is available on GitHub at the following address:

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

A Casper Extension Attribute is also available on GitHub at the following address:

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

Hat tip to Dan Brodjieski, Ben Toms,  and Balmes Pavlov.

As mentioned previously, I needed to migrate my Casper server from using the Apple Push Notification Service (APNS) certificate generated by one Apple ID to now using another APNS certificate generated by another Apple ID.

This project is fairly straightforward, thanks to a couple of factors:

1. The Casper server in question is managing only OS X devices.
2. I have a way to identify via a Casper Extension Attribute which Macs have MDM profiles associated with the APNS certificate which is no longer active.

I was able to set up a Casper smart group to look for machines that fit the following criteria:

• Criteria: Extension Attribute name (In this case, the EA is named Apple Push Notification Service certificate identifier.)
• Operator: Like
• Value: com.apple.mgmt.External.uuid_of_former_apns_certificate_goes_here

From there, I set up a policy that is scoped to run on the members of that smart group. For more details, see below the jump.

The policy I set up runs the script shown below to perform the following tasks:

1. Remove the existing MDM profiles
2. Download and install a fresh set of MDM profiles (this new set of profiles will use the new APNS certificate.)
3. Run a recon to update inventory.

The inventory update should then take the machine out of the smart group.

Here’s how the policy I set up looks in Casper 9.x:

• Frequency: Ongoing
• Trigger: Check-In
• Actions:
• Run script
• Update Inventory

The script looks like this in Casper:

As part of rolling out Office 2016 for my shop, I noticed that Office 2011’s Microsoft Document Connection application was no longer included with Office. A number of folks in my shop had been using this application to access documents on our Sharepoint servers, so its absence meant I needed to learn how to access Sharepoint sites using Office 2016.

After some research and discussion with colleagues, I was able to figure out how to connect to Sharepoint from within Office 2016 applications. For more details, see below the jump.

You can add Sharepoint sites to Office 2016 applications, with access to the sites showing up inside the Open and Save dialog windows. Word 2016 will be used in this example.

1. In an Open window, click the + button.

Note: You may need to click the Online Locations button before getting access to the + button.

2. In the Add a Service window, click SharePoint

3. In the Add a SharePoint Site window, enter the address of the Sharepoint site you want to access into the URL blank:

https://server.name.here

4. Once the address has been filled in, click the Next button.

5. Enter your username and passphrase in the User name: and Password blanks.

6. Once entered, click the Sign In button.

7. The SharePoint site will appear and be available under the SharePoint section of Office 2016 applications’ Open or Save windows.

I’ll be speaking about virtualization, with a focus on VMware solutions, at MacSysAdmin 2016, which is being held from October 4th – 7th, 2016 in Göteborg, Sweden. For those interested, my talk will be on Thursday, October 6th.

For a description of what I’ll be talking about, please see the Thursday program page.

When working with AppleScripts that other folks have written, it’s often useful to be able to look at the source of the AppleScript. One quick way to do this via the command line is to use the osadecompile command. This command is designed to output the source of a compiled AppleScript or other OSA language scripts to standard output. For more details, see below the jump.

As an example of this, let’s look at an AppleScript which has been compiled into an AppleScript application. The application has the following source code and is designed to produce a dialog box reading Hello World.

The AppleScript in this case is named Hello World.app and it’s been saved into ~/Documents:

To read out the source code for the AppleScript application without opening a script editor, you can run the following command:

osadecompile /Users/username/Documents/Hello\ World.app

osadecompile will then display the source for the AppleScript application.

One thing to be aware of is that osadecompile is not able to display source for a read-only AppleScript script or application.

This is because a read-only AppleScript has had its source code stripped as part of the compiling process. With the source code removed, it cannot later be decompiled by either the Script Editor application or osadecompile.

In this case, osadecompile will display an error similar to the one shown below.

As part of providing support for the Macs in my shop, I build and use utility disks which contain useful utilities like DiskWarrior and Carbon Copy Cloner. My shop’s network supports NetBoot across subnets, so I also build NetBoot sets from the utility disks. The reasons I do this are the following:

1. Having a utility disk available via NetBoot means I always have access to a utility disk when needed.
2. The other members of my team also have access to the same utility disk when they need it.
3. Nobody needs to carry around external drives with the utility software.
4. Updates to the utility disk can be made in a centralized fashion.

For details on how I’m building NetBoot sets from utility disks, please see below the jump.

Pre-requisites:

• System Image Utility
• An already-built utility drive available on a hard drive with at least 30 GBs of free space.
• A separate boot volume which is running the same OS version as the utility drive
• Available local disk space to store the new NetBoot utility drive on during the creation process

Adding extra drive space for the NetBoot set:

To help make sure that there is available space on the NetBoot disk for copying files and for OS X’s memory swap, I prefer to add a large empty disk image to the utility drive which is acting as the template. This large empty disk image is included in the NetBoot disk as part of the creation process, then removed later and deleted.

The reason to do this is that otherwise the NetBoot disk will be created with only one or two gigabytes of available free space. Please see below for the procedure I’m using:

1. Open Disk Utility

2. Select the option to create a new blank disk image

3. Set the size as desired (I normally set it to 30 GBs.)

4. Save to a convenient location on the utility drive

Creating the NetBoot set:

1. On the boot volume, launch System Image Utility

2. Select the utility drive and click the Next button.

3. Set the network disk image type as NetBoot Image then click the Next button.

4. Click the Agree button in the Software License Agreement window.

5. In the Add Configuration Profiles, Packages and Post-Install Scripts window, make no changes and click the Next button.

6. In the System Configuration window, make no changes then click the Next button.

7. In the Directory Servers window, make no changes and click the Next button.

8. In the Image Settings window, enter the Network Disk: and Description: settings as desired and also enable the following settings:

Select how you want to assign an image number. You can assign a random number, which generates a value from 1 – 4096 or you can manually assign a number. If you choose to have the image served from multiple NetInstall servers, the number generated will be from 4097 – 65535.

I use the following settings when creating NetBoot utility disks:

• Assign a random image index
• Image will be served from multiple servers

Once all settings have been set, click the Next button.

9. In the Supported Computer Models window, make no changes and click the Next button.

10. In the Filter Clients by MAC address window, make no changes and click the Next button.

11. When prompted, enter a desired name for the NetBoot set and save where convenient.

12. When prompted, authorize creation of the NetBoot set by entering an administrator’s username and password.

13. The NetBoot set will be created and saved.

14. When the process has completed, click the Done button.

Removing blank disk image from the NetBoot set:

To make sure the NetBoot set has sufficient free space, the blank disk image now needs to be removed. Please see below for the procedure I’m using:

1. Disconnect the utility drive.

Note: The reason for this step is that the NetBoot drive will have the same drive name and disconnecting the utility drive will help avoid confusion.

2. Double-click on the NetBoot set’s NetBoot.dmg file to mount the disk image.

3. Once mounted, navigate to where the blank disk image is stored and delete the disk image.

4. Unmount the disk image.

Compressing the NetBoot set:

To save space on the NetBoot server, my next step is to take the NetBoot set’s NetBoot.dmg file and convert it from a read/write disk image to a read-only compressed disk image. This conversion will shrink the size of the NetBoot.dmg file, but will not reduce the available free space of the NetBoot disk when it’s being used to boot over the network.

1. Move the NetBoot set’s NetBoot.dmg file outside of the NetBoot set folder.

2. Convert the disk image to Compressed format and save the compressed image into the NetBoot set folder.

Once the NetBoot set’s NetBoot.dmg file has been converted to a read-only compressed disk image, it is ready to be posted to the NetBoot server.

Enabling the NetBoot set for use:

1. Copy the NetBoot set to your NetBoot server

2. Add it to where you host NetBoot sets (this will likely be /Library/NetBoot/NetBootSP0, but you may have NetBoot sets stored on an alternate drive.)

3. Open Server.app and select NetInstall

4. Select the NetBoot set, then click the gear icon.

5. In the gear icon’s menu, select Edit Image Settings…

6. In the settings window, select the following:

• Make available over NFS
• Make this image available for diskless booting

When the settings have been set, click the OK button.

Testing the NetBoot set:

Boot a couple of Macs from the new NetBoot set to verify that it is working properly.

One of the challenges Mac admins have to deal with are Mac application installers which don’t follow one of the following models:

• Drag-and-drop installation
• Package installation

In many cases, these alternate installers take the form of applications which may or may not have options for installing via command line. For those that do not have the option of command line installation, the only real option is to install the application in question, then re-package it as either a drag-and-drop install or an installer package.

However, for those installer applications that do support command line installation, this opens up the option of embedding the installer application inside an installer package and using a postinstall script to run the necessary commands for the installer application to install its files onto the Mac. I’ve used this workflow several times in the past, with some examples linked below:

• Creating a DNAStar Lasergene 13.x installer
• Revisiting Sophos Enterprise Anti-Virus for Mac 9.2.x deployment
• Deploying Sophos Anti-Virus Home Edition for Mac 9.2.x for personal use

These examples have been manually built by me on an as-needed basis as new versions are released, but wherever possible, I want to automate this process using AutoPkg. Thanks to being able to study a recently-built .pkg recipe for AccuBarcodePro created by @foigus, I was able to build recipes for AutoPkg which handle downloading and packaging the following installer applications:

• Sophos Anti-Virus Home Edition
• Adobe Creative Cloud Installer

For more details, see below the jump.

In the case of both the Sophos and Adobe installer workflows, the AutoPkg recipe model looks like this:

1. Download the installer application from the vendor.
2. As part of an AutoPkg .pkg recipe, create a Scripts directory that AutoPkg will later include as part of building an installer package
3. Copy the installer application into the Scripts directory
4. Add a postinstall script to run the needed commands for the installer application to the Scripts directory
5. Build an installer package which has the installer application and postinstall script embedded inside the package.

For the Creative Cloud Installer package recipe, copying the installer application involves using the Copier processor to copy the application from the downloaded Creative Cloud disk image and into place inside the Scripts directory.

Once the installer application is stored in the Scripts directory, the FileCreator processor is leveraged to create the needed postinstall script and likewise store it in the Scripts directory.

Once both the installer application and script are stored in the Scripts directory, the PkgCreator processor is called to create an installer package which includes setting the Scripts directory as the location from which the package calls preinstall and postinstall scripts.

The Sophos package recipe involves a similar method, with the exception of how the installer application gets into the Scripts directory. The Sophos download is a .zip file, so the Unarchiver processor is leveraged to extract the contents of the zip file directly into the Scripts directory. The Sophos download includes both an installer application and a separate associated directory containing the installation files, so being able to extract directly into the Scripts directory means that both the installer application and associated directory are placed into the Scripts directory in one step.

An issue that I see occasionally on new Macs is that they’re set to use a language different than mine when I take them out of the box. In my case, the alternate language is most often set to French (for unknown reasons), rather than being set to US English like I’m expecting.

OS X normally handles this issue as part of the installation process, by asking which language is preferred and using that for the OS.

However, when I set up new machines, I’m past the point of selecting the language that way. Fortunately, there are alternate ways to change the language used at the login screen. For more details, see below the jump.

If there is just one user account on the Mac, you may be able to change the language globally using the Language & Region preference pane in System Preferences:

1. Log into the Mac
2. Open System Preferences
3. Select Language & Region or its equivalent in the Mac’s current language.

Note: The relevant icon displays the United Nations flag

4. Set the Region you want

5. After the Region information is set, click on the plus ( + ) button.

6. Select the language you want to use.

7. When it asks if you want to use the new language as the principal language, select the button that says to use the new language.

8. The new language should now appear marked as the principal language.

9. If desired, select the old language and click the minus ( – ) button to delete it.

10. When you close the preference pane, you’ll be prompted to restart to set the new primary language.

11. After the Mac restarts, the login screen should now use the language you set.

The Language & Region preference pane should also now show the new language and Region settings in the desired language.

If there is more than one user, or if you just want to change the login window’s language, there’s an alternate tool to use:

1. Log into the Mac
2. Open Terminal
3. Run the following command with root privileges:

languagesetup

4. A list of languages will be displayed.

5. Type the number that appears next to the language you want to use. Once entered, press Return on your keyboard.

6. Exit out of Terminal
7. Restart your Mac
8. After the Mac restarts, the login screen should now use the language you set.

For more information about this, please see the Apple KBase article linked below:

https://support.apple.com/HT202036

As part of making sure my customers have the latest version of their applications available, I use AutoPkg, JSSImporter, and AutoPkgr to ensure that as new software updates are released, they are automatically uploaded to my shop’s Casper server.

As part of this process, some applications need to be converted by AutoPkg from using the drag-and-drop installation method provided by the vendor to now being installed using an installer package.

In the case of certain applications, the process of packaging can change an application which is fine when installed via a drag-and-drop installation method to one which is broken when installed via an installer package. This is due to Apple’s pkgbuild tool erroneously stripping certain metadata used by the application’s code signing. If an application is set to check for that metadata as part of its code signature verification process, this can result in the application reporting that it’s been damaged and not launching.

An example of this which I’ve run across is Labtiva’s Papers.app, a reference library application designed to collect, organize and enable citation of scientific journal articles and other reference materials. The Papers.app installation method provided by Labtiva is a drag-and-drop install, where the customer is supposed to copy the application from a disk image and into a convenient location (like /Applications.)

When the application is installed by copying it into place, there are no problems with the application and it launches normally.

When Papers.app is packaged, then installed via an installer package, an error message will appear at first launch to report that the application is damaged.

Why the difference? In the case of Papers.app, the verification of the application’s code signing appears to include verification of certain metadata which pkgbuild appears to remove as part of the packaging process. For more details, see below the jump.

The removal of the code signing metadata can be checked using RB App Checker Lite, an application designed to help developers check code signatures and receipts for OS X applications. Using RB App Checker Lite, we can compare the code signing from Papers.app which has been installed via a drag-and-drop install vs. Papers.app which has been installed using a pkgbuild-generated installer package.

Drag-and-drop

Installer package

When checked, the package-installed Papers.app shows that the code signing has been removed from a particular file:

• Papers.app/Contents/Frameworks/libtriggersync-OSX.a

In this case, the metadata which has been stripped is associated with three different code signing attributes:

• com.apple.cs.CodeDirectory
• com.apple.cs.CodeRequirements
• com.apple.cs.CodeSignature

After additional investigation with the xattr tool, it looks like some metadata is missing from two additional files as well:

• Papers.app/Contents/Frameworks/libjpeg.a
• Papers.app/Contents/Frameworks/libtiff.a

Now that it’s known which metadata is missing, the question now is how to put it back? Fortunately, the xattr tool provides the following:

• A way to export the metadata from an existing known-good instance of the code-signed file
• A way to write the exported metadata to a file which is missing it.

Exporting the metadata:

The xattr tool includes two options which assist in exporting the metadata. The -p option tells xattr to display the metadata for a particular code signing attribute and the -x option forces the attribute value to be displayed in hexadecimal format. To export specific extended attribute metadata for a code signature, you can run the command shown below:

xattr -px com.apple.cs.code_attribute_here /path/to/file

To display the com.apple.cs.CodeSignature metadata for Papers.app/Contents/Frameworks/libtriggersync-OSX.a in hexadecimal format, run the following command:

xattr -px com.apple.cs.CodeSignature /path/to/Papers.app/Contents/Frameworks/libtriggersync-OSX.a

That will produce a long string of hexadecimal format. To use stdout to export the data into a text file, run the following command:

xattr -px com.apple.cs.CodeSignature /path/to/Papers.app/Contents/Frameworks/libtriggersync-OSX.a > /path/to/filename_here.txt

The output stored in the text file will appear similar to this:

To prepare it for the next step, writing the metadata back, the line breaks need to be removed from the exported metadata. That will result in a long one-liner of data that appears similar to this:

Writing the exported metadata back to a file:

To write the metadata to a file which is missing it, the xattr tool includes two options which assist in the writing of the metadata. The -w option enables the provided data to be written as the value of the specified code signing attribute and the -x option specifies in this case that the provided data will be written in hexadecimal format. To write the metadata to a file which is missing it, you can run the command shown below:

xattr -wx com.apple.cs.code_attribute_here metadata_goes_here /path/to/file

To see how this is being applied to the com.apple.cs.CodeDirectory attribute of /path/to/Papers.app/Contents/Frameworks/libtriggersync-OSX.a, please see the link below:

https://github.com/autopkg/homebysix-recipes/blob/master/Papers/Scripts/postinstall#L22-L24

Writing this information back fixes the issue with the code signing, which in turn allows Papers.app to launch and run normally after being installed by an installer package.

To help automate this process for AutoPkg, Elliot Jordan added a postinstall script to his Papers .pkg recipe. Papers.app installer packages generated by this AutoPkg recipe will automatically fix the code-signing problem introduced by pkgbuild, by writing the correct metadata back to the necessary files as a post-installation action.

Hat tip to Elliot Jordan for both diagnosing the problem with Papers and showing how to fix the problem.

This week, I’m out in San Francisco as an attendee of Apple’s WWDC 2016 conference. As part of this, I’m taking notes during the labs and sessions. Due to wanting to stay on the right side of Apple’s NDA, I’ve been posting my notes 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 with my notes. It’s available via the link below:

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