One of the practices that has historically helped Macs fit better into enterprise environments has been to bind Macs to Active Directory (AD) domains and use AD mobile accounts, using either Apple’s own AD directory service plug-in or a third-party product like Centrify. However, this practice has meant that the password for the mobile account is being controlled by a service located outside of the AD-bound Mac. This has led to problems in the following areas:

• Keychain password synchronization
• FileVault 2 login password synchronization

With the recent availability of tools like Apple’s Enterprise Connect and NoMAD, it’s now possible to provide the advantages of being connected to Active Directory to your Mac without actually having to bind your Mac to an AD domain. This has led to more environments not binding their Macs to AD and using either Enterprise Connect or NoMAD with local accounts.

With local accounts, all password management is done on the individual Mac. This means that problems with keychain and FileVault password synchronization are vastly reduced because the password change mechanism for a local account includes updating both the keychain and FileVault 2 automatically with the new authentication credentials.

For those shops that have been binding their Macs and using mobile accounts, but want to switch to the new local accounts + Enterprise Connect / NoMAD model, there is an account-related challenge to overcome:

How to transition from an AD mobile account, where the password is managed by AD, to a local account, where the password is managed by the individual Mac, with the least amount of disruption for your users?

To assist with this process, I’ve developed a script that can take an existing AD mobile account and migrate it to being a local account with the same username, password, UID, and GID. For more details, see below the jump.

The script I’ve developed is interactive and designed to convert an existing Active Directory mobile account to a local account. Because the existing account is being modified, instead of being deleted and replaced with a new local account, the following account characteristics do not change:

• Username
• Password
• UID
• GID

This provides the following advantages:

• The home folder does not need to be renamed
• Existing keychains and FileVault enablement continue to work
• Any applications, files and directories where the AD mobile account had access rights, the new local account will have those same access rights.

The script must be run with root privileges and uses the following process:

1. Detect if the Mac is bound to AD and offer to unbind the Mac from AD if desired
2. Display a list of the accounts with a UID greater than 1000
3. Once an account is selected, back up the password hash of the account from the AuthenticationAuthority attribute
4. Remove the following attributes from the specified account:

5. Recreate the AuthenticationAuthority attribute and restore the password hash of the account from backup
6. Restart the directory services process
7. Check to see if the conversion process succeeded by checking the OriginalNodeName attribute for the value Active Directory.
8. If the conversion process succeeded, update the permissions on the account’s home folder.
9. Prompt if admin rights should be granted for the specified account

Testing

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

• OS X 10.11.6
• macOS 10.12.2

In that testing, I did the following:

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

It has also been tested with FileVault 2-enabled accounts on both OS X 10.11.6 and macOS 10.11.2. In that testing, I did the following:

1. Encrypt an AD-bound VM with an AD mobile account
2. Once encryption had finished, I logged into the AD mobile account and ran the migration script while logged in as that account.
3. Once the account had been migrated, I rebooted and verified that I could log in at the FileVault login screen with the current password.
4. I changed the password for the local account to a new one and rebooted.
5. I verified that I could log in at the FileVault login screen with the new password.

Note: It is not necessary to be logged in as the account being migrated. I also verified that I could migrate a standard mobile account without admin privileges by logging into a separate account with admin privileges, running the script and selecting the standard mobile account from the list.

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

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

The script is available below:

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

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

Hat tip to Pat Gallagher and Lisa Davies. I modeled the script’s functionality off of Pat’s MigrateUserHomeToDomainAcct.sh script (designed to move local accounts to network accounts) and Lisa’s Perl script to migrate AD mobile accounts to local accounts provided both inspiration and guidance for writing this one.

At the beginning of November, I made the following announcement via Twitter:

Time has marched on and today is my last day at the Howard Hughes Medical Institute’s Janelia Research Campus. I wanted to take the opportunity to express my gratitude to the good folks who work there and to my management in particular.

Since 2011, I’ve spoken at a number of Mac IT conferences on a variety of topics. The ability to do so wouldn’t have been possible without the generous support that I received from HHMI. I’ve also had complete freedom when it comes to the writing I’ve done on this blog and elsewhere, which has been a huge boon to me both professionally and personally.

I look forward to continuing to both speak and write as part of my move to SAP, where I’m joining a great team doing amazing things. However, I’ll never forget that it was HHMI’s unstinting support that made it possible to begin with. Thank you.

As part of starting my new position, I’m transitioning from a job where I’m going to work at an office to a work-from-home position. This has a number of personal benefits for me, but I also knew that I was going to need an office to work out of. Working from my dining room table, or from the sofa, was going to be problematic for me for the following reasons:

1. I need a transition between work and home – I knew that if I worked from inside my house, I was not going to be able to easily do the mental switch from “I’m at work” to “I’m at home”. “Home” and “Work” was inevitably going to blur into some mishmash that I mentally dubbed “Hork”. That did not sound pleasant, either for me or for my family.
2. I need quiet – Like a number of homes, mine is occasionally very noisy. This isn’t necessarily a bad thing, that’s just the way it is. Very likely, there were going to be numerous occasions when I needed quiet when working and what was happening in my home was not quiet at all.
3. I need room for work-related stuff – Where I worked was also going to be where I was going to use and store my work-related gear. For my own peace of mind, I didn’t want to store my work-related equipment near where my pets and younger members of the family would have access to them.
4. I need to set up work-related equipment on a permanent basis – For various reasons, I like working on a desktop workstation, with attached displays, keyboard and mouse. I also like not having to constantly disassemble and re-assemble my desktop and its attached peripherals, which means I need a place where I can set them up and trust that they’ll be able to stay there on a long-term basis.

With all of those needs in mind, I decided to go the route of having a purpose-built office constructed for my work needs. For more details, see below the jump.

For my new office, here are the resources I started with:

Space

I am fortunate in that I have a sizable yard outside of my home, as that meant I had room to build as large an office as I could afford.

Budget:

