Prepare your organization for macOS Monterey

Mike Boylan: Hi, my name is Mike Boylan, and I'm a senior consulting engineer in Apple's Worldwide Field Engineering team focused on macOS deployment and management. I'm really excited to help you prepare your organization for macOS Monterey.

macOS Monterey brings powerful features designed to allow you to connect, share, and create like never before, get things done faster, and work seamlessly across Apple devices. And there are a number of platform changes, new management features, and lots of deployment workflow improvements for IT as well.

In deploying macOS Big Sur, we covered changes to deployment and management for Mac computers with Apple silicon and went deep into deployment workflows with a focus on the macOS Installer. And at WWDC21, we had a lot of sessions for you, covering a wide range of topics relevant to deployment and management of macOS. We'll recap some of the key points from these sessions, but we'll also share updates we've made since these sessions based on your feedback. There are improvements in macOS Monterey throughout all aspects of the deployment life cycle, from initial enrollment, to deployment and ongoing management, and return to service. Let's get started with initial enrollment. Automated Device Enrollment lets organizations configure and manage devices from the moment the devices are removed from the box and enables you to use all available MDM functionality, including marking the MDM profile as nonremovable. Automated Device Enrollment is designed for devices owned by the organization and works best with devices purchased directly from Apple or from participating Apple Authorized Resellers or carriers. We know that some devices may be purchased or donated from outside of the normal channels that support Automated Device Enrollment; and for these scenarios, we're introducing Apple Configurator for iPhone which will be available on the App Store. Apple Configurator for iPhone makes it easy to assign any supported Mac running macOS Monterey to your organization's Apple School Manager or Apple Business Manager, allowing you to take advantage of all of the great device management features that Automated Device Enrollment enables.

Using Apple Configurator for iPhone requires Mac computers with the Apple T2 security chip or Apple silicon running macOS Monterey and an administrator or Device Enrollment Manager user to log in. You simply bring Apple Configurator for iPhone close to the Mac while it's in the Setup Assistant to start the process. Like on iOS, there's a 30-day provisional period where a user can opt out of the Automated Device Enrollment by removing the MDM profile from the Profiles pane in System Preferences. This requires administrator credentials and will also remove the Mac from Apple School Manager or Apple Business Manager. For more information, watch the WWDC21 session "Manage devices with Apple Configurator." Now let's turn to improvements for ongoing management tasks. We've talked about system extensions for a number of years now, and we hope that developers you work with have already made the transition away from kernel extensions. When deploying and managing system extensions, to avoid unnecessary approval prompts to users, best practice is to deploy the configuration payloads to approve the extensions before apps attempt to load them. But we know that's not always possible, so in macOS 11.3 and later, installing a system extension payload changes the state of the extension. For example, if a system extension is already pending user approval, installing the payload will activate the extension. Conversely, removing the payload will deactivate the system extension and mark it for removal on the next reboot of the Mac, allowing for a straightforward removal process.

But to make it even easier to remove a system extension in macOS Monterey, there's a new configuration option in the system extension payload called RemovableSystemExtensions. An app in this list can deactivate its own system extensions, for example, when an app is uninstalled. With this key set, there is no admin password required to remove the system extension, allowing for a fully automated removal.

Many system extensions require more than just a system extension payload to fully configure them. For example, a system extension that is built with the network extension framework may need to set up a content filter, which you can enable and approve using a content filter payload. Some extensions may also require Privacy Preferences Policy Control payloads, and you may wish to manage notifications for critical apps that use system extensions. Check with your system extension vendors on configurations needed to fully enable and configure the solutions, as well as to inquire about their compatibility with any other system extensions that you plan to run at the same time. This is especially important if you plan to use products from multiple vendors together.

