The Classic Mac Operating Systems

The Apple II was released in June of 1977 and changed the world, long before the Mac. It was one of the first mass-produced and therefore actually accessible computers. Back then, if environments had more than one computer, device management meant someone walked around with floppy disks that were used to boot the computer. Large-scale device management didn’t become a thing until much, much later.

The Macintosh was released in 1984 and marked the first rung of the upward climb to where we are today. Between Apple’s System 6 and Mac OS 9 operating systems, Mac management over the network often used the AppleTalk network protocol (which was released in 1985 but only went away in 2009 with Mac OS X Snow Leopard) instead of TCP/IP. In addition to being unsupported by any other platform (although Windows NT Server shipped with a connector and there were third-party tools that could bootstrap a service to host AppleTalk), AppleTalk’s methods of network communication were viewed by many as being unnecessarily “chatty,” which caused networks to slow down. This reputation, other Apple-specific characteristics, and the difficulty of managing Apple devices using Microsoft management tools led to the opinion that many old-timer IT execs still have today: “Apple devices don’t play nice on corporate networks.” They always did, just in a different way than Windows.

Network Protocols

Many of those older IT execs still have questions about whether or not Apple devices will cause problems on modern networks. If an Apple device can hurt a network, then the network has problems. It is true that once upon a time, Apple devices could spew AppleTalk traffic on the network that caused packet storms or other problems. But then, so could IPX or NetBIOS, which were initially released in 1983. The developers of these protocols learned a lot about how to network computers in the past 40 years.

Networking capabilities were initially built into the Apple Lisa in 1983 and initially called AppleNet. AppleNet was replaced by AppleTalk in 1985, and Apple finally dropped support for AppleTalk in 2009, although its use had slowed since the introduction of Mac OS X. Apple was able to join TCP/IP networks in 1988 with the release of MacTCP, which provided access to most types of devices that a Mac would connect with provided there was an agent that could decipher typically socket-based communications for each protocol.

Before Mac OS X, the Chooser was a tool used to connect to network file servers and printers. Shown in Figure 1-1, the Chooser would scan the network for AppleTalk devices and display them, which allowed users to “choose” a device to mount. Those mounts were synonymous with drive letter maps to network shares in Windows and mounted NFS shares for Unix and Linux. Because networks grew and discovery protocols didn’t always find devices on the network, users could also enter a custom IP address to connect to if the host didn’t show up in the list. The custom IP could also be used to connect to other LANs or over a WAN, provided port 548 was open on a host.

A user interface of a window to select a file server. The workgroup server is selected, and two files are displayed on the left side titled AppleShare and LaserWriter 8. AppleTalk Active radio button is selected.

With the advent of Mac OS X in 2001, the Chooser was replaced with the Connect to Server option (Figure 1-2), which had everything required to connect to file servers, WebDAV, and FTP servers available in most standard TCP/IP environments. Apple added Rendezvous to Mac OS X beginning in 2002, which allowed Macs to find devices and services over TCP/IP. Renamed to Bonjour in 2005, this zero-configuration technology uses mDNS (multicast Domain Name System) to allow users to locate (or browse) and connect to devices or services on networks with the same level of convenience that AppleTalk offered but with built-in support for the traditional Windows SMB (Server Message Block)services.

An interface of the connect to server window. There are 2 input fields, server address, and favorite servers. The browse and connect buttons are below the input fields.

The concerns about Apple on corporate networks were valid at times. During the massive rollouts of Windows 95 and then Windows 98, many environments used Novell networks or left IPX/SPX enabled on computers. NetBIOS, and later NetBEUI, were often enabled as well, causing a lot of traffic going over older hubs. When you added AppleTalk into that mix, there could legitimately be just too much traffic for the network equipment of that era. Luckily, AppleTalk is long behind us. Additionally, many switching environments started to ship with Spanning Tree Protocol (STP) enabled during the 2000s. Macs could have issues with Spanning Tree Protocol, especially if AppleTalk had not been disabled. However, Mac OS X slowly phased AppleTalk out in favor of newer protocols like Apple Filing Protocol (AFP) and later SMB. Even AFP became a “legacy” protocol as Apple transitioned the default protocols to SMB over time, and by the mid-2000s, AppleTalk was only there for backward compatibility with old hardware and software.

Once file services (and print services as AppleTalk gave way to standard LPR and other types of printers) were more compatible with other vendors, Apple could turn their attention to more important services. Larger environments naturally looked toward how they could manage devices over that same network connection used for files and printers.

Early Device Management

Devices weren’t managed as intricately initially as they are today. Not only were the network protocols different, but the technology stack was wildly different; there weren’t nearly as many devices being managed from a central location, and we didn’t have 30–40 years of IT wisdom on how to make the lives better for our coworkers, students, or even ourselves. There also wasn’t the expectation of privacy that there is today, which is a key element for managing Apple devices, as we’ll cover over the next few hundred pages. Maybe administrators managed extensions (as Desk Accessories) with Font/DA Mover or launchers. This allowed a school or other environments to install fonts and things like screensavers – but Apple-provided tools for centralized management of Macintosh settings by and large weren’t available reliably until the 1990s.

Apple’s At Ease was an alternative desktop environment released for System 7 in 1991, which provided a simplified desktop environment for multiple users to use and share files, functionality not otherwise supported in the Mac at that time. As At Ease evolved, Apple also released At Ease for Workgroups, which provided client configuration options and a restricted Finder mode. It also allowed for home folders that could be stored on an AppleShare IP Server and with eMate the ability to hand in homework for classes (Figure 1-3). That restricted Finder mode later evolved into a (mostly) multiuser operating system environment in Mac OS 9 and the Simple Finder, which is still around today in modern macOS.

A user interface window. 6 folders are selected and the file menu is opened with a list of options.

The following are few important things to keep in mind as this story evolves through the years:

• At one point, At Ease was a unified tool to manage file shares, printers, settings on devices, and mobile devices (the Newton).