I had a certain amount of money available to draw on for the budget, which I believed was going to be sufficient to build the office and outfit it. However, I also knew that I would need to shop around carefully to find vendors who could deliver what I needed within my budget.

Planning

What I wanted:

1. A space with a lot of natural light
2. A space with sufficient room for both myself and my work-related equipment, while not feeling cramped once everything was in there.
3. A building suitable for year-round use, with heat, air conditioning and insulation
4. A building with sufficient electrical capacity to power all of my current work equipment, the HVAC equipment, lighting and other needs, along with the ability to accommodate potential future growth.
5. Multiple Ethernet networking outlets in convenient locations inside the building
6. Multiple indoor electrical outlets in convenient locations inside the building

What I didn’t want:

1. Personally having to handle the acquisition of the needed construction and electrical permits
2. Having to build anything myself
3. Going over my budgeted amount of money

With these criteria, I spoke with several builders. None of the initial folks I spoke with were able to provide something that met my criteria and the budget I was working with, but eventually my research led me to the folks at Stoltzfus Structures, who had a pre-fabricated shed model that would meet my needs with some added customization:

• Upgrading the electrical breaker box from a 70 Amp breaker box to a 100 Amp breaker box
• Installing four interior electrical outlets with integrated USB power ports
• Installing four interior Ethernet outlets using Category 6 Ethernet cabling
• Installing one exterior weather-proofed electrical outlet.

The shed would incorporate a 12 foot by 16 foot office space and a separate 12 foot by 8 foot storage space, which gave me a lot of room for my office while also providing dedicated space for other storage needs.

Once we had agreed on a price for the customized shed and the costs associated with getting construction and electrical permits, we moved on to construction.

Note: One aspect of the office construction which was not handled by Stoltzfus Structures was the connection of the shed’s network to the main house’s network. For this part, I worked with Tom Bridge from Technolutionary to connect an existing Ethernet network in the main house to the shed’s Ethernet network. More details on this topic will follow later in the post.

Construction

As part of the process of building this shed, I re-learned a saying that applied over and over again:

“Everything will take longer than you think it will.”

As an example of this, I met with the folks at Stoltzfus Structures at the beginning of October and paid half of the cost of the shed so that the construction process could begin. The original timeline was to have it completed by the end of October. The actual completion date for the shed, with various delays due to weather, getting permits from the county, and other hangups, was December 1st. Meanwhile, the electrical work’s final inspection (where it was signed off as OK by the county and no other work needed to be done) was December 16th. Please see below for some shots of the construction process and final product:

Fortunately for me, I didn’t absolutely need to have the shed in operation until January 2nd so I didn’t tear my hair out over how long it was taking. The lesson to take from this was pretty clear though: However long you think a construction project will take, plan for it to take at least twice or even three times as long. That way, all your surprises will be pleasant ones.

Office networking

As part of the construction, one of the goals I had in mind was to ensure that the office network was going to be use Gigabit Ethernet networking at the present time, but with the option to upgrading to 10 Gigabit Ethernet networking at a future date. To ensure this, I had the shed equipped with Category 6 Ethernet as that would be compatible with a future upgrade to 10 Gbit Ethernet networking.

Meanwhile, Technolutionary’s network contractor used 10 Gbit-compatible fiber optic cables to connect the shed to the main house’s existing Ethernet network. That allows the shed to share the main house’s existing internet connection over a dedicated landline connection, which avoided the need to set up a potentially more expensive wireless bridge between the main house and the shed.

Outfitting the office

When it came to outfitting the office with furniture and other gear, here’s what I wanted:

• Sufficient desk space for multiple displays, desktops and laptops to co-exist without feeling cramped
• Sufficient storage space for various cables and other accessories to be put away but still be readily available
• Desk-mounted electrical outlets
• A soda machine (because I’ve always wanted one.)
• A comfortable office chair

Desk

I decided on using two writing desks and arranging them in an L pattern. These desks’ large flat surfaces allowed me to place displays and keyboards in convenient locations, while also providing a lot of additional room for desktops and laptops to sit on the desks’ surfaces. These desks also include metal grommets on the desks’ surfaces to provide basic cable management for cables coming up from under the desk.

Storage

I decided on a 12-drawer mobile organizer designed for classroom use for my storage needs. It has a mix of small and large drawers for storage, and is also able to be rolled to wherever in the office I may need it.

Desk-mounted electrical outlets

I decided on two desktop power strips because they were easy to install and offer both three AC power outlets and two USB power outlets. One power strip is attached to each desk.

Soda machine

I decided on a Hisense Chill, which is a beverage vending machine designed for use in the home and includes the ability to stock both bottles and cans. The Chill can also be configured with customized front panel art and button labels, both of which I took the opportunity to change out.

Chair

In this case, I was fortunate and received a comfortable office chair as a Christmas gift.

Lessons learned

As this project progressed, I learned several lessons that will no doubt be familiar to folks who have done similar projects:

Everything takes longer than planned

I began the planning for this project in early 2016, with accumulating the financing needed for this project. That process was completed by June 2016, and I assumed that the hard part was over; now I just needed to find someone to take my money and build an office.

That assumption was incorrect, it wound up taking until early October 2016 to find a builder for the project.

From there, the project timeline was that construction from start to finish would be completed within the month of October; ending in early November.

That assumption was incorrect, it would take until early December for the office construction to be completed. It took another couple of weeks for all the electrical work to be completed and inspected, so it was mid-December before the lights actually went on and the heat started working. Having the heat working is especially important for mid-December in my area.

Pay attention to the details

For the most part, construction went smoothly but I tried to keep a close eye on what was going on. One place in particular where I caught a problem was in the installation of the Ethernet cabling in the wall. Once it was installed, I checked on it before the wall paneling went in place. It turned out that that Category 5E Ethernet cabling had been installed instead of the Category 6 cabling I wanted.

When I checked back with the construction project manager, we saw that only “Ethernet” had been specified in the construction plan. Category 5E Ethernet cabling is cheaper, so it had been installed. I requested the Category 5E Ethernet cabling be removed, Category 6 Ethernet cabling installed, and agreed to cover the additional cost.

