Deploy macOS Big Sur in your organization

Hi, my name is Mike, and I'm a senior consulting engineer at Apple supporting enterprise and education. I'm joined by my colleague Danielle from Enterprise Product Marketing, and we're really excited to take you through a technical deep dive of deploying macOS Big Sur.

macOS Big Sur is our latest operating system released last fall for our Mac computers, and it brings so many new features that we decided to increment the macOS version to version 11. It features an all-new design, updates to apps you love, like Messages and Maps, includes enhanced translation features and privacy protections in Safari, and so much more. Today we'll focus primarily on platform changes that affect IT organizations.

In this session, I'll provide an overview of those platform changes, Danielle will provide a deeper focus on our moving of our Mac computers to custom Apple silicon and the considerations for deployment with that transition, and then we'll both wrap up with specific workflow guidance, including recommendations for one-to-one and shared deployments. Additional resources for this session can be found alongside the recording and will be covered briefly at the end.

So let's get started with platform changes.

Auto Advance is a feature we introduced a few years ago for Apple TV that makes it super easy to set them up at scale by allowing them to be automatically configured simply by connecting power and Ethernet. It's been very successful, and we brought it to the Mac in macOS Big Sur. Here's a quick demonstration of it in action, where you can see just how quickly we reach the macOS login window.

Once a device enrollment profile is assigned to the device using MDM and Apple School Manager or Apple Business Manager, simply plug in power, connect Ethernet, and then power it on.

You can preselect language and region using MDM, and all of the setup screens are automatically advanced.

Your network must support DHCP and must not require a client proxy configuration for this to work out of the box.

Once the process starts, after about 30 seconds of no user interaction, the Mac will quickly reach the login window. Because this workflow is ideal for shared deployments or unattended configurations, it's assumed that user accounts besides the IT administrator account that's often created using MDM will either come from a directory service or be provisioned using some additional helper tool. If you choose to use Auto Advance in a one-to-one deployment, you'll need to consider how the account for the initial user who uses the Mac will be created. Auto Advance is the fastest way to set up a Mac and, combined with startosinstall, which I'll cover later, is a powerful combination that allows for a completely automated, and even remote, upgrade and reinstall of macOS.

Over the years, we've had a variety of different types of MDM enrollment on macOS, including device enrollment, user-approved MDM enrollment, and automated device enrollments, which happened as a result of enrolling using Apple School Manager or Apple Business Manager. Each type of enrollment allowed for managing or restricting more features respectively, with Automated Device Enrollment allowing the strongest levels of device management, as it enabled supervision. In macOS Big Sur, user-approved MDM is equivalent to supervision, greatly simplifying the considerations for device enrollment on macOS.

If a user manually enrolls their Mac using a downloaded enrollment profile and installs it using System Preferences, last year in macOS Catalina, that resulted in user-approved MDM. In macOS Big Sur, it's simply called a device enrollment and results in supervision to allow for full management of the device.

We'll also automatically convert all existing user-approved MDM enrollments to supervised upon upgrade to Big Sur. User-approved MDM is a consideration of the past, and we hope this will greatly help your deployment workflows.

There is a small caveat to supervision for Mac computers with Apple silicon, but Danielle will discuss that later.

MacOS Big Sur brings managed apps to the Mac for both device enrollments and user enrollments. The primary benefit is that MDM can now remove an app it has installed, either by choice or automatically upon unenrollment.

iOS-style managed app configuration and feedback are supported as well. And while custom configuration profiles with custom preferences have been supported on macOS for a long time, Managed App Configuration allows for use with User Enrollment, and in most cases allows for a more tightly coupled configuration within common MDM platforms. For device enrollments, MDM can convert a non-managed app to managed, but converting from unmanaged to managed is not supported for user enrollments.

There are some requirements for managed apps on macOS. The package installing the application must only install a single .app bundle file into the Applications directory, and the application can be removed if it hasn't been moved from the Applications directory. Because apps installed from Apps and Books from Apple School Manager or Apple Business Manager install into the Applications directory by default, this makes them perfect candidates to be managed apps.