• At Ease provided some semblance of multiple users, but the actual operating system of the Mac didn’t interpret those the way it does today.

• Many of the philosophies available in At Ease are still the same, even though the way those are implemented on devices is now quite different, due to a shift from AppleTalk, Ethernet, Wi-Fi, and then devices that could exist outside a Local Area Network.

• eMate (Figure 1-4) was used to exchange data with devices, including the Newton (when using Apple Newton Works), which made it the ancestor of Apple Classroom (albeit a less feature-rich ancestor).

The e Mate classroom exchange preferences window. There are 4 sections titled Listen for connections on, store student documents in, backup and advanced. The cancel and save buttons are at the button of the window.

At Ease didn’t solve every problem for every use case. Another important shift from this era was the first wave of third-party device management solutions. In August of 1991 (the same year the Internet was born), netOctopus was launched at Macworld in Boston. This kicked off an era of third-party tools that allowed organizations to manage Apple devices. By 1993, when FileWave was released, Apple allowed and even gave active thought to how to put things (like files) in places on Macs. That was the infancy of a centralized command and control environment. The same happened in Windows, where in Windows 3, an administrator could edit .ini files from a central location. That evolved into .zap files and similar formats (now .mst files) that could be distributed from a central location in the upcoming Windows 95 era and beyond. Companies that built similar tools for Windows management exploded over the next decades, while many who focused on the Mac wouldn’t see such meteoric growth until the iPhone.

The next major third party to enter the picture was Thursby Software. They released DAVE, a file and printer sharing tool for the Mac, which bridged the gap to SMB/CIFS shares from Windows servers. Microsoft had an AFP server called File Sharing Services for Mac, but it was never on par with what was needed by most organizations. DAVE’s introduction in 1996 allowed Macs in Microsoft-centric environments to connect to SMB file servers and access files, which in turn meant that Macs didn’t need their own platform-specific file servers in order to get useful work accomplished. Thursby also helped address the gap to connect users to Active Directory with ADmitMac, which allowed Macs to connect to and work like Windows workstations with an Active Directory domain.

The computers of this era left a lot to be desired. The Macintosh II, Macintosh LC, Macintosh Portable, PowerBook, Quadra, Performa, and Centris are mostly overshadowed in organizations that actually need centralized management by the onslaught that was one of the most substantial technological revolutions in history, the PC era. But all that was ready to change.

NeXT

Steve Jobs left Apple in 1985 and started his next company, aptly named NeXT. The first NeXT computers shipped in 1988, with the NeXTSTEP operating system at the core of what would later become Mac OS X when Apple acquired NeXT and brought Steve Jobs back. Therefore, the management ecosystem in NeXT set the tone for how Macs were managed into the modern era.

The most important thing that happened on a NeXT computer was that the first web page was served on a NeXT computer by Tim Berners-Lee in August 6, 1991, at the European Organization for Nuclear Research, CERN. Doom was developed on NeXT – which ushered in a whole new era of gaming. When Steve Jobs returned to Apple in 1997, NeXT’s workstation technologies had matured enough that Apple could begin to replace Mac OS 9 with Mac OS X (which would later evolve into macOS). The NeXT had many obvious user interface similarities to the Mac, as seen in Figure 1-5.

A user interface of a workspace manager. 5 files are displayed on the right side of the window. The center of the page has an administrator window for the local users folder.

As it pertains to the concept of device management, several important things came from NeXT that would later influence the Mac and then iOS. The most important is the object-oriented nature of NeXTSTEP, and the second is the development environment. Ironically, the Unix-derived nature of OPENSTEP is what brought the modern Mac so far, so fast. And the “open” components of the operating system have actively been removed piece by piece as large portions of open source code within the Mac are being removed as well. Still, Darwin, Xcode, and parts of iOS are still hosted and regularly updated on opensource.apple.com, and WebKit and Swift are successful open source projects from Apple. However, Apple owns the licenses for these. Most aspects of a POSIX-compliant OS X that are removed in the transition to macOS are instead components that might result in future legal complications due to different licensing schemes (e.g., MIT vs. GPLv2 vs. GPLv3).

Specific pieces of technology also emerged from NeXT, such as the property list file type (XML-based files that can store key-pair sets of information), which lays the foundation for all modern settings management on the Mac. Objective-C, the Mach kernel, and the Dock likewise surfaced as part of the NeXT acquisition. NeXT also had the Electronic AppWrapper (the predecessor to the App Store), Mail, Chess.app, TextEdit, and, most importantly, Workspace Manager, which seemed a bit like the Mac OS 9 Finder and would later become the Finder for Mac OS X.

Another important and critical part of the evolution of the Mac also began in the NeXT era. In 1991, NeXT introduced support for the 80486 processor. At this point, there was no partnership between Apple and Intel. But the NeXT move to the x86 architecture (Marklar) ushered in an era of an Intel partnership, once Apple acquired NeXT and began to plan the introduction of the new operating system that lasts to this day (although there was a PowerPC chipset port in there through the Rhapsody era). The x86-based architecture did more than make it easier for Apple to buy ready-built chips from Intel; it introduced better virtualization of Windows for the Mac and made those Directors of IT stop and think that suddenly Apple played nice and maybe could be trusted to show up on their networks.

Mac + Unix = Mac OS X

Apple started to integrate NeXT technologies with a new operating system with the code name Rhapsody. Rhapsody included many of the tools administrators still use today. The transition to Mac OS X introduced a more Unix-oriented management framework, which replaced the single-user model in Mac OS 9 and earlier. Mac OS X was a true multiuser experience and marked the start of what would evolve into management policies.

New policy-based management was introduced in the form of Managed Preferences, or MCX (Managed Computing for X). These are still available in /System/Library/CoreServices/ManagedClient.app and allow administrators to prepopulate global system preference domains or control the settings applied in those keys. Those preferences were similar to how the registry in Windows worked and similar to how traditional Mac administrators blocked access to resources like Control Panels in At Ease. For many years, Managed Preferences was the main way that administrators controlled settings on a Mac, and MCX provided a framework that later tools leveraged to provide centralized management of a Mac’s settings.

