Building a home office

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.

Moving on

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

After six rewarding years at @HHMIJanelia, I'm moving on in January 2017 to join the Mac CoE @SAP team.

— Rich Trouton (@rtrouton) November 1, 2016

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.

Migrating AD mobile accounts to local user accounts

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.

MacAdmin 101: Using createOSXinstallPkg to build OS X and macOS installer packages

Providing new installs of macOS, or upgrading to newer versions, can be a challenge in many Mac environments. Apple’s OS distribution model is focused around the Mac App Store (MAS), which may not be an option for a number of managed Mac environments. The MAS-distributed OS installer also does not include the option of adding additional third-party packages to the OS installation process; it only installs the software that Apple itself includes in the OS installer.

To address these needs, an open-source tool named createOSXinstallPkg is available. createOSXinstallPkg allows you to create an Apple installer package from an “Install macOS.app”. You can use this package for the following:

• Installing OS X or macOS onto an empty drive
• Upgrading existing OS X or macOS installations to a newer version of the operating system

The advantage of using this tool is that a number of system deployment tools for Macs can deploy the installers created by this tool, allowing OS installations or upgrades to be performed by the system management tool already in use by a particular IT shop. One great thing about using this tool is that createOSXinstallPkg will create an installer package that either installs a stock copy of either OS X or macOS, or you can add additional packages to the stock OS install.

When adding packages, there are a couple of guidelines to keep in mind:

1. There is about 350 megabytes of free space available in the OS installer. This is sufficient space for configuration or bootstrapping packages, but it’s not a good idea to add Microsoft Office or similar large installers.
2. The limitations of the OS install environment mean that there are a number of installers that won’t install correctly.

In particular, packages that use pre-installation or post-installation scripts may fail to run properly when those packages are run as part of the OS installation process. To help work around this limitation, I’ve developed a solution which I’ll be discussing later in the post. For more details, see below the jump.