Note that Data Separation and Managed Open-In in the context of managed apps are currently unique to iOS and iPad OS.

Custom apps let you meet the unique needs of your organization. And now, you can distribute custom Mac apps. Custom apps can provide a tailored look and feel, security features for sensitive data, special functionality for unique business or school workflows, and much more. They're then made available privately to your organization through Apple Business Manager or Apple School Manager, so that you can then distribute them to your customers or users internally. With macOS Big Sur, a Mac Pro-- 2019 or later-- supports Lights Out Management. This means a Mac Pro can be started up, shut down, and rebooted remotely if needed, meaning no more physical trips to the data center for remedial tasks.

An MDM-enrolled Mac gets designated as a Lights Out Management controller, and when MDM wants to perform a Lights Out Management action on a capable device, MDM sends a command to the controller, and then the controller in turn sends the command to the Mac Pro using a secured and proprietary protocol over IPv6 that leverages industry-standard PKI. Lights Out Management requires macOS Big Sur, and your Mac Pro computers must have a network connection on the same subnet as your controller Mac over IPv6 using Ethernet. You also need to ensure that you have the Lights Out Management payload and a payload configuring a certificate with an RSA key, such as SCEP, deployed to your controller and Mac Pro computers that you wish to manage. Network interface bonding is supported on Mac Pro computers you wish to manage.

Here's a quick illustration. As an MDM admin, you send a Lights Out Management command from your MDM server, and the controller Mac receives the command and then distributes it to each of the Mac Pro computers that you've targeted.

macOS Catalina introduced a read-only system volume. macOS Big Sur takes it a step further by introducing a cryptographically signed system volume to protect against malicious tampering. As a part of this, macOS actually boots from an APFS snapshot. The signed system volume also allows for easier updating of the system, as the update process is now much more similar to iOS and iPadOS.

Because the system volume is cryptographically validated, FileVault works a bit differently in that it no longer encrypts the system volume. However, FileVault can still be used to encrypt user data on the data volume. The general impact of this change for IT should be minimal to none, but it's an important platform change that we wanted you to be aware of.

While interacting with SecureToken at scale was made significantly better in macOS Catalina with the introduction of the bootstrap token, we've expanded how it can be used in macOS Big Sur so that it can be even more useful to your organization. A bootstrap token enables macOS to grant SecureToken to accounts without needing to authenticate separately with an already SecureToken-enabled admin password. In macOS Big Sur, a bootstrap token will grant SecureToken to any user on a supervised Mac by default, including local user accounts. Previously, the automatic granting of SecureToken was restricted to just mobile accounts and the MDM-created IT admin account.

Also, an important change to call out is one that was made in macOS Catalina 10.15.4 for that release and newer. If your MDM supports the Bootstrap Token feature and a bootstrap token has not yet been generated by macOS and stored with MDM, macOS will try to generate one and store it any time any currently SecureToken-enabled user logs in to the Mac. In most cases, this means that a unique per-Mac bootstrap token should be available for use by Mac computers in your organization without additional scripting being required. The bootstrap token also enables additional management features on Mac computers with Apple silicon, and Danielle will cover those later.

System extensions, introduced in macOS Catalina, are APIs to allow developers of apps-- for Endpoint Security, networking, file providers, and printers and scanners-- to build apps that are outside of the system kernel. Vendors who use kernel extensions, or kexts, should instead use these new system extensions to provide existing and new functionality while keeping the system secure.

As IT administrators, we know you use device drivers, file providers, networking, and security apps that may still require kernel extensions. We encourage you to talk with your vendors about getting them to move to newer versions that are built on system extensions as soon as possible. In some cases, that may mean you need to switch vendors.

These newer versions greatly reduce the possibility of kernel panics on Mac computers because they run in user space, reduce the attack surface, and are manageable using MDM, just like how kernel extensions have been able to be handled for a number of years.