The Bondi Blue iMac was released in 1998, shortly after Steve Jobs returned to Apple. This led to a quick increase in the number of devices managed in larger environments. Mac Admins soon began to employ the second major wave of third-party Apple device management solutions. These built on the frameworks that came to the Mac from NeXT, which still managed the way things appeared on a Mac but went further and allowed for software packages (.pkgs) and centrally managed preference files.

The first major open source project used to manage Macs was released in 2002. Radmind was initially developed at the University of Michigan. The Casper Suite 1.0 was also released in 2002, which evolved into what’s now known as Jamf Pro. At this point, device management was mostly about how administrators could initially deploy a Mac in a known state, known as imaging, and how to use packages or similar data constructs to deploy additional information and settings onto devices, as you can see in Figure 1-6, which shows Casper 1.0’s package selection screen.

The Casper Admin Console window with Groups, Packages, and Configurations as the main menu. On the left side are 4 input fields titled name, group, info, and notes.

These tools used an agent (or daemon usually) on devices to communicate back to a server and pull down objects to be deployed. That agent pulled commands or configurations down to devices. FileWave and Radmind took a more file-based approach, where they dropped a “set” of files in a location on a filesystem in order to deploy a change on a system. NetOctopus and Jamf used native Apple technologies, like software packages (pkgs), to make changes on devices instead.

By 2008, the community had matured to the point that agent-based management had matured to be on par with what was available for Windows systems through tools like Altiris. In fact, Altiris and other Windows management solutions had agents available for the Mac. Tools with a stronger focus on Apple, such as FileWave, Jamf, and LANrev, could manage Macs as first-class citizens on corporate networks.

In 2008, Greg Neagle began to work on an open source agent for Mac management called Munki. The first public code commits came in early 2009, which opened the way for an open source alternative to Mac management. The use of Munki has grown over the years, and so centralized management has been accessible to environments that previously couldn’t afford it or who needed more customizable workflows than those available with the third-party solutions. With the advent of MDM, Munki also plays a pivotal role in adding agent-based options for environments that also use MDM. Most importantly, Munki brought an almost DevOps-style focus to Apple administration that allowed many administrators to manage Macs in much the same way they manage code.

Management is now a set of policy-driven actions used to achieve a certain amount of idempotency on Apple devices, or the known state a device is in. The first management tasks were to control the way a system looked and the experience a user had to access the applications and data they needed. Some lost their way for a while, if only to make the job easier. Yet since the advent of iOS, they have started to rediscover that goal to improve the user experience, not control it. The less that changed on the operating system, the more control is passed to the user. Therefore, while there’s still a gap in understanding the exact state of a device, administrators now have a good ecosystem that allows for policies that don’t destroy the experience Apple crafts for devices.

Server

Apple has had a server product from 1987 to 2022. At Ease had some file and print sharing options. The old AppleShare (later called AppleShare IP, shown in Figure 1-7) server was primarily used to provide network resources for the Mac from 1986 to 2000; file sharing was the main service offered. Apple also took a stab at early server hardware in the form of the Apple Network Server, which was a PowerPC server sold from 1996 to 1997 that ran the AIX operating system. AppleShare IP worked up until Mac OS 9.2.2. In an era before, as an example, mail servers required SMTP authentication, AppleShare IP was easily used for everything from printer sharing services to mail services. An older Quadra made for a great mail server so a company could move from some weird email address supplied by an ISP to their own domain in 1999.

The AppleShare I P Manager window. Admin and status are the main menus. The web and file admin is not running, but the web and file server is running. The mail admin is not running, but the mail server is running. The print admin is not running, but the print server is running.

Meanwhile, services that provided sockets so other systems could access that data were a central need for NeXTSTEP and OPENSTEP systems. The UNIX underpinnings made it possible to compile a number of open source software packages, and as mentioned earlier in this chapter, the first web server was hosted on a NeXTcube. After NeXT was acquired by Apple, AppleShare IP and services from NeXT were made to look and feel similar and morphed into Mac OS X Server.

The first few releases of Mac OS X Server represented a learning curve for many classic Apple admins and in fact caused a generational shift in who administered the systems. John Welch wrote books in 2000 and 2002 that helped administrators get up to speed. The Xserve was released in 2002, and the Xserve RAID was released in 2003. It took time, but a community began to form around these products. The late Michael Bartosh compiled a seminal work in Essential Mac OS X Panther Server Administration for O’Reilly Media in 2005. Charles Edge (coauthor of this book) released The Mac Tiger Server Little Black Book in 2006.

Up until this point, Apple never publicly acknowledged that businesses or enterprises used their devices, especially for servers. They purchased advertising for the first time to promote the Xserve. Apple continued to improve the product with new services up until 2009 with Mac OS X Server 10.6. At this point, Apple included most services necessary to run a standard IT department in the product. These included the Web (in the form of Apache), mail, groupware, DHCP, DNS, directory services, file sharing, and even web and wiki services. There were also edge case services such as Podcast Producer used to automate video and content workflows. Xsan provided administrators with a storage area network (SAN) in the form of the StorNext clustered filesystem. Apple also acquired a company called Artbox in 2009, whose product was rebranded as Final Cut Server.

In 2009, the Xserve RAID was discontinued, and the Xserve was canceled the following year. The next few years saw services slowly removed from the server product, which coincides with an increased frequency in legal disputes over usability of open source code licensed with specific types of licenses. The Mac OS X Server product was migrated to just an app on the App Store, as seen in Figure 1-8. At that point, macOS Server was meant primarily to run Profile Manager and be run as a metadata controller for Xsan. Products that used to compete with the platform were then embraced by most in the community. Apple let Microsoft or Linux-based systems own the market to provide features that are often unique to each enterprise and not about delighting end users.