Catching this at the time I caught it was important for the following reasons:

1. Category 5E Ethernet cabling can support gigabit transmission speeds, but is not able to support 10 Gbit. Since I wanted to have the option to support 10 Gbit down the road, having Category 5E Ethernet cabling for the wall outlets would have made that more difficult.
2. Identifying the issue before the wall paneling went in place made fixing it a lot more simple. If it had been caught after the wall panels went into place, removing the wall panels would have been needed. The removal process would have been both expensive and time-consuming; in fact I probably would have just lived with having Category 5E Ethernet cabling and installed a makeshift solution later for 10 Gbit Ethernet.

Communications breakdowns will happen

As part of setting up the office networking, the networking contractor installed a wall-mounted box in the shed for the fiber optic and other cables which were run from the main house. He suggested installing a larger box and I agreed. Between the time that we had that conversation and he actually returned to install the box, the office construction crew finished the walls and closed in the space around the existing small box.

I didn’t know that the networking contractor needed to know when the construction crew was closing up the wall in question, so the larger networking box did not get installed. I have the small networking box and have been able to work with it, but not being able to communicate to the construction crew what was needed meant that I have a solution I can work with instead of the ideal solution.

Closing thoughts

I am both happy and proud of how this particular project turned out, and I look forward to being able to use my new office for years to come. For those who are thinking of similar projects for your own use, hopefully this information helps you out in the process of turning your ideas into reality.

I don’t normally try to foretell the future but there is one change for Mac admins that I’m pretty sure will happen:

The coming of Apple File System (APFS) will mark the end of disk imaging on Macs.

For those not familiar with disk imaging, a disk image is a computer file containing the contents and structure of a disk volume. Mac disk images are applied to hard drives using the Apple Software Restore (asr) command line utility to erase the destination drive and then block-copy the data from the disk image onto the destination drive.

Mac deployment practices have generally fallen into one of three categories:

Monolithic imaging

Monolithic imaging is the practice of building a Mac with the desired operating system, desired software, and desired configuration settings, then creating a disk image which includes all the contents of that Mac’s boot drive, including the operating system, installed software, and settings.

Once that disk image is created, the image is then applied to multiple other Macs to make them just like the original Mac.

Modular imaging

Modular imaging is the practice of creating a disk image that contains only the base OS (as well as necessary OS updates from Apple).

Once that disk image is created, the image is applied to multiple other Macs. Desired software and desired configuration settings are then installed onto the newly-imaged Mac as post-imaging deployment tasks.

Thin imaging

Thin imaging is technically not an imaging practice, as no disk image is involved. Instead, the assumption is that Macs from Apple come with a pre-installed OS and that OS should be used instead of wiping it and replacing it with a new copy from a disk image.

In this scenario, a deployment workflow is run which installs the desired software and desired configuration settings onto the Mac. If a Mac needs to be wiped and re-setup, a fresh copy of the OS is installed via the Recovery environment or similar OS installation process and then the thin imaging deployment workflow is re-run.

Imaging using asr has been around for a long time (I first began using it back in the Mac OS X 10.2.x days) but there have been strong hints that those days are coming to an end. The most visible of these was this tweet from the makers of DeployStudio:

While the makers of DeployStudio don’t speak for Apple, a statement like this matches up with what I’ve heard from other Mac admins who have independently received similar messages as part of their communication with Apple. Apple hasn’t commented publicly one way or the other, so unfortunately I can’t be more specific than that.

If imaging isn’t available, 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 a thin imaging deployment workflow, which installs the desired software and desired configuration settings onto the Mac’s existing OS. To get an existing OS though, you would need to install it via the Recovery environment or a similar OS installation process.

Planning for the future

Today, imaging works and our deployment workflows are what they are. What should be done to prepare for the future?

If you’re already using DEP with MDM to set up your Macs:

1. Congratulations! You’re good to go with a Apple-supported deployment workflow that should work fine for the foreseeable future.

If you’re not using DEP with MDM to set up your Macs:

1. If DEP is an option for your organization and you have an existing MDM service, investigate using Apple’s DEP service to set up your Macs for deployment. You may find that DEP doesn’t work for you in its current form, but now is the time to find that out and work with Apple to get those parts fixed.
2. If DEP isn’t an option for your organization (because you aren’t using MDM and/or you aren’t in a country where DEP is supported) and you aren’t using a thin imaging deployment workflow now, I recommend investing the time and effort to start using a thin imaging workflow. In particular, if you are using monolithic imaging to set up your Macs, it is time to stop and transition to an alternate way of deploying Macs before that imaging method abruptly stops working.

When will we know how long imaging has left? My recommendation will be to watch what Apple reveals at this summer’s WWDC 2017 conference and pay particular attention to any device management or APFS developments that are being announced, as those announcements should likely provide the best information.

On some occasions, it’s useful to be able to make a full backup of a system on an ad-hoc basis. One example would be making a complete backup of a Mac’s boot drive before sending it in to Apple for a repair, as Apple may swap out or erase the Mac’s existing boot drive as part of the repair process if their tools indicate a drive problem.

When I’ve needed to do this, I’ve used DeployStudio for this task. The reason why is that DeployStudio includes the ability to do the following:

1. Create an asr-ready disk image from a Mac’s boot drive containing the OS and all other data.
2. Restore the disk image to an available volume on the same or different Mac, and setting the target volume to be bootable.

These capabilities were originally designed to allow monolithic images to be created from one Mac for distribution to other Macs, but these capabilities also allow DeployStudio to create on-demand backups of a Mac’s boot drive. For more details, see below the jump.

By default, new installations of DeployStudio include the following two workflows:

Name: Create a master from a volume
Description: This simple workflow enables you to select a volume (HFS, NFTS or EXT format) in order to create a disk image. The disk image will be stored automatically on the DeployStudio repository.