Regarding their older equivalents, kernel extensions, new in macOS Big Sur is that when some kernel extensions that should be updated to use system extensions or DriverKit are attempted to be loaded, an alert will warn users that the kexts needs to be updated, and they will not load on macOS Big Sur. There is an exception, however, for kexts that have been allowed by MDM. This is designed to help support the move to system extensions while also balancing the needs of large organizations.

By default in macOS Big Sur, installing a kernel extension and allowing it to load requires a user-initiated action by an administrator to rebuild the kernel cache. We know many organizations don't allow their users to be administrators, so macOS Big Sur provides two options for organizations to enable kexts to load without requiring administrative credentials.

The first option leverages MDM to restart the device and rebuild the kernel cache instead of relying on a user to be involved in the process. There are three options on the RestartDevice MDM command to accommodate this, one of which is new in macOS 11.3.

The first option, RebuildKernelCache, tells the Mac to rebuild its cache and reboot. The optional, accompanying KextPath option allows for MDM to ask specific kexts to be loaded that haven't been discovered by the system yet through an app's attempt to load them. This allows MDM to install an app and load the kexts without the user having to launch the app first before the reboot that rebuilds the kernel cache.

New in macOS 11.3, the NotifyUser option will display a notification to the user and includes a "restart now" option in the notification. When clicked, this performs a graceful restart of macOS, like going to the Apple menu and choosing Restart.

It's worth noting that NotifyUser can be used with the RestartDevice MDM command outside the context of kernel extensions, and therefore without the kext-related options shown here, but it's especially helpful when they're combined.

The second option is to include the new key, AllowNonAdminUserApprovals, set to true, in the System Policy Kernel Extensions payload from MDM. When using this key, a standard user can manually complete the installation of kexts by rebooting the Mac from within System Preferences, Security & Privacy, without having to provide administrator credentials.

To increase data security and prevent unintended profile installation, when a profile is downloaded, before it can be installed, an alert is shown to the user indicating that they need to finish the profile installation in System Preferences. This is similar to what we introduced in iOS and iPadOS 13 and is true for both MDM enrollment profiles and configuration profiles.

To install a profile or perform a device enrollment into MDM, the user must manually launch System Preferences, navigate to the Profiles preference pane, and select the profile. At that point, the user will see a window describing what the profile does and can choose to install it or ignore it. If no action is taken by the user roughly eight minutes after the profile is downloaded, the profile is automatically removed from System Preferences. These additional steps are important to consider in your deployment workflows and documentation.

We continue to make security enhancements that impact several command-line tools IT teams may be using in deployment workflows. With macOS Big Sur, it's no longer possible to install profiles using the profiles command-line tool. All other features of the tool remain the same and continue to work as expected.

Additionally, the networksetup command-line tool doesn't allow standard user accounts to change network settings without an administrator user name and password. Standard user accounts can still turn Wi-Fi on and off, change the Wi-Fi network name or SSID, and read all network settings. This brings the networksetup command-line tool into parity with what a standard user can control in either the Network pane of System Preferences or the Wi-Fi menu in the menu bar.

macOS Big Sur also prevents the use of the security command-line tool to add certificates to the system keychain without interactive authorization from an admin user. This means it's no longer possible to trust a root certificate across the entire system without either an admin explicitly authorizing it or it being installed using MDM.

Many changes were introduced in the areas of software updates in macOS Big Sur. First, as I mentioned previously, macOS has adopted an update mechanism similar to that of iOS. This allows the updater to make changes to the system before you ever need to reboot when doing a software update. This significantly reduces the downtime of the system while installing a software update, which provides a better user experience. You can specify deferring major upgrades and minor, security, beta, and app updates for macOS for up to 90 days.

New in macOS 11.3 is that major macOS upgrades, minor macOS updates, and non-OS updates can each be deferred with separate deferral windows, meaning three different possible deferral windows, each up to 90 days.