A screenshot of the C E MacBook pro specification page. The hostname, computer name and internet are displayed, with a few other options like runtime, version and network interface.

macOS Server was canceled in April of 2022. Today, server products that try to do everything for everyone seem like a distant memory for many at Apple. There is instead a keen eye toward how to make the lives of Apple devices better and provide a clean experience for users. This can be seen by the Caching service built into macOS (moved there from macOS Server) and how some products, such as Apple Remote Desktop, are still maintained.

Apple Remote Desktop

By 1997, the Apple Network Administrator Toolkit, which was used to install At Ease, also came with the Apple Network Assistant. Shown in Figure 1-9, the Apple Network Assistant will look very similar to modern users. Mac Admins could remotely control the screen of a Mac, lock screens, share your screen, copy files, remotely open apps, send messages to the desktop, and perform other basic network administrative tasks over an AppleTalk network.

A user interface of the network assistant for Apple remote desktop. The workstation window is in the center of the page, and a few menu options are at the top.

By 2004, it was clear that there were some better options than a UDP-based protocol to perform screen control. Apple Remote Desktop 2 was built on top of Virtual Network Computing (VNC) but does much more. It also comes with a task server, so it can queue up commands to be sent out. While Remote Desktop can make a specific immediate change or action on a computer, it also provides a great entry point into management tools and makes it easy to test unattended installations.

Now on version 3.9.5 (Figure 1-10), Apple Remote Desktop has gone through a number of different places in the Apple ecosystem. Management commands have transitioned to APNs-based workflows for other products, and Apple Remote Desktop only allows connectivity over a LAN unless you open ports to control devices from incoming WAN connections. Other tools such as Bomgar, TeamViewer, GoToMyPC, Splashtop, ISL, and a host of other solutions can do this; it’s no surprise that Apple hasn’t made such a large investment into a refactor for a product that now costs $79.99 on the Mac App Store and has only 1.7 star out of 5 star ratings. Furthermore, Apple Remote Desktop gets away from a slightly more modern way of thinking at Apple: users should explicitly approve any invasion into their privacy.

The remote desktop page for Apple displays the scanned devices with the name, I P address, D N S name, and A R D version.

Ecosystem Coexistence

With the release of a more modern and flexible operating system, Apple introduced multiple users. This feature led to the ability to have one of those users be sourced from a directory services account. These accounts then gave users the ability to log in to their local computer with the same password used on servers to access their mail and other services provided by an organization.

MCX was developed to use with Apple’s Open Directory directory service built into Mac OS X Server. Administrators could also get policy data via directory services in the form of an extended Active Directory schema that contained MCX data, which is much easier to manage en masse than the local MCX referenced earlier. The reason is that both used similar Lightweight Directory Access Protocol (LDAP) implementations. Not all organizations could extend their schemas (no Active Directory administrator wants to extend their schema), and so techniques were also developed to bind client computers to both Active Directory and Open Directory and allow users and groups hosted in Active Directory to be nested inside Open Directory in order to deploy Managed Preferences to clients without extending the Active Directory schema. This was known as the Magic Triangle.

Many Apple admins’ jobs were once to manage servers. Those jobs now shifted, and now administrators moved to manage cloud services and the states of devices, first with directory services and MCX and then toward more modern management techniques, such as the ones initially introduced to manage iPhones and iPads. This is where profiles enter into the picture, which cover a lot of needs of an administrator, but not all.

iOS Device Management

The presence of the Mac in the enterprise continued to grow, but another big change was on the way. A corporate dogma that evolved out of the Windows ecosystem became a model of how the business of IT was done. Apple developers worked to support the traditional methodologies but rethought the paradigm and started to go their own way. This was made possible by the newfound dominance of the iPhone that accessed Exchange servers and the fact that suddenly employees showed up with these devices and used them at work. Suddenly, companies needed to manage the OS that ships on iPhone, iOS.

The original iPhone was released in 2007, and iOS management initially occurred manually through iTunes. Most needed to deploy apps for schools, so the deployment options started with the ability to drag an app onto a device to install it onto phones over USB cables. Some settings were exposed to iTunes. Back then, iOS devices were registered with Apple when they were plugged into iTunes to use it. Administrators could also back up and restore a device with iTunes, which came with some specific challenges, such as the account used to buy an app would follow the “image” to the new device. Additionally, if the backup was encrypted or not determined, what was stored in the backup and some information might have to be reentered. This led to profiles.

iPhone OS 3.1, released in 2009, came with the mail client in iOS that read and respected any Exchange ActiveSync (EAS) policies. These were policies configured on an Exchange server that gave the institution the ability to limit various features of the device, such as the ability to restrict the use of the camera or to force a password to wake a device up. EAS policies had been introduced by Microsoft in 2005, as part of the Exchange 2003 SP2 release, but had mostly been used to manage Windows Mobile devices.

At this point, Apple got larger and larger deployments, and it quickly became clear that it was no longer tenable to plug devices into iTunes and wait for long restores through legacy monolithic imaging solutions. The first iteration of iOS device management techniques that survives to this day was through profiles which gave control over most of what was available through EAS policies and added additional features. The success of the iPhone 4 in 2010 and the iPhone 4s in 2011 meant administrators needed better tools than iTunes restores and iPhone Configuration Utility to apply profiles. In 2012, the ability to create profiles and apply them to devices was moved into a new tool called Apple Configurator, which is still used to build custom profiles.

Apple Configurator could do a lot more than install profiles. Apple Configurator also allowed administrators to back up, restore, and install apps with Volume Purchase codes from the App Store. These were like coupon codes. Administrators could also build complex workflows that Configurator called Blueprints to do all of these automatically when a device was plugged in. Those options were expanded over time to include automatic enrollment into a Mobile Device Management Solution and the ability to supervise unsupervised devices (which we’ll cover throughout the book).

Mobile Device Management