Name: Restore a master on a volume
Description: This simple workflow enables you to restore a disk image (HFS, NFTS or EXT format) located on the DeployStudio repository to a local disk or volume.

I cloned both workflows and edited the new workflows to make it more clear that these workflows were used for backup and restore tasks.

Name: Create Backup System Image
Description: Use this workflow to make an image of a system prior to working on it.

Here’s how I have the workflow set up in DeployStudio.

Name: Restoring System Image From Backup
Description: Use this workflow to restore a backup image of a system.

Here’s how I have the workflow set up in DeployStudio.

Note: The Skip Apple Setup Assistant option is checked because I’ve found that DeployStudio will remove the /private/var/db/.AppleSetupDone file when restoring. This file suppresses the Apple Setup Assistant, so checking this option is needed in order to add the .AppleSetupDone file back.

Creating a backup

To create a backup using the Create Backup System Image workflow, use the following procedure:

1. Boot to DeployStudio
2. Log into DeployStudio
3. Select the Create Backup System Image workflow.

4. Select the Mac’s boot drive.
5. Name the disk image something unique and distinctive.

6. Click the play button to start the workflow.
7. Go get coffee or do other work while DeployStudio is creating the disk image.

8. Once the backup is complete, click the Quit button to reboot the Mac and exit DeployStudio.

Restore from backup

To restore a disk image to a drive using the Restoring System Image From Backup workflow, use the following procedure:

1. Boot to DeployStudio
2. Log into DeployStudio
3. Select the Restoring System Image From Backup workflow.

4. Select the desired disk image.

5. Select the desired target drive.

6. Click the play button to start the workflow.
7. Go get coffee or do other work while DeployStudio is restoring the disk image.

8. Once the restore is complete, click the Quit button to reboot the Mac and exit DeployStudio.

9. When the Mac boots up, the DeployStudio Finalize process runs then automatically reboots the Mac.

10. After the second reboot, log into the Mac and verify that the restore was successful.

Note about drive space

An important thing to account for when using DeployStudio for backups like this is ensuring your DeployStudio server has sufficient disk space available on the DeployStudio fileshare for the backup disk images. When DeployStudio is capturing an image, here is the process it uses:

1. The data on the target drive is written to a read/write sparsebundle disk image. This disk image will be the same size as the amount of data that you’re trying to back up.
2. Once the data on the target drive has been completely written to the sparsebundle disk image, the sparsebundle disk image is converted to a compressed read-only disk image.
3. Once the compressed disk image has been fully created, the sparsebundle disk image is deleted.
4. The compressed disk image is scanned by asr for later restoration.
5. The restore-ready compressed read-only disk image is uploaded to the DeployStudio server.

Because the sparsebundle disk image is not deleted until after the compressed read-only disk image is ready, at a point in the process, you’re going to need available space for not only the full size of the data you’re backing up, you’ll also need available space for the full size of the compressed disk image.

If there is available space on the drive being backed up, or on another hard drive connected to the Mac being backed up, DeployStudio will prefer to use local disks for creating the sparsebundle disk image and compressed disk image. However, if there is not sufficient space available on the Mac being backed up for the disk images to be created, DeployStudio will mount a temporary network fileshare from the DeployStudio server and do the necessary disk image creation using the available space on the DeployStudio server itself.

Now that Skype for Business has been released for macOS, I’ve been using it as a soft phone solution rather than using an actual phone in my office. I ran into an issue with a conference call today though which forced me to use my cell phone instead of Skype. For more details, see below the jump.

I needed to join a conference call with an outside third-party, where I needed to enter a participant code after calling the number. The participant code is a multi-digit code which can be entered into any phone’s dialpad.

The process I followed looked like this:

1. Call the conference call number using the Skype dialpad.

2. Connect successfully.
3. Once connected, an automated voice asks me to enter the participant code.

What I expected:

1. Enter the code into the Skype dialpad

2. Automated operator connects me to the conference call

What happened:

1. Enter the code into the Skype dialpad

2. Automated operator ignores code
3. Re-enter code into the Skype dialpad
4. Automated operator ignores code
5. After about 30 seconds, automated operator disconnects call.
6. Re-dial number
7. Repeat steps 1-5 twice more.
8. Give up after step 7, use cell phone.

After discussing it with some colleagues in the Macadmins Slack, Ian Trimnell was able to provide a solution for this problem. If you need to enter additional digits after being connected to a call:

1. Call the number using the Skype dialpad.

2. Once connected, click the phone icon in the top right corner of the call window.

3. A separate dialpad will appear.

4. Enter the additional digits into this dialpad.

As part of assisting a colleague with a customer today, I needed to figure out how to enable the debug logging for Microsoft AutoUpdate. For Mac admins with a similar need, please see below the jump for details.

Microsoft AutoUpdate (MAU) sends its logs to the following location:

/Library/Logs/Microsoft/autoupdate.log

By default, this is INFO level logging and usually appears like this.

To start debug logging, you need to enable MAU’s Extended Logging using the following procedure:

1. Quit Microsoft AutoUpdate (if running.)
2. Open Terminal and run the following command:

defaults write com.microsoft.autoupdate2 ExtendedLogging -bool true

3. Launch Microsoft AutoUpdate.
4. Run whatever process is needed.
5. Check /Library/Logs/Microsoft/autoupdate.log for the results.

The additional logging should be marked with the Debug tag:

For those who want to enable MAU’s ExtendedLogging setting using management profiles, I’ve created a .mobileconfig file and posted it here on Github:

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

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

PDF – http://tinyurl.com/MacADUK2017pdf

Keynote – http://tinyurl.com/MacADUK2017key

A lot of Mac admins need to test software in their environment against both the shipping version of macOS and older versions of OS X. However, getting older OS installers from the Mac App Store (MAS) can be problematic if the Mac you’re using isn’t able to run the older OS as its own operating system. If the Mac you’re using isn’t itself able to run the older OS, a request to download the OS installer from the MAS will result in an error message like the one shown below.