For organizations that use FileVault and escrow a personal recovery key -- or PRK -- with MDM, macOS Monterey makes it easier to access Mac computers with Apple silicon. In macOS Monterey, you can boot a Mac directly using the PRK without requiring a password change and an intermediary reboot through recoveryOS. This allows for much faster access to a Mac to troubleshoot or assist users. On this Apple silicon MacBook Pro, the unified login experience, which is new to Apple silicon, is shown. Notice that the login screen is respecting the option to show the username and password field instead of a list of users, even with FileVault enabled. To boot the Mac using the PRK, you can simply press Option-Shift-Return and enter the PRK in the Recovery Key field. Simply press Return or click the forward arrow when finished to boot the Mac.

Let's discuss our recommendation for using personal recovery keys or institutional recovery keys, also known as IRKs, with FileVault going forward. On Intel-based Mac computers, an IRK could be used to unlock a FileVault-encrypted Mac, disable FileVault using the command line, or more commonly, to recover data using target disk mode. Using an IRK at scale is now considered legacy, and an IRK provides no functional use on Mac computers with Apple silicon. Mac computers with Apple silicon have Mac Sharing mode instead of target disk mode, and it requires having access to recoveryOS to use. Alternatively, a personal recovery key, or PRK, is unique per encrypted volume, can be escrowed to MDM, and allows for easy key rotation after use. It can also be used on a Mac directly to access recoveryOS or to boot macOS, as we just showed on Apple silicon. This process for Intel-based Mac computers is similar. A PRK is an extremely robust tool for organizations, and organizations currently using institutional recovery keys should use personal recovery keys instead going forward.

We continue to add additional user privacy protections to macOS. In macOS Monterey, apps or services that require the installation or configuration of pluggable authentication modules -- or PAM modules -- now require user authorization. Authorization can be granted using a Privacy Preferences Policy Control profile from MDM that grants full disk access or access to system administrator files. Many MDMs already grant their agent tools access to these categories, so it's possible your existing workflows won't need to change at all to accommodate this new protection.

The built-in Kerberos extension offers a way to provide directory connectivity to an on-premise, active directory environment without actually needing to bind a Mac computer itself to the directory. In one-to-one deployments, we recommend using the Kerberos extension or solutions like it, along with local accounts, instead of traditional directory binding and mobile accounts whenever possible. We built the Kerberos extension into the operating systems in macOS Catalina, and iOS and iPadOS 13, and it is the replacement for Enterprise Connect on macOS. Enterprise Connect is officially sunset as of macOS Monterey and running Enterprise Connect on macOS Monterey is not supported. The Kerberos extension has some new optional settings in macOS Monterey. You can now specify a preferred Kerberos Distribution Center, or KDC, for your Mac computers to use. And you can limit access to the Kerberos credential to only apps that match bundle IDs in a configured access control list that are explicitly installed as managed. Additionally, you can allow the standard system Kerberos utilities including Ticket Viewer in klist to access and use the credential too. We've also improved the reliability for checking for required password changes. For more details on the Kerberos extension, please check out the "Leverage Enterprise Identity and Authentication" session from WWDC 2020. Since macOS 10.15 Catalina, scripting language runtime such as Python, Ruby, and Pearl have been included in macOS for compatibility with legacy software only. Future versions of macOS won't include scripting language runtimes by default and might require you to install additional packages. If software you use depends on scripting languages, it's recommended that vendors bundle the runtimes within their apps instead. In macOS Monterey, the previously bundled system PHP has been removed. Python 2 was officially sunset as of January 2020 by the Python Software Foundation and isn't recommended to be used. In macOS Monterey, a graphical dialogue will appear when an app tries to use the built-in system Python 2.7. It's important to note that the dialogue displays the calling app information. So if an MDM agent runs a script that you wrote that is calling the system Python, the dialogue may display the name of the agent app, even though they may not actually be using Python in their app at all. For that reason, it's recommended to check your scripts for usage of the system Python and update them as necessary. Future versions of macOS won't include Python 2.7. It's recommended that you install and manage your own runtimes, including Python 3. You can also call the system Python 3 if needed, but that requires the Xcode command line tools to be installed.