Apple Push Notifications were introduced in 2009. Those allowed devices to be alerted when there was data available for a given app. The MDM agent was built on top of that technology the following year. MDM, short for Mobile Device Management, was introduced in 2010, along with iOS 4. Initially, MDM was used to manage profiles on iOS, thus why Apple called their MDM service in macOS Server Profile Manager. In addition to managing profiles, three actions were supported in that original release: locate, lock, and wipe.

Apple continues to evolve the device management toolset made available through MDM. The transition also makes the Mac more and more similar to iOS, sometimes disrupting traditional agent-based management when features that tap into then-unsupported areas of the filesystem are introduced. At the same time, the original programs had too many acronyms and were too disconnected – therefore much more difficult to access for new administrators of the ecosystem, who continue to flood in more rapidly than ever to support the platform.

Apple Device Management Programs

The App Store is arguably the reason that iOS is so popular. “There’s an app for that” became the popular catchphrase for television commercials. The App Store debuted in 2008, the day before the iPhone 3G was released. It launched with 500 apps and grew to well over 2 million.

The App Store created a cultural shift in how people use computers. Need an app to manage HR operations? There’s an app for that. Need an app to look up CIDR tables? There’s an app for that. Need an app to make fart sounds? Obviously, that was one of the first apps. Businesses and schools started to use these devices at scale. But there was a gap: in order to get apps to users, administrators had to install them as an App Store user. That meant users used their own accounts to install VPP codes or got gift cards which came with tons of legal and accounting problems, as these apps were basically gifted to personal accounts and could be counted as income.

As with all things, large customers wanted a way to buy apps en masse. The Volume Purchase Program (VPP) was introduced to the App Store in 2010, which allowed customers to purchase apps in bulk. The VPP was akin to large tables of gift codes that were doled out to users, which could be done through Apple Configurator with a fancy spreadsheet. That evolved into revocable codes and then the ability to assign apps over the air, which still required a user to associate their personal Apple ID to an organization (although apps were revocable so it could be reclaimed when employees left an organization). The VPP allotments could then be managed over the air with a Mobile Device Management solution. Recent enhancements included a B2B app store, which has apps that aren’t publicly available, and device-based VPP, which ties apps to devices enrolled into an MDM automatically at setup. That’s done through what was once called DEP.

The Device Enrollment Program (DEP) was launched in 2014 and is now referred to as “automated enrollment.” Organizations need to either be a school or have a DUNS number from Dun & Bradstreet (in order to prove they are a legitimate company) to participate. Enrollment via automated enrollment proves that an organization owns a device, and so Apple provides special management features that allow greater control by a centralized device management solution, such as the ability to force a device background or the ability to skip the confirmation screen before an app is being deployed on a device. Automated enrollment links a purchase order to an organization’s Apple management accounts, so initially only supported the ability to work with a few official Apple resellers. Apple recognized that some devices weren’t a part of DEP for various reasons, so added the ability to enroll iOS devices into DEP through Apple Configurator in 2018.

All of these acronyms can provide unnecessary friction to learn how to work with Apple. Therefore, Apple School Manager (ASM) was released in 2016, which also added the Classroom app into the mix – teachers could manage various features on Apple devices via the app. ASM provides a single portal to manage these Apple services as well as a means to manage classroom rosters. This makes it easier to find everything necessary to set up MDM services. Apple Business Manager was released in 2018, which centralized all of the ASM options applicable to businesses into a new program. As with ASM, organizations now have a single location to obtain VPP tokens and assign servers for automated enrollment-based devices associated with a given account.

Enterprise Mobility

All of the solutions referenced need a third-party device management tool. The first real mobile management solution to gain traction was SOTI, which launched in 2001 to leverage automation on mobile devices. They got into device management when those options became available for each platform. More and more IT departments wanted “over-the-air” management, or OTA management. AirWatch, founded by John Marshall in 2003 as Wandering Wi-Fi, was the first truly multiplatform device management solution that included iOS device management. Jamf, Afaria (by SAP), and MobileIron, founded by Ajay Mishra and Suresh Batchu, in 2007, also built similar OTA profile delivery techniques based on the original MDM spec that Apple introduced for OTA management.

At this point, most OTA management tasks (such as issuing a remote wipe or disabling basic features of devices) were done with Exchange ActiveSync (EAS). As seen in Figure 1-11, administrators could control basic password policies as well as some rudimentary device settings such as the ability to disable the camera. With this in mind, Apple began to write the initial MDM specifications, which paved the way for an entire IT industry segment to be born.

A default properties box for Enterprise Mobility Management. It has the password tab as active, some of the checkboxes are checked, and the input fields have values.

A pivotal moment for Apple device management came in 2011, when BlackBerry announced support to manage Apple devices with their BlackBerry Enterprise Server (BES), which had been created in 1999 to manage BlackBerry devices. This represented a legitimization of sorts for Apple mobile devices in enterprise environments and also an opportunistic play for licensing due to the fact that the devices became such a mainstay in the enterprise. A shift toward UEM began at BlackBerry, which continued until 2018, when BlackBerry Enterprise Server was renamed to BlackBerry Unified Endpoint Manager. By then, BlackBerry was no longer a leading phone manufacturer.

Things quieted down a bit, as vendors struggled to keep up with near-constant updates from Apple. In 2016 after Apple started to publish the MDM specifications guide freely, an open source MDM called MicroMDM was initially committed to GitHub, which made it easier for organizations to build their own fork or implement services atop MicroMDM should they choose. Others crept on the scene as well in those years, such as Absolute Manage MDM, AppTech360, Avalanche Mobility Center, Baramundi, Circle by Disney, Cisco Meraki (by way of the Cisco acquisition of Meraki), Kaseya EMM, SureMDM, Trend Micro Mobile Security, and many others. Some focus on specific horizontal or vertical markets, while others focus on the ability to integrate with other products (like those in a company’s portfolio). With such a wide field of MDM solutions, Apple focused on a great API and did not spend a ton of time on specific features needed for every possible market in their own product called Profile Manager (a part of macOS Server).