If you’re in this situation, but also have VMware Fusion or a similar virtualization solution available, there is a way to download the desired older OS installer using a VM running the shipping version of macOS. For more details, see below the jump.

The method described below uses VMware Fusion, but should be replicable using any virtualization solution which supports running the shipping version of macOS as a guest OS.

1. If needed, create a new VM running the shipping version of macOS.

2. Log into the VM.

3. Launch the App Store application and sign in with the desired Apple ID.

4. Select the desired OS installer and click the Download button.

5. You’ll receive a message that a newer version of the OS is installed and are asked to confirm that you want to download the older OS installer. Click the Continue button.

6. The older OS installer should download.

7. Once the installer has completed downloading, copy it out of the VM to a convenient location.

As part of some work I was doing today, I needed to burn an .iso file to a CD. As I have in the past, I opened Disk Utility and looked for the icon for burning a disc only to discover that this option stopped being available as of OS X El Capitan. It is likewise not available in macOS Sierra’s Disk Utility application.

After doing some additional research, it looks like the ability to burn a disc image is now only available through the Finder or by using hdiutil. For more details, see below the jump.

To burn a disk image file to an optical disk on macOS Sierra, use the procedure described below:

1. Select the desired disk image and right-click to bring up the contextual menu.

2. Select Burn Disk Image “Disk Image Name Here” to Disc…

3. If needed, insert a blank optical disk when prompted.

4. If something other than the default settings are needed, click the drop arrow and set your desired burn options.

5. Once the drive is ready to begin burning the disk image to the optical disk, click the Burn button.

6. The disk image should now burn to the optical disk.

It can be difficult to provide consistent access for Mac admins when using a local admin account on FileVault 2-encrypted Macs, due to the way password changes are handled for FileVault 2-enabled accounts. The reason for the difficulty is that FileVault 2’s encryption doesn’t care about passwords, it only cares about encryption keys.

When an account on a particular Mac is enabled for FileVault 2, the account’s password is used to generate an key which can be used to unlock the encrypted Core Storage volume that FileVault 2 sets up on the Mac. When the password for the enabled account gets changed, the password and its associated key are updated by first requesting the previous password (and its associated key) to authenticate the change to the new password and associated key.

Assuming that the old password is provided as part of the password change process, no problem. However, if the old password is not provided as part of the password change process, the new password does not get an associated key to unlock FileVault 2 because the old password’s key was not invoked to authorize the change to a new key. The result of this is that the new password can be used to log into the OS and provide whatever password authorization duties are needed for the OS, but you still need the account’s old password to log into the Mac at the FileVault 2 login screen.

The usual fix for this situation is to run the following commands with root privileges:

1. Remove the user from the list of FileVault 2-enabled accounts

fdesetup remove -user username_goes_here

2. Add the user back to the list of FileVault 2-enabled accounts

fdesetup add -usertoadd username_goes_here

When the account is re-enabled using the fdesetup add -usertoadd command, a new key is set up for the user and the passwords are back in sync. However, there are two drawbacks to this approach if a Mac admin wants to automate this:

• You need to provide the password in a non-encrypted format of the account being enabled.
• You need to provide in a non-encrypted format either a recovery key or the password of another FV 2-enabled account on the Mac.

In short, the passwords and/or recovery key used to remove and re-enable the account in question need to be provided “in the clear”, where anyone successfully intercepting the passwords will be able to read them.

Fortunately, for those Mac admins who have a way to capture and escrow FileVault 2 personal recovery keys, there is an alternative to enabling the local admin account. For more details, see below the jump.

This approach relies on the encrypted Mac using an alphanumeric personal recovery key and the Mac admin having access to that personal recovery key.

If both of those conditions are true, see below for a way to log into a local admin account without needing to have that account enabled for FileVault 2.

1. If needed, boot up the Mac.

2. Once the Mac has booted to the FileVault 2 login screen, select an account if needed.

3. When prompted for the account password, click the question mark icon.

4. The next prompt will offer an option to reset the password using the recovery key. To access that, click the arrow icon.

5. Enter the alphanumeric personal recovery key and hit the Return key on the keyboard.

6. The FileVault 2-encrypted boot drive will unlock and boot to the OS login window.

7. At the OS login window, a Reset Password window will appear. Click the Cancel button to halt the password reset process.

8. Log into the Mac using the desired local admin account.

Note: Once a personal recovery key is used to log into a Mac, I recommend replacing it by rotating to a new personal recovery key. For those interested in automating this, my colleague John Kitzmiller has documented how to set up an automated recovery key rotation process using Casper. His post is available via the link below:

https://www.johnkitzmiller.com/blog/automatically-re-issue-individual-filevault-2-recovery-keys-after-single-use-with-the-casper-suite/

For shops that want to help their customers stay on top of Apple software updates without forcing those updates to be applied, there is a convenient URL that can be used:

macappstore://showUpdatesPage

When this URL is called from the command line using the open command, the following actions take place:

1. The App Store application launches
2. The Updates page loads.
3. The Mac automatically checks for Apple OS updates and updates for applications purchased through the Mac App Store (MAS).

The relevant command is shown below and can be run without root privileges:

open macappstore://showUpdatesPage

For folks using Jamf Pro (the management solution formerly known as Casper), this command can be leveraged to provide a way for customers to easily check for Apple and MAS software updates on their own schedule. For more details, see below the jump.

As an example of how this can be used, a Self Service policy can be built which uses the command referenced above.

• Frequency: Ongoing
• Trigger: None
• Make the policy available In Self Service
• Actions:
  • Execute command:

    open macappstore://showUpdatesPage
    

Once built, the policy should be available in Self Service for your customers to access.

Please see below for what the process should look like from the customer’s perspective.

Every so often, it’s necessary to resize the boot drive of an existing virtual machine. The process of resizing the VM’s boot disk from outside the VM is usually pretty straightforward:

1. Shut down the VM
2. Go into the VM’s drive settings

3. Resize it to the desired size

4. Power on the VM.

However, when the VM boots up, the disk space used by the OS won’t have changed.