When sending the ScheduleOSUpdate MDM command to install a macOS software update, MDM can force the installation of the update and, if necessary, force a restart.

If you've been using the softwareupdate command-line tool to ignore specific updates or set a custom software update catalog, note that those flags have been removed in macOS Big Sur, and managing software updates using MDM is the way forward.

On macOS, there are two types of services within Privacy Preferences Policy Control: user and system. User services are granted by individual users and grant only access to processes operating within that user's session-- for example, access to a user's camera or microphone. System services, in contrast, may only be granted access by administrators but authorize the service for every user on the system. Some services are especially privacy-sensitive, such as Camera, Microphone, Screen Capture, and Listen Event. While they can be configured using MDM, they can only be denied and not allowed.

In macOS Catalina, standard users were able to approve their own apps for Screen Capture, but in macOS Big Sur, admin authentication is required. However, in macOS Big Sur, MDM can specify apps that standard users can then approve themselves for both Screen Capture and Listen Event. This helps ensure a balance between the need to configure devices at scale while still empowering users to make informed and conscious decisions about apps or services that need to access particularly privacy-sensitive services.

The Authorization key can accept a value of AllowStandardUserToSetSystemService for Screen Capture and Listen Event service entries to enable this feature. After it's set, the Security & Privacy preference pane makes a clear visual distinction in the table list for which apps can be approved by the standard user. The Authorization key replaces the previous Allowed key, which was only Boolean true and false, but we support both keys for other service types in macOS Big Sur to help ease the transition.

For machines that are upgrading to macOS Big Sur, any entries that were approved in previous versions of macOS will remain approved upon upgrade.

macOS Big Sur includes a number of new features and enhancements for SSO extensions and the built-in Kerberos extension. First, MDM payloads configuring SSO extensions can now be installed on the user channel, and settings configured on the user channel take priority over any settings configured on the device channel.

Improvements were made for how Per-App VPN is handled for SSO extensions, including that associated domains now work with Per-App VPN.

SSO extensions now also receive more information about the calling app that's trying to use the extension.

There's a new profile removal operation too. When an MDM profile configuring an SSO extension is removed from the device, extensions now have a short window of time to sign out, clean up files or keychain entries, revoke tokens, or perform other cleanup actions as necessary.

For more detailed information on SSO extensions and improvements in macOS Big Sur, please watch the "Leverage Enterprise Identity and Authentication" session from WWDC 2020.

The built-in Kerberos extension also includes a number of new features. If you're not familiar with the built-in Kerberos extension, it 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.

It offers a number of features, like password synchronization and automatic Kerberos ticket management. We built the Kerberos extension into the operating systems in macOS Catalina and iOS and iPad OS 13, and it is the replacement for Enterprise Connect going forward.

We now support user channel profile delivery for configuring the Kerberos extension. This improvement can allow for user-level certificate identities for use with certificate-based Kerberos or PKINIT.

We also now support configuring the Kerberos extension for app to Per-App VPN on macOS. The Kerberos menu extra and the AppSSOAgent must be added to the app-to-Per App VPN payload to take advantage of this improvement.

There's now more control for IT over the initial login experience, including a new MDM configuration option to delay the first login prompt and a new flag on the AppSSO command-line tool to manually trigger the initial login prompt for when it's most convenient during your deployment process.

The menu extra now more accurately represents the state of the extension to the user and, when clicked, provides additional information about the state of the network and credential.

And lastly, the user interface is now customizable too, including the ability to set a custom identity name as well as custom help text.

Here's an example of the identity name being customized along with the custom help text.

Regarding Enterprise Connect, macOS Big Sur is the last release to support Enterprise Connect.