A number of family or residential MDM providers have also sprung up, which include Circle by Disney. The one market Apple has not made MDM available to has been the home. Apple has a number of tools they believe help families manage devices, such as Screen Time (built into every Apple device). It’s been touted as a violation of user privacy to deploy MDM for home environments and in fact is a violation of the Apple Push Notification (APNs) terms of service. Apple has also limited what vendors can do in the home space. For example, OurPact, initially launched in 2012, was shut down in 2019 along with a number of other Screen Time apps as they used MDM to control various functions of iOS devices. Some of those have been restored to the app stores, but Apple has gotten more specific about requirements for future acceptance.

MDM isn’t the only feature that began on iOS and ended up on the Mac. In fact, so many options shifted over that the name of the operating system used on Macs was even changed.

iOS + Mac OS X = macOS

Apple once dedicated an entire keynote to “Back to the Mac.” macOS shows a slow unification of features from iOS. This isn’t to say that the operating systems will eventually merge (in fact, Apple has stated they will not and instead split iPadOS from iOS), but concepts inarguably do continue to come to the Mac from iOS.

This began with the App Store, released for iOS and then for Mac in 2011 with Mac OS X 10.6.6. Software updates were later moved to the App Store, which unified how updates are centralized. Software updates for iOS have always been free. Up until 2013, major operating system releases were not free for the Mac. Mavericks was free as was every operating system thereafter. Updates for iOS have always been free (except a couple of releases for the iPod Touch, which were legal and accounting issues more than technical or marketing issues). This is one of the larger shifts in architecture from iOS that has changed not only the Mac but the entire IT industry (although while Microsoft hasn’t made Windows free as of the time of this writing, it is very easy to legitimately get it for free now).

Imaging Is Dead?

NetBoot shipped in 1999 at Macworld. NetBoot allowed an administrator to boot a computer to an image stored on a centralized server. NetBoot was cool but was only adopted in niche environments; given the rapid acceleration of the desktop and the less rapid acceleration of the servers, networks and disk drives used to host and facilitate access to NetBoot servers.

Apple Software Restore then shipped in 2002. It had existed since the Mac Classic days as an internal restore tool, but after the public release, the combination of these formed the foundation of the imaging story for the Mac for the next 15 years. Administrators with a fleet of devices to image could boot a Mac to a NetBoot volume and then, since the hard drive wasn’t being used, could reformat the drive and restore an image to it.

An “image” refers to a digital replica. “Imaging” is when an admin takes a snapshot of the boot volume (and other volumes as well) of a device and then replicates that snapshot onto other devices. The Mac community has often referred to this practice as “monolithic imaging” and usually involved a Mac configured just how someone wants it. That image is captured with a tool like the asr command, which is built into the Mac.

Monolithic imaging first became a common practice around 2004 and evolved so you could stream that image over a network and lay those bits down on a hard drive. Other evolutions involved scripts that ran to normalize the volume or customize the image that could be applied to computers at imaging time like a computer name and other per-device settings. Additional post-flight scripts performed additional tasks on the image which hadn’t been booted, as well as install standard Apple packages during the imaging process.