However, the OS can detect that there is available unallocated disk space that it isn’t using.

Fortunately, this is a correctable condition and the fix can be applied without needing to shut down the VM or boot from another drive. For more details, see below the jump.

The VM disk resizing process is a two-step process, where the first part is resizing the VM boot drive. The second step is resizing the drive partition using the OS’s tools to use some or all of the available unallocated space.

To tell the OS to use all of the available unallocated space, use the procedure described below:

1. Open Terminal

2. Run the command below:

diskutil resizeVolume / R

This command will tell macOS to do a live re-size of the boot partition, with the R flag specifying that all available unallocated space should be used.

3. The drive partition will resize to fill all available space.

4. The OS should now recognize and be able to use the now-allocated space.

I’ve written a script to run the appropriate diskutil command, which is available below and on my GitHub repo:

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

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

In a number of environments, Mac admins are transitioning from hosting their Mac-supporting services in on-site datacenters to now hosting them with various cloud service providers. These service providers can include Jamf Cloud, Amazon Web Services, Akamai or Rackspace.

For Mac admins using Jamf Pro, one way to start this transition is to use a Cloud Distribution Point (CDP). This allows a Jamf Pro server to use several specific cloud services’ content delivery networks to host installers and (if applicable) in-house developed applications and eBooks.

For my own needs, I was looking into setting up a CDP on Amazon Web Services (AWS). Jamf provides some documentation on how to set a CDP up with AWS, but doesn’t provide specific guidance. After some research and testing though, I was able to figure out the process for Jamf Pro 9.97x. For more details, see below the jump.

Before I was able to set up the CDP in my Jamf Pro server, I first needed to log into AWS and set up the needed permissions and policies for Amazon’s Simple Storage Service (S3). S3 is AWS’s primary service for storing data and Jamf Pro servers use it when setting AWS-hosted CDPs. For the process I used, see below:

Setting up AWS access and permissions

1. Log into the AWS console.

2. Once at the AWS Dashboard, select Identity and Access Management (IAM).

3. Select Users from the sidebar.

4. Click the Add User button.

5. Set up a new user and select Programmatic Access for the Access type option, then click the Next: Permissions button.

6. Click the Attach existing policies directly button.

7. Click the Create Policy button.

At this point, a new Create Policy window or tab should open in your web browser.

8. Click the Select button associated with the Create Your Own Policy button.

9. Copy and paste the policy shown below.

This policy sets up the account you just created with the correct permissions for the Jamf Pro CDP to be set up and work properly with AWS’s S3 and CloudFront services.

Note: Even if you do not plan to use CloudFront services, you will still need to have these permissions included with the policy. If these permissions are not included, the CDP creation process may halt with an error.

10. Once you have the policy set up, named and described, click the Validate Policy button to make sure the policy is formatted correctly.

11. If the policy validates correctly, click the Create Policy button.

Once the policy has been created, it will now show up in the list of policies that you can select. It will have its type set as Customer Managed, since it was created by an AWS customer as opposed to being created by AWS as a service for its customers.

12. Select the new policy if needed and click the Next:Review button.

13. At the review window, make sure that the selected choices match expectations. If they do, click the Create user button.

14. Once the user has been successfully created, the Access Key ID and Secret access key for the new user account can be accessed. To view the secret key, click the Show link.

The account credentials can also be downloaded as a .csv file.

At this point, the existing AWS policy and account permissions are sufficient to create a CDP for a Jamf Pro server on AWS. For those who want to additionally secure your CDP by using CloudFront signed URLs, it will be necessary to get a copy of the appropriate CloudFront public and and private keys.

Unlike many management functions in AWS, access to the appropriate CloudFront public and and private keys is only available to the root user of the AWS account. Depending on the size of your organization, the AWS root account may be controlled by a group outside of yours, so you may need to do some investigation to see who can provide you with access to the CloudFront keys.

If you have access to your AWS account’s root user, here’s how to generate the appropriate CloudFront public and private keys.

1. Log into the AWS console.

2. Click on your account’s name in the upper right hand corner of the window.

3. Select My Security Credentials from the drop-down menu.

4. Find the CloudFront Key Pairs section and click the plus symbol, then click the Create New Key Pair button.

5. A pop up window will appear to notify that a new key pair has been created. Click the Download Private Key File button to download the private key.

Note: I also recommend downloading the public key at this time.

• The private key will download as a file named something similar to pk-033E34D4CB164A61912908A7B3EE93BE.pem
• The public key will download as a file named something similar to rsa-033E34D4CB164A61912908A7B3EE93BE.pem

To verify which is which, you can also open the .pem files with a text editor and see if the keys report themselves as private keys or public keys.

Note: Once you have the keys downloaded, store them in a secure location.

Setting up the Cloud Distribution Point

Once the needed configuration has been done in AWS and the necessary credentials have been acquired, an AWS-hosted CDP can now be set up on your Jamf Pro server using the procedure shown below.

1. Log into your Jamf Pro server

2. Go into Management: Computer Management and select Cloud Distribution Point.

3. In the Cloud Distribution Point window, click the Edit button.

4. Select Amazon Web Services from the Content Delivery Network drop-down menu.

5. Locate the account credentials of your previously created AWS user account and fill in the needed credentials for the Access Key ID and Secret Access Key blanks.

6. Once the credentials have been entered, click the Save button.

7. To check the connection between the Jamf Pro server and the CDP, click the Test button.

8. In the Test Cloud Distribution Point window, click the Test button.

If the connection is working properly, you should see a success message.

Verifying the creation of the Cloud Distribution Point in AWS

1. Log into the AWS console.

2. Once at the AWS Dashboard, select S3.

3. Verify that a new S3 bucket has been created, using a name beginning with jamf.

At this point, the CDP should be up and working but it is not using signed URLs at this point. If you want to enable signed URLs, use the procedure shown below.

Enabling signed URLs on the Cloud Distribution Point

1. Log into the Jamf Pro server