In macOS Monterey, using the socketfilterfw command-line tool or MDM to manage the system firewall are mutually exclusive. If any options for the firewall are configured using MDM, the command-line tool will not allow modifying any settings even by an administrator. We've enhanced the MDM manageability of the system firewall in macOS Monterey by enabling the configuration of the logging options, including setting logging to be on and to what level. Currently configured logging options are also now provided to MDM in the security info query to help with compliance reporting. Note that when managing the system firewall using MDM, the options for allowing signed, downloaded, or system apps for incoming connections are always enabled. These map back to the command-line options for allow, download, signed, enabled, and allow, signed, enabled, set to on. There are a number of changes to TLS certificate trusts in macOS Monterey. Underscores in DNS names are now allowed, multiple extensions with the same extenID are rejected, key usage is more strictly enforced, and pathLenConstraints on enterprise root CAs are enforced. For SMIME, certificates with RSA keys less than 2048 bits are no longer trusted.

In macOS Big Sur we enabled managed apps on macOS, including support for managed app configuration and feedback and the ability to remove an app with an MDM command or when a device unenrolls from MDM. New in macOS Monterey, if you use User Enrollment for BYOD environments, managed app data is separated on a different volume, and managed apps that use CloudKit now use the Managed Apple ID associated with the MDM profile. When the app is removed, the data container is erased. Managed Apple IDs also now support iCloud Drive for user enrollments. The organizational iCloud Drive appears as an additional location in Finder. Watch the "Discover account-driven user enrollment" session from WWDC 2021 for more details. In macOS Monterey, Mac computers with Apple silicon now support the 802.11k, v, and r Wi-Fi standards for optimized roaming on enterprise networks. The IPv6-Only-Preferred option is also now supported in DHCPv4 on all Mac computers that support macOS Monterey, which allows IPv6-capable devices to forgo the assignment of an IPv4 address. There's also a restriction available for preventing the use of iCloud Private Relay, a new iCloud+ feature that helps protect a user's privacy when they browse the web in Safari. You can block iCloud Private Relay on a specific network using DNS, but this restriction prevents it from being enabled on the Mac in the first place. If you use proxy auto-configuration, or PAC files, to configure your Mac computers to use a proxy, there are important changes in macOS Monterey to be aware of. Using HTTP URLs for PAC files is deprecated. Web Proxy Autodiscovery, or WPAD, via DNS is not affected by this change. For any other configurations of PAC files though, including WPAD via DHCP option 252, macOS Monterey may attempt to access the PAC file over HTTPS first before eventually falling back to the HTTP URL. Consult with your networking teams about these changes, as only secure URL schemes should be used for PAC files going forward. Now let's talk about an incredibly important aspect of device management for organizations: managing software updates. At WWDC 2021 my colleague Lucy from the Software Update team gave a great session detailing improvements to managing software updates across Apple platforms. That session contained a wealth of information for MDM developers and admins alike, and we'd encourage you to watch it. Here, we'll provide some additional guidance, specifically for you as an admin. First, let's start with the software update command-line tool, as we recognize that a lot of organizations currently wrap tooling around it to manage software updates on macOS. The software update command-line tool is still supported and is not deprecated. It requires elevated privileges to run on both Intel and Apple silicon, but on Apple silicon, it asks for user credentials for a volume owner to install a software update. More details on volume ownership can be found in the resources section we'll discuss at the end of the session. By default, the tool will prompt for these credentials interactively, but macOS Monterey also includes options for passing the user credentials directly into the command. In macOS Monterey you can use the Software Update CLI tool at the login window to install software updates as well. While the software update command-line tool is still supported and you may be able to modify existing tooling or workflows to accommodate the authentication requirement on Apple silicon, you should use MDM and the ScheduleOSUpdateCommand to deploy software updates to manage Mac computers going forward in an organization. Using MDM will help you unify update deployment workflows across both Intel-based Mac computers and Mac computers with Apple Silicon. There are three stages of managing software updates: testing, deploying, and enforcing. Let's start with testing and the ability to defer software updates.

