Friends, Mac Admins, countrymen, lend me your ears.
I come to bury Server, not to praise him.
The evil that people do lives after them;
The good is oft interrèd with their bones.
So let it be with Server. The noble Mac Admin
Hath told you Server was ambitious.
If it were so, it was a grievous fault,
And grievously hath Server answered it.
Here, under leave of Server and the rest—
For the Mac Admin is an honorable person;
So are they all, all honorable people—
Come I to speak in Server’s funeral.
Server was my friend, faithful and just to me.
I speak not to disprove what some Mac Admin spoke,
But here I am to speak what I do know.
You all did love them once, not without cause:
What cause withholds you then, to mourn for them?
We interviewed Chip Pearson of Jamf Software this week on the pod, and the episode dropped today, and if you’ll pardon the cliché, it’s our best episode yet. Chip gives us a view into what it was like to be a Mac Admin in the days when Timbuktu was king, when AppleTalk Zones were still a big potential hurdle, and the Mac IIcx was the workstation du jour. He talks about quitting his job one morning, what it’s like to move from consultant to product to chairman of the board.
I remember very clearly seeing Chip speak at Macworld when I was still a very wet-behind-the-ears IT consultnat, and his message of empathy and focus on the role of the individual in tech’s embrace within your organization was very critical.
This was a fun interview, and it’s worth your time. Thanks Chip!
This photo, from the Davis Enterprise, circa 1986-ish?, shows me with my third grade teacher, my elementary school principal, my Dad, and an engineer from the University in the town I grew up in.
I am absolutely a product of growing up in a University town, with involved parents, with schools that saw the future early and had the connections to figure it all out.
The next generation of people that do what we do now are out there, and they have to be more representative of our world than our current community is.
We all come from somewhere. There’s a spark in everyone’s life that makes a job a career. We can be the principal, the engineer, the parent, the teacher. Who are we preparing for what comes next? That’s what Carole Franti, Mary Ellen Dolcini, Adam Bridge and Charles Soderquist taught me, starting with that Apple ][. That’s why I give talks and teach workshops now.
The existing complexity of DEP, though, gives us choices. There’s no reason we couldn’t setup multiple MDMs for multiple departments within an organization, allowing central management of assets, and separate management of devices at the department levels, allowing for good competition between MDM vendors in the mid-level of the environment. Having multiple options is good, because it gives us choice, and it avoids obvious anti-trust complaints.
Read the whole thing. Complex shouldn’t be immediately pejorative. Good management can, and almost should be considered a complex task.
Hopefully by now you’re aware of Apple’s Device Enrollment Program (DEP), which allows you to specify a Mobile Device Management (MDM) server for your devices to check in with during their initial setup process. This applies not just to iOS devices, which substantially benefit from enrollment in MDMs, but also to Macs, which traditionally have had fewer benefits.
That has substantially changed in the last few months.
A month ago, the Mac Admins Podcast sat down with Erik Gomez of Pinterest to talk about using MDMs to install Mac applications – including root agents like Puppet, Chef and Munki. Erik designed a workflow — and built some tools himself — to configure those root agents and engage them in a seamless series of actions for onboarding new staff. The goal was simple: fully utilize DEP and MDM to install their management agents and software management scheme, as well as customize the device in a way that their engineers normally would ahead of deployment.
The experience of rolling out new equipment to new staff, or returning staff, can be a whole lot less hands on for IT Admins, and that’s an excited part of this.
This process is going to talk about several different important parts, and I want to lay out what you need to make this work.
DEP Account – This should go without saying, but you need a DEP Account. That involves getting a customer number from Apple, and if you’ve got a retail store near you, their business team can help with this. Please stop and read the Deployment Program Help if you have questions. Please note: It can take more than a week to get this done, so start early.
Developer Account – This process requires that you have a signing certificate that is signed by the Apple Worldwide Developer Relations Certificate Authority. There can be no substitutes, so you’ll need to join the Developer Program. It’s $99, and you should probably already have this anyway.
SimpleMDM Account – SimpleMDM is one of the few MDMs that support the InstallApplication verb in the mdmclient binary for the Mac so far(1). You can try it out for 30 days with no credit card. Devices start at $30/year.
A Web Server – You’re going to need a place to host your signed application packages and a JSON file. It’s best if it has an SSL/TLS Certificate installed and configured for use.
InstallApplications Script – You will need the InstallApplications project from Github. This is the glue that makes everything else possible. InstallApplications is the actual signed package you’ll be installing from the MDM, which will in turn reference the JSON file on your web host, and then process the packages specified therein. This is a great way to stage a bunch of useful content on the machine that can then be called in a coherent process to take the machine from fresh-from-Apple to fresh-from-your-organization.
DEPNotify – There are few things as bad as a process with no interface. Users can grow confused or impatient if expectations are not properly set. DEPNotify is a good way to message to your users what is happening with their brand new computer.
During Setup Assistant, a machine that is registered with DEP will check in with Apple’s Activation Servers, and based on the hardware model identifier and the serial number, be assigned to the MDM that corresponds with its record in the DEP portal. At that time, the MDM in charge of the situation can deploy pre-stage packages during the Setup Assistant.
That’s where this process comes in. You can create and sign the InstallApplications package with your Developer certificate, and then deploy that LaunchDaemon to the machine in a safe method without ever touching it. InstallApplications works by referencing a JSON file that is stored on the internet that provides a series of package URLs, file locations and file checksums for the packages you want to install on the machine before and after the Setup Assistant completes.
The nice thing about InstallApplications is you only need to rebuild the package if the location of the JSON file — or some of the attendant details for how it’s secured — have changed. Ideally you build it once, and then handle the rest via the JSON file. Once you have selected your pre-stage and stage 1 and 2 packages (of which there can be a number of each, you’re not limited to one package per stage), make sure to capture the appropriate checksums with the shasum -a 256 /path/to/your/cool/package.pkg and embed the values appropriately.
As part of our install, we’re dropping in the DEPNotify binary and the munkitools package into the pre-stage, since they don’t require a user session, and then a trigger for DEPNotify that performs the first login tasks during Stage 1. We’re doing our Munki configuration via SimpleMDM’s support for custom profiles, so those settings are already present when our trigger script runs after the first user logs in. Our script, a sample of which is linked here, kicks off the DEPNotify application, and begins to guide the user through what will follow.
I also wrote a second script that is installed as the last thing our Munki server doles out for install. It issues one last command to DEPNotify and then cleans up the log file. You can later create an uninstaller for DEPNotify that cleans up the application.
Sign this package with your Developer ID Certificate.
Upload this to SimpleMDM as a macOS Package and Configure it to be installed in the default group selected in DEP.
Create the referenced JSON file and place it on your Web Server making sure that the security on the directory matches what you’ve specified in step 1.(2)
Upload the packages referenced in the JSON file to your Web Server.
Check to make sure packages download okay.
Write a first-boot script that launches your software installer, and gives DEPNotify the data that it needs to get things going.(3)
Test this with a Virtual Machine(4). Test it again. And again.
And Now, A Video:
This is what it’s like to setup a machine using Simple MDM, InstallApplications, DEPNotify and Munki together in a seamless toolchain:
It took approximately one full day to set all of this up and get it working like I liked, including the creation of this entry and documentation.
(1) the others are ZuluDesk and Airwatch as of the release of this post. I’ll keep this footnote updated as I hear of more.
(2) Right now, InstallApplication.py really does not like redirections, so make sure you’ve specified the correct URL.
(3) This is going to be the part that takes the longest. Building a good post setup experience for your users is going to be an interesting experience, and I think we’re going to see a lot of different takes on it based on the different schools of thought for user-focused deployment. There’s no reason that something like DEPNotify couldn’t be used over a period of hours or days to inculcate institutional culture to new staff. Play with this, It’s going to be interesting.
(4) Testing with a Virtual Machine is easily done. Using Joe Chilcote’s vfuse, create a new VM from an AutoDMG master. Open the .vmwarevm bundle and edit the .vmx file in a text editor (I recommend BBEdit) and add your Serial Number and Model Identifier. Now start your VM and you’ve got a DEP-enabled VM!
This week’s Techno Bits newsletter has a summary of the Broadcom Wi-Fi SOC exploit, some great links from Emily Kausalik and Charles Edge on macOS Sierra’s logging system, and some backstage sneak peeks into Merriweather Post Pavilion’s new stage house and the network that supports it, as well as a thank you to Walt Mossberg for his incredible career in tech journalism.
Congress has decided, for whatever reason they have chosen to represent as to why they’re acting, and frankly, none of them are too well-explained, that your Internet Service Provider can continue building a file on every site that every device on your home and work internet connection visits.
Ostensibly this is for marketing purposes – i.e., to sell those results to third parties who want to buy them in bulk – and it means that the connection that you pay for each month isn’t entirely your own.
This is, as one might imagination, a frustrating betrayal of trust, more so when you consider that we are not blessed with robust competition in most residential marketplaces, and there are few rare ISPs that can afford to stand on moral grounds against this tactic.
It used to be that you could opt out of the “super cookie” Unique Identification Headers (UIDH) that companies like Verizon are already appending to your HTTP Requests.
Yeah, that’s sleazy. They are trying to make you, their customer, more visible to advertising partners based on your existing actions.
Thanks to aggressive lobbying of the Congress, and an abdication of any desire for an individual right to privacy on the part of Legislative and Executive branches, these communications giants are going to take a second turn at squeezing more revenue out of their networks, and they’re going to do it to their customers without so much as a discount for being their unwilling partners in marketing.
Okay, That Sucks, Now What?
So, what’s a person to do if they want to keep their surfing habits – which in many cases contain personally identifying and possibly embarrassing information – away from their ISP’s prying eyes?
There’s an easy way to help prevent their access, and that’s to use a Virtual Private Network, or a VPN. That’s a way of sending all your outbound internet traffic securely to a third party before it passes through to the internet as a whole.
What’s that look like? Think of it this way: imagine that you want to send a secret letter to a friend. You don’t want anyone in your local post office to know that you’re sending a note to John Smith in Des Moines, Iowa, so you pack up your sealed letter to John in a letter to another friend, Betty Johnson of Dubuque, Iowa, with a note to please mail this letter for you from her local post office. The post office sees that you sent a letter to Betty, but because there are rules against opening your mail, they can’t read it. Then, Betty receives your message, posts your letter to John, and no one’s the wiser.
That’s what a VPN does. It’s a secure way to send all your traffic to a third party to act on your behalf. You can securely wrap your traffic to the Internet to a third party before it gets out to the rest of the internet.
It’s not perfect, but it at least prevents some of the skeeviest trends in local ISPs. Drawbacks to using VPNs include weird results for Location searches, a performance hit to your internet speed, and perhaps the inability to view location-specific programming.
I don’t make anything from a referral to them, but I do use their product and endorse it. It’s an easy VPN to setup. Give it a try if you spend a lot of time on unencrypted Wi-Fi, or if you don’t want your ISP to have access to your surfing history.