Please test your workflows and deployment methodologies using the new Kerberos extension, and engage your Apple teams for workflow and migration guidance. A user guide for the Kerberos extension, which includes migration guidance from Enterprise Connect, is available from apple.com/business on the IT page under "Identity Management Resources." That's a summary of the most important platform changes in macOS Big Sur. I'd encourage you to check out the AppleSeed for IT release notes and the MDM Settings Guide for IT for all of the latest updates.

Now over to Danielle to discuss the transition to Apple silicon. Thanks, Mike. Mac is transitioning to its own custom silicon, and it started this transition in November 2020 with the M1.

This gives Mac new and exciting performance as well as powerful new technologies. This change allows for common architecture across all Apple products, making it easier for developers to write and optimize their apps for the entire Apple ecosystem. We will continue to support Intel-based Mac computers for years to come. There are some important considerations with Apple silicon in the context of deployment and management that you should be aware of. Let's cover those now.

A big consideration to the move to the new processing architecture is application compatibility. macOS Big Sur includes technologies that ensure a smooth and seamless transition to Apple silicon. Using Universal 2 application binaries, developers can easily create a single app that taps into the native power and performance of the new Mac computers with Apple silicon while still supporting Intel-based Mac computers.

Developers can easily convert their existing apps to run on Apple silicon, and for the first time, developers can make their iOS and iPadOS apps available on the Mac without any modifications.

New in macOS Big Sur 11.3, MDM can install iOS and iPadOS apps on Mac computers with Apple silicon.

With the translation technology of Rosetta 2, users can run most existing Mac apps that have not yet been updated, including those with plug-ins.

As Rosetta cannot translate kernel extensions, kernel extensions must be recompiled to run on Apple silicon if they're needed. But vendors should adopt system extensions instead going forward.

The Hypervisor framework allows for virtualization to be possible, including the ability to run Linux.

Let's talk about Mac Sharing Mode. Mac computers with Apple silicon do not have Target Disk Mode. Instead, they have a feature called Mac Sharing Mode that uses SMB for connectivity over Thunderbolt or a USB cable. Because it's file based, block-copying data over this interface using tools like asr, or Apple Software Restore, are not supported.

Once a Mac has been set up with a user account, if FileVault or Activation Lock is enabled, using Mac Sharing Mode requires authentication.

Mac Sharing Mode provides access to the macOS volume in its entirety, not just access to the user's home folder.

The host Mac with Apple silicon shows up on the target Mac you're connecting it to just like a mounted network share, and all you need to do is connect as guest.

Mac computers with Apple silicon have a similar macOS recovery environment, called recoveryOS, that you're used to accessing today. However, instead of using Command plus R, you access it by holding down the power button at startup.

When reinstalling macOS from the recoveryOS, the latest available update for the major version of the macOS that you're currently running is installed. For example, if you installed 11.1 on your Mac, but now 11.3 is available, recoveryOS will install macOS 11.3.

In the case where something is wrong with recoveryOS or it needs to be reinstalled, instead of using Internet Recovery, like on Intel-based Mac computers, Apple Configurator 2 can reinstall it through the Revive option.

Apple Configurator 2 can even install a fresh copy of the latest version of macOS during the process if you choose the Restore option.

This makes Apple Configurator 2 a great option for rapid return to service on Mac computers with Apple silicon. Note that upgrading macOS in place is not supported using the Apple Configurator 2 recovery mechanism.

On Mac computers with Apple silicon, macOS has a new unified login experience. The unified login experience allows for new features even when FileVault is on.

It supports a richer UI with accelerated graphics that is consistent with the look and feel of macOS. This experience is made possible by being able to fully boot into macOS without requiring a user to unlock the system. For example, the user name and password view is now supported if you choose to use that view instead of the default list of users. It also has built-in support for authentication with CCID- and PIV-compatible smart cards and includes VoiceOver support for greater accessibility.

On Mac computers with Apple silicon, the ability to manage software updates and load kernel extensions is automatically enabled for devices enrolled into MDM with Automated Device Enrollment, and it leverages the bootstrap token. To cover that small caveat to supervision that Mike mentioned earlier: For devices that are supervised using Device Enrollment, which would have previously been known as user-approved MDM, reduced security can be manually enabled in the Startup Security Utility to allow MDM to manage kernel extensions. This is not necessary for MDM to manage software updates to the latest version.