2. Go into Management: Computer Management and select Cloud Distribution Point.

3. In the Cloud Distribution Point window, click the Edit button.

4. Select the Require Signed URLs checkbox.

5. Click the Upload CloudFront Private Key button.

6. In the pop-up window that appears, click the Choose File button and select the appropriate CloudFront private key.

7. Once the CloudFront private key has been selected, click the Upload button.

8. Once the private key has uploaded, the name of the private key file should appear and be grayed out in the CloudFront Private Key blank. The CloudFront Access Key ID blank should also be populated with the Access Key ID.

9. Once all settings appear to have been applied correctly, click the Save button.

The CDP should now automatically begin using signed URLs.

Hat tip to my colleague François Levaux-Tiffreau, for providing the best documentation I came across in my research on how to set up a CDP with Jamf Pro.

While discussing various issues with a colleague, he mentioned that he was seeing the root account enabled on several machines where it should not have been. In general, the root account on macOS is not needed for system administration and should be disabled so he asked if there was a way to use the dsenableroot command to disable the root account without also needing to provide a password.

Unfortunately, disabling the root account by using the dsenableroot -d command does require providing a password as part of the command.

However, it is possible to disable logins to the root account without using the dsenableroot -d command. For more details, see below the jump.

In Unix operating systems, there are two commands whose only purpose is to exit and return a pre-determined message on exit:

• true – returns a successful exit message
• false – returns an unsuccessful exit message

Another use for the false command is to block account logins. By setting the account’s shell setting to the path of the false command, any interactive login (either via the OS login window or via command line) will fail to successfully complete. This has the effect of blocking login to the affected account.

On macOS, you can set the root account’s shell to the false command by running the following command with root privileges:

/usr/bin/dscl . -create /Users/root UserShell /usr/bin/false

Once the root account’s shell has been set to /usr/bin/false, it will no longer be possible to log into the root account at either the OS’s loginwindow or in the Terminal.

It will still be possible to run commands with root privileges by using the sudo utility.

Thanks to participating in multiple Slack instances, I’ve been in the position more than once where I’ve wanted specific emoji available in one Slack to also be available in another Slack instance. While Slack themselves provide a stock set of emoji for all Slack instances, custom emoji can help you express yourself better. For example, one of my favorites on the MacAdmins Slack instance is :headdesk:, represented by this animated emoji.

While there are solutions to moving emoji en masse, I usually just want to selectively download emojis as I see them. Fortunately, there’s a relatively straightforward way to do that using Safari. For more details, see below the jump.

To download emoji using Safari, you’ll first need to enable Safari’s ability to examine webpage elements:

1. Open Safari.
2. Under the Safari menu, select Preferences…

3. Select Advanced in the toolbar.

4. Click the Show Develop in menu bar option.

5. A new Develop menu should appear.

Once the Develop menu is available, go to your Slack team’s list of custom emoji.

Once you have found the emoji you want to download, use the procedure below to download it:

1. Right click on the emoji image and select Inspect Element.

2. The Safari web inspector will open and display a block of selected text. Use Copy under the Edit menu to copy the selected block.

3. Paste the block into a convenient text editor.
4. Select and copy the image URL in the block of text.

5. Paste the URL into a browser address bar and click the Return key to load the link.
6. The emoji should appear in your browser window.

7. Download the emoji image to a convenient location.

At this point, the emoji is ready for upload to other Slack instances.

In a number of Mac environments, there is a need or requirement for a login banner (otherwise known as a lock message). This message appears in the following locations:

• FileVault 2 pre-boot login screen
• OS login window
• Screensaver lock window

Brevity is best, as staying within a maximum of three lines permits the banner text to be displayed consistently in all three locations. Exceeding the three-line limit may result in the text being cut off and not fully displayed.

You can set this banner text from the command line using the following defaults command, which should be run with root privileges:

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "My Login Window Text Goes Here"

Being able to consistently set when lines begin and end can be challenging though, as the defaults command is not able to interpret a newline command natively. However, it is possible to set a multi-line login banner and be able to consistently set when lines begin and end. For more details, see below the jump.

To accommodate for the defaults command’s inability to interpret newline commands, you can use the printf utility to format the text of the login banner as designed and store the formatted text as a variable. printf is able to interpret the characters \n as indicating a carriage return, so it is possible to run the following command:

printf "This Mac belongs to John Doe\nPhone number: 1-555-555-1212\nReward offered if found.\n"

To display the following text:

This Mac belongs to John Doe
Phone number: 1-555-555-1212
Reward offered if found.

In order to set a login banner with this message, you could run a script like the one shown below, using root privileges:

#!/bin/bash

loginbannertext=`printf "This Mac belongs to John Doe\nPhone number: 1-555-555-1212\nReward offered if found."`

# Set login banner

/usr/bin/defaults write /Library/Preferences/com.apple.loginwindow LoginwindowText "$loginbannertext"

The message will appear at the login window,  screensaver lock window, and FileVault 2 login with the desired lines of text beginning and ending as specified.

Note: If the message does not appear at the FileVault 2 login, you also need to remove certain cache filenames ending in .efires from the following location:

/System/Library/Caches/com.apple.corestorage/EFILoginLocalizations

As part of my pre-release testing of macOS Sierra, I tested iCloud Desktop and Documents syncing and decided I was not going to use it because of the problems I found. However, at that time I could not find a way to disable only iCloud Desktop and Documents without having to disable iCloud Drive entirely.

As part of the release of macOS 10.12.4, Apple has made available a profile option that allows for the specific disabling of iCloud Desktop and Documents syncing without needing to block iCloud Drive.

For more details, see below the jump.

For those who want to disable iCloud Desktop and Documents, I’ve created a .mobileconfig file and posted it here on Github:

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

Once installed, you should be able to have iCloud Drive enabled in your iCloud settings.

When you click the Options… button for iCloud Drive, the Desktop & Documents Folders setting should appear as grayed out and not selectable.