When we release a beta version of an OS, you have time and tools to test the OS in your environment before it's released, including with test plans and focus release notes in AppleSeed for IT. Once an update is publicly released, software update deferral restrictions that you can apply from MDM to supervised Mac computers prevent software updates from being offered to users until a specified period of time has expired. This period of time is configurable from one to 90 days. Update visibility on a Mac relative to the deferral period is based on the publication date of an update and not when a client Mac computer first discovers the update. In macOS 11.3 or later you can set separate, independent deferral windows for major, minor, and non-OS updates such as Safari. And while the maximum deferral window for all update types is 90 days, note that installing a major macOS upgrade as a user requires administrator credentials and running an Install Assistant application. Also, it's really important to note that while deferred updates aren't visible in the Software Update preference pane or in the output of the Software Update command-line tool, MDM still has the ability to install specific updates on devices. In other words, an update does not need to be visible to a user in order for MDM to be able to install it. This gives you the flexibility to, for example, completely skip a particular update in your environment and simply instruct your Mac computers to jump ahead to a newer OS update if you prefer it. Once you've tested, next you're ready to deploy software updates. When using MDM to update a device, MDM sends a ScheduleOSUpdateCommand. The command on macOS has several different modes of operation known as "install actions". The available install actions are DownloadOnly, NotifyOnly, InstallASAP or default, InstallForceRestart, and InstallLater. Let's go through them now. DownloadOnly is useful for both attended and unattended devices to download the update in the background before installation time. NotifyOnly can be used to alert users that there's an action for installation -- neither of these options actually start an install. InstallASAP or Default is the primary update mechanism on macOS. It is ideal for unattended or remote macOS devices or for situations where you want to enforce an update as quickly as possible but still respect applications that may currently need to block a restart for updating, such as if a critical task needs to finish running. Unless an application blocks restart, this action performs the update as soon as possible once the download finishes with an option displayed in a notification for a user to cancel the restart within 60 seconds. In macOS Monterey the 60-second countdown timer is displayed for both major and minor updates. InstallASAP is also the install action that should and can be used for major macOS upgrades using MDM. For example, you can upgrade a Mac from macOS Big Sur 11.5 and later to macOS Monterey using only MDM, without needing to separately download the full macOS installer first and without the use of any scripting using tools like startosinstall.

InstallForceRestart is the ultimate enforcement action for installing an update as it ignores any blocking applications and installs the update as quickly as possible. This is ideal for ensuring compliance by an absolute date as long as the device is online or for unattended or remote systems where it doesn't matter what is happening on the device in the current moment. Note that this action can cause data loss as, again, it doesn't stop for blocking applications, so it should be used with extreme caution. Last but not least is InstallLater. InstallLater allows you to schedule an update for installing that night if possible and is analogous to the InstallTonight option that the standard Software Update system offers to a user. The device will choose a window of time based on machine learning, using conditions such as when the device is least used, for the install to occur which usually happens between 2 and 4 a.m.