Mac computers with Apple silicon introduce the concept of ownership.

Ownership can loosely be defined as the user who has first claimed the Mac for configuring it for their use and is not tied to true legal ownership or chain of custody. Ownership in this context defines who is authorized to make changes to the startup security policy for a specific install of macOS. The startup security policy defines the restrictions around which version of macOS can boot on Mac computers with Apple silicon as well as how and if third-party kernel extensions can be loaded and managed.

Ownership is backed by cryptography protected in the Secure Enclave and should really be more of an implementation detail versus a primary consideration for deployment operations.

However, because security policies are specific for each installation of macOS, before you can perform certain installation actions, such as installing an additional copy of macOS, you may be prompted for a current user's credentials, and more specifically, a current owner's credentials. You'll also be prompted for an owner's credentials before making any changes to the startup security policy for a specific macOS installation in recoveryOS. It's possible to be an owner but not be an administrator, but certain tasks requiring ownership will check for both. For example, modifying startup security settings requires being both an administrator and an owner.

Installing software updates on Mac computers with Apple silicon also requires owner authentication before the installation can begin, but remember that managed devices also leverage the bootstrap token from MDM.

So that's a summary of changes related to deployment for Mac computers with Apple silicon. Now, Mike will discuss deployment workflows, including best practices for both one-to-one and shared deployments.

Thanks, Danielle. I'd like to start this section by spending some time talking about the macOS installer. It's critical to the installation of macOS, and it contains powerful automation tools for IT to help with various deployment workflows.

We're proud to be able to offer eight years of hardware support in macOS Big Sur. The macOS Installer will run on most Mac computers that date back to 2013.

Your deployment model and distribution method for the macOS installer will determine the best way to acquire it. Historically, in most cases for IT-driven workflows, including the ones I'll go through shortly, acquiring a single copy of the installer from the Mac App Store or System Preferences has been the best method. Depending on your IT policy, if users can upgrade their Mac computers themselves, they can also simply leverage the Mac App Store or System Preferences and download the installer.

You can acquire licenses for the macOS installer from Apps and Books within Apple School Manager or Apple Business Manager for use with distributing from MDM. And another great option for acquiring the installer is an option introduced last year in macOS Catalina for the softwareupdate command-line tool that allows you to script the download. I'll cover this in more detail shortly.

Once you've acquired the installer, you'll want to think about how you distribute it to your Mac computers. You can remotely copy it to your Mac computers using your preferred tool of choice. You could place the installer on external media, such as a USB thumb drive. You could push the installer application directly using MDM as an app acquired through Apps and Books in Apple School Manager or Apple Business Manager. Or as I mentioned, since macOS Catalina, you can easily script the download, potentially directly on the target Mac.

Since macOS Catalina, the fetch-full-installer flag on the softwareupdate command-line tool automatically downloads the latest full copy of the macOS installer available in the software update catalog. You can also specify a specific version using the full-installer-version flag, assuming that version is still available in the catalog. As a quick note, in macOS Catalina, you may have needed to use that flag even to download the latest installer, but that's not necessary in Big Sur.

In Big Sur, you can use the list-full-installers option to see a listing of available installers for download, but note that the listing is customized for the Mac that the command is executed on and will only include installers dating back to the oldest macOS version that was available for that Mac.

When used with startosinstall, which I'll cover soon, this can enable a completely automated download and installation or reinstallation of macOS.

Once you have a copy of the macOS installer, there are many ways to actually start the installation of macOS Big Sur. Having many choices enables a lot of flexibility in many different workflows. In this next section, I'll go through the methods shown to start the installation of macOS. Many of these installation methods also leverage content caching to help reduce internet bandwidth utilization on your network. Let's start with the command-line tool startosinstall.