With the release of macOS 10.12.4, it appears that Apple has made a change to the OS installer that blocks the installation of third-party packages which have been added to the OS installer. In my testing, I’ve verified the following tools are affected:

• createOSXinstallPkg
• System Image Utility
• create_os_x_vm_install_dmg

Note: There may be others, this list is what I’ve tested.

In each case, the OS install process proceeds without issues until the OS installer tries to install the third party installer package. At that point, the installation process fails and displays the message shown below:

The package "Package Name Goes Here" is not signed.
Quit the installer to restart your computer and try again.

The error message displayed is misleading however, as this message may also appear if the package has been signed with a Developer ID Installer certificate.

In testing done by myself and others, we have found that there is one circumstance where you can still add a third-party installer package:

1. If you are building a NetInstall NetBoot set using System Image Utility
2. If the package is signed with a Developer ID Installer certificate.

Otherwise, the only installer packages I’ve seen which install correctly are packages which have been signed by Apple itself.

For more details, see below the jump.

As mentioned previously, Apple’s System Image Utility is affected by this issue. To replicate the failure behavior, use the process shown below:

Pre-requisites:

• A Mac upgraded to macOS 10.12.4
• System Image Utility
• A macOS 10.12.4 installer
• A unsigned third-party installer package

For my third-party installer package, I used one created by First Boot Package Install Generator.app.

1. Launch System Image Utility
2. Select the macOS 10.12.4 installer as the source.

3. Select option to build a NetInstall Image

4. Select option to add an additional installer and add the unsigned third-party installer package.

5. Change no other options from their default settings.
6. Build the NetInstall set.

Once the NetInstall set is built, boot a Mac or VM from the NetInstall set and run the OS installation process. In my testing, the OS install process has consistently failed when trying to install the unsigned third-party installer package. To show what this behavior looks like, please see the video below:

Note: The video has been edited to artificially reduce the amount of time the OS installation process takes to run. Run time of the pre-edited video was 21 minutes 18 seconds.

To replicate the successful install behavior, use the process shown below:

Pre-requisites

• A Mac upgraded to macOS 10.12.4
• System Image Utility
• A macOS 10.12.4 installer
• A third-party installer package which has been signed with a Developer ID Installer certificate.

For my third-party installer package, I used the same firstboot package created earlier and signed it using the productsign utility and my Developer ID Installer certificate.

/usr/bin/productsign --sign 'Developer ID Installer: Name Goes Here (FT45CST65F)' "/path/to/First Boot Package Install.pkg" "/path/to/other/place/First Boot Package Install.pkg"

1. Launch System Image Utility
2. Select the macOS 10.12.4 installer as the source.

3. Select option to build a NetInstall Image

4. Select option to add an additional installer and add the signed third-party installer package.

5. Change no other options from their defaults.
6. Build NetInstall set

Once the NetInstall set is built, boot a Mac or VM from the NetInstall set and run the OS installation process. This time, the installation process of the third party installer package should succeed. To show what this behavior looks like, please see the video below:

Note: The video has been edited to artificially reduce the amount of time the OS installation process takes to run. Run time of the pre-edited video was 20 minutes 9 seconds.

Workarounds

Since the new behavior is specific to the 10.12.4 installer, my recommendation at this point is to use the macOS 10.12.3 installer where needed. Once the OS is installed, update to later versions of macOS Sierra as a post-installation task.

I’ve had a tool available for a while named create_vmware_osx_install_dmg, but it looks like it has reached the end of the road with macOS 10.12.3. The reason for this is because macOS 10.12.4 has introduced a change that prevents the addition of third-party packages to the OS installer. create_vmware_osx_install_dmg uses the addition of a third-party installer package, so unfortunately this tool cannot be used to generate 10.12.4 or later OS installers.

That said, I still want to be able to create macOS installer disk images for VMware Fusion and ESXi, so I’ve forked create_vmware_osx_install_dmg into a new script named create_macos_vm_install_dmg. create_macos_vm_install_dmg will generate stock OS installer disk images for the following OS versions:

• Mac OS X 10.7.x
• OS X 10.8.x
• OS X 10.9.x
• OS X 10.10.x
• OS X 10.11.x
• OS X 10.12.x

This script does not use a third-party package, so it is able to build a macOS 10.12.4 installer disk image. For more details, see below the jump.

Downloading the script

The create_macos_vm_install_dmg script is available from the following location:

https://github.com/rtrouton/create_macos_vm_install_dmg

Once you have the script downloaded, run the create_macos_vm_install_dmg script with two arguments:

1. The path to an Install macOS.app or the InstallESD.dmg contained within.
2. A directory to store the completed disk image in.

Example usage:

If you have a 10.12.4 Sierra installer available, run the script using this command:

sudo /path/to/create_macos_vm_install_dmg.sh "/Applications/Install macOS Sierra.app" /path/to/output_directory

You will be given a choice as to whether or not you want an .iso file for use with ESXi.

If you choose to not create the .ISO file, this should produce a .dmg file inside the specified output directory that is named something similar to macOS_InstallESD_10.12.4_16E195_20170329111134.dmg. This DMG will install a stock factory install of macOS 10.12.4.

If you choose to create the .ISO, you should have two files inside the specified output directory, named something similar to macOS_InstallESD_10.12.4_16E195_20170329111134.dmg and macOS_InstallESD_10.12.4_16E195_20170329111134.dmg.iso

Creating a VM with the OS installer disk image

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 your macOS installer disk image file and click on the Open button.

6. You’ll be taken back to the Create a New Virtual Machine window. Verify that the disk image file you want is selected, then click the Continue button.

6. In the Choose Operating System window, set OS as appropriate then click the Continue button.

In this example, I’m setting it as follows:

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

7. In the Finish window, select the Customize Settings button if desired. Otherwise, click the Finish button.

8. Save the VM file in a convenient location.

The VM is now configured and set to use the macOS installer disk image. To install macOS, start the VM and then do nothing. The VM should begin automatically installing macOS on the VM’s boot drive and reboot itself to the Setup Assistant when finished.