Imaging then became modular, and tools such as AutoDMG (https://github.com/MagerValp/AutoDMG) were released to build images, and DeployStudio (shown in Figure 1-12) was released to deploy images – both to address issues administrators found with the built-in NetBoot, NetInstall, and NetRestore tools from Apple. These allowed admins to build a master out of packages and dmg files that were then synthesized into an image. As seen in Figure 1-13, these workflows started out a little tough to use but quickly became GUI-driven and much more accessible to new administrators.

The Deploy admin window has the workflow menu on the right selected, with title, description, access group and identifier for the workflow parameter. There are 2 workflows and the second is selected.

3 photos of the Auto D M G software. On the left is the build page, on the top right is the log page with details of logs, and on the bottom right is O S installation window with an installation process.

The methodologies continue to evolve. The device security landscape has changed in such a way that Apple doesn’t seem so friendly to tools that put bits on devices in an arbitrary fashion. Filesystems don’t change often. Apple introduced HFS in 1985 to replace the Mac File System. It went through a few revisions over the decades and most notably became HFS+ in 1998. It then makes sense that Apple would move toward a common filesystem across all operating systems. This led to APFS (Apple File System) filesystem being introduced on March 27, 2017, for iOS and then rolled out to tvOS and watchOS. By September of that year, it came to the Mac in macOS 10.13.

With the move away from imaging I thought for sure that apfs would be the death knell for AutoDMG. Apple has a long tradition of not discussing upcoming changes in public, so listening closely to what they announce at WWDC is critical – and always, _always_, test the betas. In the end apfs turned out to be quite uneventful for AutoDMG itself and the surrounding ecosystem had to bear the brunt of the changes.

—Per Olofsson, creator of AutoDMG

The introduction of APFS to iOS and then macOS gives Apple software engineers a lot of options around how to slice disks, how to leverage volumes to provide device management options, and potentially how to freeze portions of the Mac filesystem from being edited. Most importantly, it means Apple administrators need to embrace a whole new way of device management.

Once volumes are prepared, admins can use tools like Apple Configurator to explode an ipsw file onto an iOS device. An ipsw is signed by Apple, cannot be altered, and is similar to the old monolithic restore process with the exception that administrators can’t install anything into the image before applying the image to devices. The Mac process of imaging evolved to how it’s done in iOS (shocking). Boot a Mac to a network volume (now hosted on the App Store); the operating system is downloaded and installed onto the Mac (now hosted on the App Store). An alternative method is to use the createinstallmedia command to build an operating system installer that can then be used to install Macs without the recovery partition/App Store.

macOS – Unix = appleOS

As it is said with the viking legend of Ragnarok, someday we will return to our roots. Mac management lost part of what makes it work so well in a corporate environment. From 10.2 and on, the Mac community gained momentum, with multiuser operating systems; fast user switching; Active Directory integration; good information security policies; mass deployment techniques on par with Windows, if not better; and a number of other features that made the Mac a first-class citizen.

Apple always played catch-up though. At some point, companies have to realize that the goalpost continues to move to be a first-class citizen on corporate networks. The success of iOS taught Apple that they can redefine corporate dogma rather than just play catch-up – suddenly rather than have their developers told what they did was wrong, they could define where the goalposts went. That mentality started to leak into the Mac. Part of that redefinition is SIP.

System Integrity Protection, or SIP, is a mode for macOS where full sandbox controls are implemented in such a way that parts of the operating system can’t be written to, even if privileges are elevated to a superuser account. There are other aspects of SIP such as how memory is handled more securely and how dynamic libraries can’t be loaded into apps – but the most noticeable aspects for many administrators involved the inability to write into /System folders and/or remotely set NetBoot targets. This philosophy comes from the fact that iOS is arguably one of the most secure operating systems ever conceived (built on generations of learning from previous secure operating systems via its origins as the Darwin UNIX core of macOS).

There are a number of features in iOS that provide such a high level of security on the platform, although arguably the most important is how apps are sandboxed. Every iOS app comes with its own sandbox, which means that apps can communicate with one another, but only if they have what are called entitlements, to do so, which typically involve a prompt so a user can allow a temporary connection between apps through a share sheet or an entitlement to use the app. Consider how many apps ask to use the Camera or access the Desktop. Over the past few years, this design philosophy was added to the Mac with special use cases allowing for various technologies that require their own type of kernel access (like a virtualization framework).

To distribute apps through the Mac App Store for 10.14.4 and below, developers need to turn on an App Sandbox and have entitlements defined for apps in more and more cases. Higher versions of the operating system actually require certain entitlements be explicit in order for the app to get notarized by Apple. Apps that aren’t notarized then can’t be opened. For macOS Catalina, an app does not yet have to be sandboxed to be notarized. The only requirement is to be set as a “hardened runtime.”

Apple has sandboxed part of the operating system. Sandboxing and other security measures are discussed in more depth throughout the book, but there are other ramifications to how the technology is implemented. In a POSIX-compliant Unix environment, administrators with an appropriate level of privileges (e.g., root access) have historically done whatever they want on a device. They’re often called superusers for just this reason. With sandbox, Apple can restrict any type of user from writing to certain directories on the filesystem. While macOS has been certified as compatible with the Single UNIX Specification version 3, or SUSv3 for short, this is more tied to the core of macOS, Darwin, than the layer that an end user interacts with.

Each variant of an operating system seems to have their own way to deal with device drivers, probably more true for UNIX-compatible operating systems than any others. The concept of an extension dates back to the Mac OS Classic era. An extension was a file that basically provided kernel access, which allowed devices to be plugged into computers. Mac OS 9 had a tool called the Extension Manager, which allowed a user to turn these drivers on and off easily. If an extension caused a computer to become unbootable, you could easily boot the computer into safe mode, drag all the extensions out of their folder and into a folder called Disabled Extensions on the desktop, and reboot and viola – the system was good.

In Mac OS X and later macOS, a kernel extension (often referred to as a kext) is code loaded directly into the kernel of the Mac. This allows much lower-level access that’s typically necessary for software that needs to interrupt processes (such as security software) or software that interfaces with physical devices where Apple doesn’t provide an API for doing so. Most operating systems have something of this sort, for example, on Windows there are Kernel-Mode Extensions.

Given how low-level kexts can run, there’s always been a concern about the security of a kext. Kexts required a signature as of 2013 (Maverick). Apple went further to restrict kexts in High Sierra, when Secure Kernel Extension Loading forced a user to accept a kext. Apple disabled synthetic clicking on this screen, so administrators couldn’t programmatically accept their own kext. The exceptions are that an MDM can preemptively enable a kernel extension, and the `spctl kext-consent add` command can do so if you have administrative access on a client computer.

Kernel extensions and MDM enrollments cannot complete without the acknowledgment from a user of what is happening. In general, to force acceptance of kernel extensions and MDM enrollments is another step toward a more iOS-centric Mac. This isn’t to say that admins will lose the ability to access a command line or write code, but as the distribution of Macs increases, those are made more difficult. Management options need to be simpler so they’re more accessible, while also more secure, to keep users safe. While the kernel extension is a uniquely Apple solution, sandbox is actually derived from the sandbox facility in BSD, a core part of trusted BSD. Based on how future options are implemented, admins could still have fully manageable and nerdy tools without the need to sacrifice attributes of the Apple experience they hold so dear, like privacy.

Moving Away from Active Directory

One of the main reasons the Mac was accepted as a standard in many companies was the ability to work within standard Active Directory environments. From Mac OS X 10.2.x until today’s macOS versions, many Mac Admins spent countless hours to refine and perfect their Active Directory bind scripts. Out of that wealth of knowledge about how every part of Active Directory worked, some also realized that it might be wrong to use Active Directory with the Mac. There were some advantages to Macs directly connected to an Active Directory domain, like users could get Kerberos tickets and have password management; it also introduced issues like how to keep login keychain passwords and FileVault account passwords in sync with the password used for the user’s Active Directory account. These password problems were solved by local accounts on the Mac, but local accounts were unable to communicate at all with the AD domain.

NoMAD was sold to Jamf in 2018, and portions are now part of a proprietary product called Jamf Connect. Since the early days of NoMAD, the paid version of NoMAD Login Window (now called Jamf Connect) has since expanded to allow for Smart Card authentication and now works with federated identity providers such as Azure AD, Okta, Ping, and Google.

Rennich introduced NoMAD. In terms of his place in the Apple device management history books, though, almost as importantly, he founded a website called afp548.com. In doing so, he and his cohort Josh Wisenbaker established the foundation blocks for what has evolved into the latter-day Apple admin community. Both went to work for Apple, and others took up the mantle to help forge that community for years to come (both have since left Apple).

The Apple Admin Community

There is a strong community of Apple administrators, which often self-identify as Mac Admins. The community idea is fairly Apple-centric – back to when Guy Kawasaki started the concept of evangelizing the platform as Apple’s Chief Evangelist from 1983 to 1987. There are a variety of ways to interact with the community, which include going to conferences, attending user groups, and interacting with the community online (e.g., via Slack).

Online Communities

The Apple administrative community began to emerge in 2001 and congealed around a few specific places. One was the Mac Enterprise list-serve, from Penn State University. Another was the Mac OS X Server list from Apple. These were active communities that were really sometimes very long email threads, but we all got to know each other. Another was afp548. The port for the Apple File Protocol hosted by Mac OS X Server is 548. The afp548.com website was launched in 2002 by Joel Rennich. It had a little more focus around the server product and later around directory services and imaging or large-scale deployment practices. Both Mac Enterprise and afp548.com are important as they represented the creation of a community built around Apple Administration that wasn’t controlled by Apple (like the forums on Apple’s own support sites).

Over time, email lists can grow unwieldy. Many conversations moved to specialized lists, chat rooms, Twitter, or bulletin boards. For example, in 2011, Jamf created a message list but eventually moved that over to a web portal that now boasts over 40,000 active users and over 30,000 discussions. Other vendors created message boards and communities as well, and the community appeared to fragment for a time. Then came the MacAdmins Slack channel.

The Mac Admins Slack is a unique online community for a few reasons. There is a general sense of thoughtfulness among members. Time and time again I see someone go to lengths to help another member that they have no prior connection with, just for the good of the community. Likewise, there's a strong sense of authenticity. Vendors, like us, can become involved, but we're really there to support the community and not to treat it like a promotional channel. It's also not just a slack. It's a podcast, it's local meetups, and more. Connections may initially be made online, but they can grow outside of it. The community extends far beyond a particular slack channel. The Slack is just a touch point.

—Taylor Boyko, founder and CEO at SimpleMDM

The MacAdmins Slack instance was introduced in 2015. Since then, “Slack” as it seems to lovingly be called has grown to over 50,000 users who have sent over 18 million messages. As can be seen in Figure 1-14, these Apple admins discuss everything from upcoming betas to DEP deployments, imaging, and even local groups for each major city and/or country in the world. More focused than checking for #macadmins on Twitter, more history than IRC, and a great place to ask a polite question and potentially save weeks of hunting for the answer to a problem.

A display page of the MACAdmin page. Part of the right menu contains a list of channels, and the right contains the blog-chat.

The MacAdmins Slack channel is one of the most important things to happen to the MacAdmins community. With over 1100 channels to follow, Slack could further fragment admins, but the fact that so many people are in a lot of different channels actually brings more people together in better contexts. Slack is real time; digest emails always felt a bit less inclusive, and it can be easier not to take something out of context when catching up through a week's worth of digests.

User Groups

Apple has a long and rich tradition of sponsoring, facilitating, helping out with, and sometimes just tolerating user groups. There have been Macintosh user groups since there has been a Mac. Over time, those charged with larger-scale care and feeding of devices have split off into their own, professional user groups. Simply search for a city name followed by MacAdmins, and user groups or meetups with an established local chapter to get involved in can often be found.

More come online all the time (some exist solely online). Many now start out of MacAdmins Slack channels or organize around those. The topics always change, but many of those discussed build up to form a set of best practices that can be summarized in a line in a balanced scorecard, one way to easily visualize how an organization tracks performance of any initiative over time. To see one of those, skip ahead to Chapter 12.

Summary

Apple’s pace of innovation in the early days was astounding. Those first few years can be read about in plenty of business books. That seemed to trail off for a while. After Mac OS X came along, the first ten years seemed to be trying to find an identity for administration. “Words matter” quite a bit at Apple. In 2008, Steve Jobs said, “Why would I do anything for that orifice called the CIO?” This sums up that period of time. Yet that is classic sales – Apple didn’t have a great story to tell for larger-scale management yet.

The Apple administrative community pushed, and Apple learned what larger organizations actually needed the devices to do and figured out how to do those tasks (such as integrate with Active Directory) in a way that preserved Apple values while still providing the tools needed to manage devices en masse.

The tipping point in that evolution was when Apple forged a partnership with IBM in 2014, with Ginni Rometty and Apple CEO Tim Cook (who spent 12 years at IBM) who did interviews (e.g., for CNBC) and were filmed on a walk around campus, looking all kinds of pensive. Since then, a newfound focus on business has tightened and so enterprise adoption has exploded. After all, the largest fleet of devices in the world is the culmination of all the iPads, iPhones, and MacBooks in homes around the world.

As seen throughout this chapter, the more things change, the more they stay the same. The names of the tools have changed: At Ease led to Macintosh Manager, which led to Workgroup Manager, and eventually became what was Profile Manager. In a more SaaS-oriented world, Profile Manager then became Apple Business Essentials (not the code but the very idea of an Apple-branded MDM). The back-end technology for management has changed with each of those names, where we now have MDM as the predominant way to manage devices – and some tools still have agents. While the look and feel of the tools has changed, the mission of each hasn’t changed all that much, much as the buttons still say many of the same words from Apple Network Assistant all the way through to Apple Remote Desktop 3.9.

In this chapter, we laid out the timeline of when various features and components were released. We can’t cover all of the items in this book at the level they deserve, especially given the number of vendors and talented engineers that now work in the Apple space. When that first book on managing Macs in the Enterprise was released, there were about half a dozen management MDM vendors; today, there are well over ten times that, some by companies with valuations in the billions. That doesn’t include the rest of the ecosystem like security tools, backup software, groupware, and other entire software categories this chapter skipped right over. It is possible to look at general themes and provide guidance around each. This guidance begins in Chapter 2, when we look at what the agent-based management solutions do to help manage Macs.