startosinstall is located inside the macOS installer's Contents and Resources folder. It allows for automated workflows using scripting, and the tool has a number of flags that make it a powerful tool for upgrading or reinstalling macOS. One of those flags is eraseinstall. This flag is useful for reinstalling macOS to its default state. It requires Apple File System, or APFS, as it creates a new volume in the APFS container, installs macOS to it, restarts, and then removes all of the other volumes in the same container, including your previous boot volume. If you want to preserve those other volumes, you can use the preservecontainer flag. The end result is that you have a clean installation of macOS, as if you had manually erased the internal storage first using Disk Utility.

Another powerful flag is installpackage. This flag enables you to have the macOS installer install any number of packages for you after the installation of macOS finishes.

If you need to install more than one package, just pass multiple installpackage flags into the command, each with a path to a different package.

If you combine eraseinstall and installpackage, you can take a machine that was recently handed back in to your help desk and reinstall macOS and any other packaged applications and it have it be ready to hand out to a new user.

macOS Catalina and macOS Big Sur install all packages passed to the command with the installpackage flag in the order in which they are passed to the command. Note that using startosinstall on Mac computers with Apple silicon requires passing administrator owner credentials into the command. Run the command with -h to view additional usage information.

There is another command-line tool inside of the installer called createinstallmedia that allows you to create a bootable installer for use with installing macOS. You can run it with the -h option to get usage information.

This tool is helpful if you have many machines you want to upgrade and have limited network resources. Using the installer on external media has a minimal network impact during installation, as nearly all of the files necessary for installing macOS are located on the external media itself.

There is a flag on the tool called downloadassets which will predownload Apple T2 Security Chip firmware used during macOS installation on Mac computers with the Apple T2 Security Chip.

Note that internet connectivity is still required on a Mac when installing, even when using that flag, as the operating system on Mac computers with the Apple T2 Security Chip still needs to be personalized for that hardware during installation, which requires connectivity to Apple servers.

Also note that while booting from external media is disallowed by default on Mac computers with the Apple T2 Security Chip, it can optionally be allowed. Booting from external media is allowed by default on other Mac computers, including those with Apple silicon.

Using recovery is another option to install macOS Big Sur. There are three forms of recovery: the local one to an Intel-based Mac, which is the macOS recovery partition, Internet Recovery for Intel-based Mac computers, and recoveryOS along with Apple Configurator 2 for Apple silicon.

For Intel-based Mac computers, you can boot to the local macOS recovery partition by pressing Command-R at boot time, and that allows you to reinstall the latest version of macOS that was already installed on your Mac.

Internet Recovery for Intel-based Mac computers, which is similar to macOS Recovery but is handled over the network by booting to servers in Apple's cloud, is available even when something may be wrong with the local recovery partition on the Mac. There are several different boot keys for Internet Recovery, but the most commonly used is Option-Command-R, which installs the latest possible version of macOS. When using recovery, either local or Internet Recovery, you can optionally use Disk Utility to manually erase the internal storage before installing.

Note that booting to the latest version of macOS in Internet Recovery on Mac computers with the Apple T2 Security Chip is dependent on the firmware version of the chip at the time you try to boot to Internet Recovery. You can update it separately from macOS if necessary by updating the T2 chip firmware in DFU mode using Apple Configurator 2.

Danielle discussed the new recoveryOS and features in Apple Configurator 2 for Mac computers with Apple silicon earlier.

Finally, if allowed by your IT policy, users can also install macOS Big Sur on their own using the install assistant from the Mac App Store or System Preferences. This is the same experience as consumers at home and provides users with a graphical walk-through of the installation steps. It does require administrative privileges to begin installation. Now I'll hand it back to Danielle.

Thanks, Mike. Now that we've covered ways to install macOS, let's move on to covering some recommendations for specific workflows, including both one-to-one and shared devices. I'll cover initial deployment, upgrading, and return to service.

