No longer relegated to the fringe, Macs are fast becoming integral to today’s business organization. As a result, IT can no longer rely on one or two dedicated “Mac guys” to maintain its Mac fleet. Instead, Mac management has become an issue that any CIO or systems administrator may be faced with on any given day.
Along the way, the tools and techniques of managing Macs have changed as well. Pushed beyond their traditional business niches, Macs can no longer be managed independent of other processes and infrastructure. They must be integrated with your existing directory service. They require an efficient, scalable deployment model that hooks into asset management. They require secure, auditable patch management and a device and user management solution that secures each Mac’s core OS components and apps.
In other words, Macs take the same requirements that apply to every Windows PC in your organization, as well as to a growing number of mobile devices. This Mac management guide will help you extend your existing support strategies to Mac workstations, and provide tips and techniques for embracing Macs as they become more prevalent in your business environment.
Active Directory: The hub of modern Mac management
Integration with Active Directory is the foundation for Mac management in the modern enterprise, as the OUs (organization units) in Active Directory can be used as the backbone for nearly any enterprise task, from enabling access to resources to setting group policies to pushing out updates and monitoring workstations. Through Active Directory, Macs gain access to the wide range of Windows Server tools and third-party solutions that key off Active Directory to determine which objects to affect with a given task.
In Mac-only environments, Apple’s own directory service, Open Directory, plays this role. But with Active Directory entrenched in today’s enterprise, extending Active Directory to be the central directory service for your Mac fleet is your best bet. Fortunately, Apple and third-party developers have enabled Active Directory to perform many of the same functions for Macs that it does for Windows clients, whether directly or indirectly.
Apple’s OS X directory service support is built around LDAP and includes a plug-in architecture. The company provides a small set of plug-ins that enable support for Open Directory, Active Directory, and generic LDAP services. The big advantage for enterprises, however, is that this approach allows third parties to create additional plug-ins that offer greater capabilities than what Apple includes with each OS X release.
Apple’s Active Directory plug-in has steadily updated since it was introduced five OS X generations ago, with the most notable improvement in OS X Lion being support for DFS browsing. That said, Apple’s Active Directory support has its limitations, as it is primarily aimed at providing authentication and, on its own, offers almost no client management capabilities.
A Mac joined to Active Directory will have a computer account and you can restrict access to that Mac as you would any PC. You can also grant members of certain AD groups, such as the various admin groups, local admin privileges. Beyond this, the only management capability relates to whether user credentials and home directory items are cached on Mac notebooks so that users can log in when they leave your network and sync automatically when they return.
Some versions of Apple’s Active Directory plug-in have proved problematic in certain Active Directory environments. Because of the scalability and flexibility of Active Directory, troubleshooting these problems can be burdensome. Early versions of Lion displayed issues with Active Directory, though the 10.7.2 update appears to have resolved most of them.
Leveraging Active Directory for Mac client management
Apple has traditionally relied on Managed Preferences for client management. Often abbreviated as MCX, Managed Preferences act like Active Directory Group Policies, providing a powerful, granular system for configuring a complete user environment, including system settings and application preferences. Like Group Policies, Managed Preferences can also be used to restrict access to applications and system components.
Managed Preferences are stored as LDAP objects and attributes in a directory system. Any LDAP schema, including Active Directory, can be extended to support Managed Preferences without having to rely on Apple’s OS X Server and Open Directory to provide client management via Managed Preferences.
There are three primary ways to implement Managed Preferences in an Active Directory environment:
Extend the Active Directory schema: Using Microsoft’s Active Directory Schema Analyzer, you can scan Apple’s Open Directory schema and create LDIF files that can extend the Active Directory schema with all the object data needed to support Managed Preferences data. You can then use Apple’s Workgroup Manager (freely available as part of the OS X Server Admin Tools package) to populate and manipulate that data—pointing to an Active Directory domain controller instead of an Open Directory server running on OS X Server. Workgroup Manager can also perform a handful of user management tasks for Active Directory, though the preferred (and safer) option is to use it only for client management.
OS X Server and augmented records: With Leopard and Leopard Server, Apple introduced what are known as augmented records. In this approach, OS X Server is installed and configured to connect to an existing directory, typically Active Directory. Once joined to Active Directory, the Mac server imports user data and groups from the primary directory into a secondary directory that it maintains. Mac clients connected to this secondary directory rely on the primary directory for authentication, single sign-on, and access to network resources, and the Mac server appends attributes to the primary directory’s records to provide client management and Mac-specific services. Although effective, this approach is better suited for Mac-based departments that are isolated within a larger organization, as it doesn’t scale well and limits administration to OS X Server’s simplified admin tool set.
The magic triangle: This option also requires OS X Server. In this case, however, the server hosts a full secondary directory system that scales through use of Open Directory replication. That server is joined to Active Directory, and clients are joined to both Open Directory and Active Directory. Groups specific to Mac systems and users are created in the secondary directory, then are populated with Active Directory users. Managed Preferences are set using these groups. This solution, which is usually implemented using OS X Server’s advanced administration tools, is more scalable than using augmented records. This scalability, however, is limited to Open Directory’s replication parameters, which are adequate for most environments, but not on par with that of Active Directory.
Device-based management using Lion Server’s Profile Manager
With Lion Server, Apple has introduced Profile Manager, a directory-independent alternative to Managed Preferences. Less of a client management solution than a mobile device management tool, Profile Manager offers the ability to manage both Mac workstations and iOS devices. However, as opposed to Managed Preferences, Profile Manager is device-focused. This enables IT to enroll devices (iPhones, iPads, Macs) and apply policies to them, but these policies are not applied based on user accounts or group membership—just devices.
Being device-focused, Profile Manager doesn’t allow anywhere near the granularity of Managed Preferences or third-party solutions. It simply covers the core needs of client management and allows for self-enrollment by users through a Web-based interface that supports SCEP. When policies are updated, Apple’s push notification system alerts enrolled devices to download the update. This combination makes Profile Manager worth considering as part of a BYOD program, particularly if you will also be supporting employees’ iOS devices.
Profile Manager is easy to implement. There’s no need to worry about schema extensions or multiple directories. If your organization requires minimal Mac management beyond the integration offered by Apple’s Active Directory plug-in, Profile Manager may be worth a look. Keep in mind that Profile Manager requires Lion Server, and it supports only Macs running Lion. Scalability is a factor of Web server implementation, and multiple Profile Manager servers can be used to distribute load. With Apple’s cancelation of the 1U rack-mounted Xserve hardware last fall, ensuring a scalable solution may be difficult, limiting the capability of Profile Manager in many, but not all, environments.
Monolithic imaging vs. package-based Mac deployment
There are two core ways to roll out and update Mac workstations, as there are with Windows PCs. The first is to capture a snapshot of a system to a disk image file, then push that image out to each workstation, either over a network or locally by a connected drive. The advantage of this monolithic-imaging approach is that, once a machine has had an image deployed to it, all software is installed and all configurations are preset.
The other option is package based. You start with a base system (either a stock system from Apple or a minimally configured system image), then deploy additional software or configuration files after the fact. This approach is advantageous when deploying Macs with a variety of application and configuration needs, as it eliminates the need to maintain a large number of images. It also allows you to simply add packages to an install workflow without having to edit or re-create your original system image.
Macs offer one distinct advantage over Windows-based PCs when it comes to monolithic imaging: Because Apple produces both the operating system and hardware, OS X is highly portable. A single image can be rolled out to a variety of Macs and be perfectly functional without further adjustment, providing that the hardware is not significantly newer than the OS X release in the image.
Package installation and patch management
OS X relies on specific file types to install software and updates, much like Microsoft’s .msi format. These package (.pkg) or metapackage (.mpkg) files are read by the OS X Installer service, which installs the bundled executables and support files in the requiste file system directory, usually
/System/Library. This can occur manually, when package files are opened on a Mac, or it can occur unattended or in the background using a variety of tools.
Of course, some applications are installed without the use of package files. These apps often do not require support files, or they create them at first launch. As such, they can be installed simply by copying them to a Mac’s Applications folder or the Applications folder inside a user’s home directory to limit access to just that user.
Other applications, most notably software from Adobe, may use a proprietary installer. For these cases, you can use package file tools to take snapshots before and after installation to create an appropriate package file for the application, if needed. You can also include such files in a monolithic image or use a deployment tool that supports the proprietary format.
Note that package files can simply include files and no actual applications. This makes them an ideal way to mass deploy updated configuration files or documents to specific file system locations.
Apple’s deployment and patch management tools
Apple provides a number of deployment and installation tools. These include Disk Utility for creating system images and Apple Software Restore for deploying images locally or using a unicast or multicast network connection. Package Maker, available as part of Apple’s developer tools, can be used to build package files and code the installer command to install package files in the background, even via SSH. All of these features are available free of charge. (For an overview of these and other mostly free Mac management tools, see “22 essential Mac tools for IT admins.”)
As far as commercial tools available from Apple, OS X Server’s NetBoot, NetInstall, and NetRestore can be used to streamline monolithic image deployment, enabling you to set up a network-based deployment operation for installing a variety of specific package files. This option allows you to combine a small number of base images with specific packages to automatically customize your Mac fleet during deployment. NetInstall can even be configured to roll out nonsystem package collections.
OS X Server also includes a Software Update Server feature that mirrors the contents of Apple’s update servers. This offers two advantages. First, by mirroring updates locally, it improves update performance while reducing the load on your organization’s Internet connectivity. Second, it allows administrators to vet updates for problems before making them available. It does not, however, provide a mechanism for ensuring updates are distributed, and it cannot be used to provide non-Apple updates.