A number of changes to make these install actions even more useful to organizations were made in macOS Monterey. Supporting InstallLater with 50 percent or greater battery life will help ensure even greater coverage of enforcement of software updates. Next, all install actions that actually start and install support the use of the bootstrap token from MDM to authorize the installation on Apple silicon, and one is required for enforcing updates without user interaction that happened automatically. Note, however, that if users act on a notification and begin and update themselves through System Preferences they will be prompted for their password on Apple silicon. A user does not need to be an administrator to authorize the update, they just need to be a volume owner. macOS Monterey supports installing OS updates when the standard user is logged into the Mac, as well as from the login window when no user is logged in. This helps ensure compatibility with remote or unattended deployments such as in a computer lab or data center. And in macOS Monterey there's the ability to use the ProductVersion like 12.1 to install an update. This reduces the complexity of identifying available software updates. Your MDM can now make a single, server-side query instead of having to query all of your devices and compare that query with the software update device ID, which is part of the device information your MDM already gets periodically. This makes your update process as simple as selecting a specific version to send to a device. During beta cycles, you can use the same version to install the latest available beta as well. For example, sending 12.1 would install the latest available beta of 12.1, even if your device was already running an earlier beta of 12.1. Now let's go through enforcing updates. As we mentioned earlier, the InstallForceRestart action is the ultimate enforcement action and can be used whenever you need to enforce an update right away. But when you know a defined timeline or simply need to ensure compliance with organizational security policies, the new user deferral option in macOS Monterey is a great choice. The new user deferral quota option lets you specify a maximum number of times a Mac should prompt a user to install an update before the update is enforced. This uses the InstallLater install action with a new key called MaxUserDeferrals. A notification is presented to the user informing them that a required managed update has been requested to install. The title of the notification is Required managed update and asks the user when they want to install it. Expanding the notification gives them options to install the update right away, try to install it that night, or defer it. It also includes the number of remaining deferrals for the user, which will decrease by one each time the user sees the notification -- approximately once per day. If the user ignores the notification or uses a deferral, no attempt to install the update is made that night. This is an important change we wanted to call out from the behavior described at WWDC. Once the maximum number of deferrals is reached, the notification informs the user that there are no deferrals remaining and that the update is scheduled to automatically install that night. MacOS will forcefully install the update as if an InstallForceRestart action was used and does require the device to be connected to power or have 50 percent or more battery life to proceed. If those conditions aren't met, the device will simply try to force the update again the next night. These improvements to managing software updates using MDM in macOS Monterey will allow you to more easily ensure compliance, manage software compatibility across your fleet, and unify update deployment workflows across both Intel-based Mac computers and Mac computers with Apple silicon. We encourage you to continue filing feedback on software update management. Be sure to use a Managed Apple ID from Apple School Manager or Apple Business Manager to file your feedback through the AppleSeed for IT program. Now let's explore a return to service, for which macOS Monterey offers an incredible improvement. macOS Monterey brings Erase All Content and Settings to the Mac. Erase All Content and Settings quickly resets a Mac to its current OS version, cryptographically removing all user data in the process. Erase All Content and Settings is supported on Mac computers with the Apple T2 security chip and Apple silicon. Sending the EraseDeviceCommand from MDM to supported Mac models in macOS Monterey will initiate Erase All Content and Settings by default. The previous erase device behavior -- called obliteration -- is only used as a fallback behavior, and we'll discuss that more shortly. On Mac computers with Apple silicon, any startup security settings that you have modified in recoveryOS are also reset. And we know that you might not want a user to be able to easily erase their Mac themselves, so there is a restriction available from MDM to prevent a user from running the Erase Assistant in macOS -- even as an administrator. A few more things to know about Erase All Content and Settings when initiating it from MDM. The Mac must be booted from an internal, sealed system volume, and it must be booted from the first partition on the disk if there are multiple. If the Mac does have multiple volumes or partitions, they will be removed during the process but external volumes are not erased. Mac computers with Apple silicon must have a bootstrap token available from MDM to authorize the erase. And Intel-based Mac computers with the Apple T2 security chip must be in Full Security mode. And if an EFI firmware password is set, it needs to be cleared before initiating Erase All Content and Settings. Note that in macOS 12.01 and later, MDM can send the SetFirmwarePasswordCommand to clear the firmware password, followed by an EraseDeviceCommand to initiate Erase All Content and Settings without requiring an intermediary reboot between the commands. When one or more of the requirements for Erase All Content and Settings initiated with MDM are not met, by default a Mac will fall back to the macOS 11 behavior called obliteration. Obliteration requires a full reinstallation of macOS before the Mac can be used. You can optionally control this fallback behavior by specifying the new obliteration behavior key in the EraseDeviceCommand from MDM. You can specify whether the Mac should or should not fall back to obliteration, and each option controls the response code sent back to MDM. Check with your MDM vendor on support for this option, as it's useful to ensure you don't accidentally end up needing to fully reinstall macOS when you only intended to Erase All Content and Settings instead. Triggering Erase All Content and Settings from MDM requires a Mac computer to reactivate in recoveryOS. However, we're super excited to announce that in macOS 12.1 and later, Erase All Content and Settings initiated from MDM can be used in combination with Auto Advance that we introduced last year in macOS Big Sur. If connected to Ethernet, the Mac can complete the entire cycle of erasing the device, reactivating in recoveryOS, and rebooting back into macOS to automatically enroll in MDM. These two technologies combined together result in an incredibly fast return to service and reprovisioning strategy for remote Mac computers. Note that on Mac computers with Apple silicon, the language chooser will not be displayed upon reboot into macOS when going through this process. Now we'll quickly cover a few additional changes to be aware of in macOS Monterey that may be useful to your organization. macOS Monterey brings Shortcuts to the Mac. Shortcuts are the future of Mac automation, and macOS Monterey begins a multiyear transition away from Automator. We still care deeply about Automator and everyone who relies on it, so in order to make the transition as smooth as possible, we've built a migration tool that can convert most automated workflows into Shortcuts including with full support for AppleScript and shell scripting. For more details on this transition, watch the "Meet Shortcuts for macOS" session from WWDC 2021. In macOS Monterey, you can now share, play, or present content from another Apple device to a Mac. This is super helpful to allow for easier sharing of schoolwork, giving demos of applications, or to simply more easily mirror or extend your display, just to list a few possibilities. Mac also now works as an AirPlay speaker, and can even function as a secondary speaker to create multi-room audio. The AirPlay receiver feature is on by default and defaults to only accepting devices with the same Apple ID, although this automatic discovery is disabled for Managed Apple IDs. The AirPlay receiver can be turned off or security settings changed in the Sharing pane in System Preferences. Note that the same network option still prompts for permission via notification in Notification Center and requests the user enter a device-specific PIN code. Even when not connected to WI-FI, the Everyone option supports peer-to-peer discovery and connectivity between the sender and the receiving Mac. When initiating an AirPlay connection from a device for the first time, the AirPlay code screen is shown with the PIN code. Once connected, the AirPlay session appears in full screen on the Mac. While not a new feature to macOS Monterey specifically, we did want to highlight the new version of the Apps and Books API in Apple School Manager and Apple Business Manager. This API is used by MDM to assign app and book licenses to your users or devices. The new apps and books API uses asynchronous processing; provides real-time notifications for state changes to assignments, assets, and registered users; and supports increased request sizes. As an example, a deployment of 25 apps to 10,000 users used to take 25,000 requests and can now be accomplished in just 10 requests. This should greatly improve the speed and reliability of large device deployments, whether it's for the back-to-school season in education, employee onboarding events, or large device refreshes. For more details, watch the "Improve MDM assignment of apps and books" session from WWDC 2021. Now let's review some resources to help you be successful in your deployments of macOS Monterey. We strongly encourage you to test new Apple software in your organization before it's released. The AppleSeed for IT program allows any nonstudent Managed Apple ID from Apple School Manager or Apple Business Manager to participate without needing an invitation. AppleSeed for IT allows you to access and download prerelease Apple software for testing in your environment, includes detailed test plans, and puts your feedback submissions into a dedicated queue for organizations. The release notes are also targeted at organizations and you can easily reassign feedback to other colleagues. The Apple Device Deployment Reference is a technical document with information available about MDM payloads, commands, and queries to help you configure devices in your environment, including information about whether or not payloads can be combined; if they're supported for devices, users, or both; and more. It also provides supporting information about infrastructure and services integration. While primarily intended for MDM developers, the MDM Developer Documentation is an incredibly helpful and thorough resource that's available to you too for helping to understand how MDM works and the options available at the protocol level. The Apple Platform Security Documentation provides security information about all software, hardware, and services across the Apple platforms. The AppleCare Professional Support website hosts program information for each of the AppleCare OS support offerings for IT departments and help desks, including AppleCare for Enterprise. Volume ownership information can be found in the Apple Device Deployment Reference and the Apple Platform Security Guide. We have several Apple Support articles available that cover information we discussed today as well. We're super excited about all of the great platform changes, new management features, and deployment workflow improvements in macOS Monterey and hope you are too. Thanks so much for watching.