Let's start with initial deployment.

For initial deployments of Mac computers in a one-to-one environment, the best experience for both users and IT is to leverage an out-of-the-box workflow that uses MDM and Automated Device Enrollment as part of Apple Business Manager and Apple School Manager.

Automated Device Enrollment enables supervision and enables kernel extension management and software update installation capabilities on Mac computers with Apple silicon.

Automated Device Enrollment allows IT to customize and streamline the setup experience for their users by enabling the ability to skip any of the common setup screens that would normally be seen during a consumer setup of the device.

During initial setup of the device, MDM can hold the devices in the Setup Assistant until they're configured with the most critical apps and configurations for first-time use. We encourage all organizations to use local accounts where possible for one-to-one deployments. For more information on why, take a look at the "Leveraging Enterprise Identity and Authentication" session from WWDC 2020.

For shared environments, we also recommend that you use Automated Device Enrollment for all the same reasons. Using the new Auto Advance feature allows for a truly zero-touch setup and is incredibly powerful when combined with the startosinstall that Mike discussed earlier.

Because multiple users are using the Mac, a directory service or identity provider helper tool often provides access to accounts. In high-traffic areas, such as a library or computer lab, consider an account expiration and removal strategy to help clean up local home folders. Whether you script this yourself or use the built-in feature of Mobile Accounts to automatically expire after a given period of time, it's up to you. Now let's look at upgrades.

When upgrading to macOS Big Sur, you can leverage one or many of the ways Mike covered earlier when he discussed the macOS installer. Ultimately, it will be up to you to decide which option works best in your environment, but there are many available to accommodate different situations and workflows. Whether to upgrade in place or erase and upgrade is also up to you.

Now let's look at return to service.

For return to service, the eraseinstall flag in startosinstall is a great option because it's supported on all Mac computers and can handle both upgrading and erasing a Mac without any additional considerations or configurations required.

On Intel-based Mac computers, you can use Internet Recovery. And because in this context of return to service, be sure to erase the internal storage first before reinstalling macOS.

On Intel-based Mac computers and those with Apple silicon, you can use macOS Recovery, recoveryOS in Apple silicon, or an external media workflow. Again, be sure to erase the internal storage first using Disk Utility or use automation features built into some provisioning tools to do so.

Note that running startosinstall from the recovery environment is not recommended going forward and is not supported on Mac computers with Apple silicon.

For Mac computers with Apple silicon, you can use Apple Configurator 2 to reinstall macOS, as discussed earlier. Note that using Apple Configurator 2 always installs the latest version of macOS at the time you perform the restore.

So that's a summary of deployment workflows, including recommendations for both one-to-one and shared devices, initial deployment, upgrading, and return to service.

Lastly, to wrap up, let's take a look at available resources.

While primarily intended for MDM developers, the MDM developer documentation is also an incredibly helpful and thorough resource that's available to IT for helping understand how MDM works at the protocol level.

The MDM Settings Guide for IT is a technical resource with information about payloads available from MDM to help you configure devices in your environment. The Deployment Reference for Mac is a technical document on the topics we covered today. The Apple Platform Security documentation lists all software, hardware, and services features across platforms. The AppleCare Professional Support website hosts program information for each of the AppleCare OS Support offerings for IT departments and IT help desks.

If you're interested in testing new Apple software, any non-student Managed Apple ID from Apple School Manager or Apple Business Manager can participate in our AppleSeed for IT program. This program allows you to get access to prerelease Apple software for testing in your environment, includes detailed test plans, and puts your feedback into a dedicated queue for filing feedback where issues and enhancements are reviewed by a team focused on education and enterprise. The release notes are also targeted at education and enterprise, which allows us to highlight any impactful changes or issues in the operating systems for organizations.

Finally, here is a list of Apple Support articles related to the topics that we've discussed.

We hope you take advantage of those resources and all the updates that have come to macOS Big Sur and Apple silicon.

Thank you.