Manage software updates in your organization

My name is Lucy Zhang, and I'm a software engineer on the Installation and Software Update team. I'll be talking about managed software updates for macOS, iOS, and iPadOS today. Software updates are critical to everyone using Apple products. Updates bring new security enhancements, like notarization and the sealed system volume in macOS Big Sur. They enable all the latest features, and maybe most importantly, that's how you get all the new emojis. Our platform makes it easy to update your device. In fact, 86% of all iPhones introduced in the last four years use iOS 14. However, in managed environments, you need more control over this process. When managing a fleet of devices, you want to keep them up to date, but you need time to test updates before releasing them, to ensure that the OS is compatible with your software. After your testing is complete, you want to ensure that updates are installed as soon as possible, while minimizing disruption to the user. In this session, we will first explore the programs and restrictions that allow you to test beta and newly released software updates. Next, the MDM commands for deploying updates. And finally, I can't wait to tell you about a new way you can ensure users get updated to the latest version you're ready to support. Let's get started with testing updates. When Apple releases a beta OS, you have time and tools to test the OS in your environment before it's released. AppleSeed for IT help you access and test new Apple software while it's in beta. Any non-student Managed Apple ID from Apple School Manager or Apple Business Manager can participate in the program, which gives you access to pre-release Apple software for testing in your environment, and includes detailed test plans and a way to provide feedback. Once the update is publicly released, you may still need time to test, and you don't want the update to be available to all your users yet. For that, you have deferral. Deferral prevents supervised devices from offering software updates to users, until a specified period of time has expired since those updates were published by Apple. When you apply a deferral restriction, the default delay is 30 days since update publication. You can also specify a custom value between 1 and 90 days. When an update has been available long enough for the specified delay to expire, that update is offered to users as part of the standard software update notifications and update process. These restrictions give you more granular control over the Software Update interface in System Preferences. The deferred updates restriction only affects the Software Update interface. It does not change the behavior of MDM commands. Even with a restriction set, MDM has the ability to send specific updates to devices. For iPhone, iPad, and Apple TV, deferring software updates is available in iOS 11.3 or later, iPadOS 13.1 or later, and tvOS 12.2 or later. When you defer updates, you set the same deferral window for major and minor updates. For Mac computers, deferring software updates is available in macOS 10.13 or later. In macOS 11.3 or later, an admin may now choose to delay major releases for longer than minor releases. That way, users can still benefit from important security updates, while the admin works to approve the latest major release for production in their environment. These are the keys that you can set in a profile to install on the Mac computer. Use the forceDelayedMajorSoftwareUpdates key to defer a major release. With this key, you can still receive minor OS and security updates, while deferring a major OS update. There may be times where you want to separately defer a minor release, and you'll use the forceDelayedSoftwareUpdates key to do that. And for separately deferring supplemental updates, you'll use the forceDelayedAppSoftwareUpdates key. If a deferral type is enabled, but there is no corresponding deferral period set, we will fallback to using the old key, ManagedDeferredInstallDelay. When there are deferral restrictions in place, this is how the software update preference pane appears on macOS. Let's explore how deferral might work. Back to the timeline, you've now deferred an update and continued testing the new OS for compatibility in your environment. Once you've confirmed the OS and completed testing, you're ready to push it to users. You want devices to update when users are ready, and it's not intrusive to their workflow. So let's explore deploying updates. There are a few steps to install the right update on the right device, and with macOS Monterey, there's more parity than ever before between macOS and iOS. The first step in deploying updates for all platforms is to check for updates and confirm device eligibility. Here's how that was done for Mac prior to macOS Monterey. Available OS updates were only able to be evaluated on the user's device. You used the command ScheduleOSUpdateScan, which tells the Mac to query the server for available OS updates, and then evaluates the updates to determine eligibility. Once the scan finished and was sent back to the MDM server, the MDM could then choose an update to deploy. However, Apple provides the Apple Software Lookup service, which provides a list of available OS versions across platforms. Here, we are presented with the iOS devices. You may already be using the feed for iPhone and iPad to reduce the back-and-forth that comes with the ScheduleOSUpdateScan for Mac. For iOS, MDM solutions use the Apple Software Lookup Service to be aware of available updates to push the command directly to the device. Here's how: First, the MDM Server can get a list of available updates, such as 12.1 or 12.2, from the Apple Software Lookup Service. When you're ready to deploy an update, the MDM server will send the update version to the device. Then, the device will reach the software update server to verify that the update is eligible and begin to download and install it. New with macOS Monterey, we are unifying this process for macOS and iOS. We now support a new DeviceInformation query key called SoftwareUpdateModelID, which returns the hardware model string for iOS and macOS to MDM. The Apple Software Lookup Service will include the appropriate hardware identifier for macOS, allowing MDM servers to determine the applicability of an update without the AvailableOSUpdates command. Just like on iOS, the MDM will be able to determine update applicability by comparing the result from DeviceInformation query to the device IDs listed in the JSON feed. Also, until now, macOS has ignored the ProductVersion key and used ProductKey instead. As of macOS Monterey, the ProductVersion key will be supported on macOS. iOS already uses this key to specify updates. For compatibility, if you specify both ProductVersion and ProductKey, then ProductKey will be used. If the device can't find an update eligible for that version, it will send the appropriate response. This removes the round trip for minor OS updates as long as you have previously collected the supported device ID of the device. MDM administrators can automatically install and authorize software updates for macOS, iOS, and iPadOS, as long as the device is supervised. In macOS 11 or later, all Mac computers enrolled using either Device Enrollment or Automated Device Enrollment are supervised. For iOS and iPadOS, the user will be required to enter their passcode to proceed with the update. Mac computers with Apple silicon introduce the concept of "ownership." Ownership can loosely be defined as the user who has first claimed a Mac for configuring it for their use and is not tied to true legal ownership or chain of custody. Ownership defines who is authorized to make changes to the startup security policy for a specific install of macOS. On Apple silicon, the startup security policy defines the restrictions around which versions of macOS can boot on Mac computers and permission to use the bootstrap token for automated updates. macOS requires authentication to perform updates. For Mac computers with Apple silicon, authentication requires a user password or an MDM bootstrap token. A user password is required for user-initiated, interactive updates through System Preferences. An MDM Bootstrap Token is used for automated non-interactive updates, which requires macOS 11.2 or later, and the update being installed must be signed by Apple. New in macOS Monterey, we have introduced support for the bootstrap token for MDM-initiated install-later flows. This means that Apple silicon devices can schedule and perform updates at a later time, when the device is not in use. Your users will appreciate that you're updating their device while not disrupting their workflow. They can just wake up the next day to an updated machine. If you're already supporting the bootstrap token, this will just start working when you use the InstallLater action in ScheduleOSUpdate. Once the MDM knows which update is applicable to devices, the ScheduleOSUpdate command is used to deploy the update to macOS, iOS, and iPadOS. Just note, an MDM command can be used to install the update during the deferral window or after. There are several options when using the ScheduleOSUpdate command. One option that must be set is the install action, whose value significantly affects the behavior of the update. The InstallASAP install action is the primary update mechanism for userless macOS devices. InstallASAP uses the bootstrap token for authentication on Mac computers with Apple silicon. This action performs immediately, with an option for a user to cancel the update. Just note that InstallASAP command does not automatically close applications that are actively in use unless the InstallForceResart option is used.

DownloadOnly is useful for both users and userless devices to download the update in the background before the installation time. NotifyOnly is used to alert users that there is an action for installation. Neither command will start the install. InstallLater allows you to schedule an Install Tonight update. The device will choose a window of time, usually between 2:00 a.m. to 4:00 a.m., based on machine learning, using conditions such as when the device is least used, for the install to occur. The device then schedules the update to occur in that window of time, given that you are plugged into power. Let's check out the notifications. With the InstallASAP command, or Default command, users can get a restart countdown notification. The user can choose to cancel the restart in the notification options. And in macOS Monterey, when you use InstallLater, the user will get this notification. Let's examine this more closely. This notification shows that the update will attempt to install that night. The user is reminded that the device must be connected to power at the time it performs the update later.

For iOS or iPadOS devices, Default is the primary update mechanism. DownloadOnly is useful for both user and userless devices to install the download in the background before the installation time. Here is what a user would be presented with. Non-passcode-protected devices install the version immediately after the command is sent from the MDM server. Passcode-protected devices require a slightly different flow. Once the device receives the install command from MDM, we will schedule the installation alert to show on the next unlock. This gives the user the option to Install Now, or Install Tonight, or Remind Me Later. On iOS, this first install alert shown to the user allows you to choose Install Now, Later, or Details. Subsequent alerts shown will say that the update is ready to install. For example, "iOS 15.0 is ready to install." And the provided options are Install Now or Later. Tapping Later in the previous screen will show the passcode prompt with the Remind Me Later option at the bottom. The MDM server can also flag an update as required. This will let the user choose Remind Me Later a maximum of three times. After the third tap of Remind Me Later, the installation notification will be shown every time the user hits the Home screen, and the Remind Me Later option is removed. Let's return to the timeline where we're now ready to install the update. For userless devices, you can use the InstallForceRestart option with ScheduleOSUpdate. Those devices will do a hard restart to perform the update. And for user devices, once you send the install command, you relied on the user to perform the update. That is, until now. I'm excited to tell you about a new feature we are introducing for macOS. After the admin update deferral period is over, you want to ensure that updates are installed quickly after you've made them available to users. You don't want the user to continue to cancel or defer the update. You need a way to enforce it.

In macOS Monterey, you now gain more control over the InstallLater policy to enforce the update. You can specify the number of times the device should prompt to install before the update is enforced. This number is defined by the MaxUserDeferrals key. This MaxUserDeferrals key implies the existing key, InstallForceRestart, once the maximum number of deferrals has been reached. When you enforce the number of maximum deferrals, the user will receive informative notifications about the remaining number of attempts left before a forced update will occur. To change the maximum number of user deferrals, you simply need to issue a new InstallLater command. Here's what the user would be presented with. When you set the MaxUserDeferrals value, the notification shows the remaining number of attempts before a forced install. The update is scheduled for tonight, but the user is given options. They can select Remind Me Tomorrow, which will defer the update again and decrement the count of remaining number of attempts. They can install it now, or they can have it attempt to update later tonight. If the user does nothing, the update will attempt that night. When the number of maximum user deferrals is reached, the user is notified that this update will be forced. This means the machine will restart to perform the update, regardless if the user is still using the device. With these new changes, admins gain more control over enforcing the macOS update and ensuring that devices are updated in a timely manner.

There is one more thing I want to tell you about managing software updates. New this year, iOS and iPadOS now offer users a choice between two software update versions within the Settings app. For example, you can update to the next major OS as soon as it's released, for the latest features and most complete set of security updates. Alternatively, continue on the current major release and still get important security updates, until you're ready to jump to the next major version of iOS or iPadOS. A new option on the Settings command lets you control what OS update is presented to the user. You specify this by providing a SoftwareUpdateSettings dictionary, which has a key called RecommendationCadence. This key can have three values. Here's what's shown if you have RecommendationCadence set to 0. This is the default view, which is what you would get if no MDM restrictions are in place. Both the major and minor versions of updates are available. Here's what's shown if you have RecommendationCadence set to 1. If two software update versions are available, the device will show the software update version with the lower version number. Here's what's shown if you have RecommendationCadence set to 2. If two software update versions are available, the device will show the software update with the higher version number. Just note, if a deferral is set with the existing enforceSoftwareDelayUpdate key, the device will take that into account and filter by the RecommendationCadence. The two update choices will eventually converge.

To recap, on macOS, we will now support deploying updates using an OS version so MDMs can determine what updates are needed for devices and push them in a timely manner. We have also automated InstallLater flows on Mac computers with Apple silicon using the bootstrap token. We will allow the MDM to enforce updates with MaxUserDeferrals, allowing for users to stay informed about when updates occur, and scheduling updates at times least likely to disrupt their workflows. Finally, on iOS, we have added support to manage what versions of updates are shown in Settings. We look forward to you gaining this additional control and providing a great update experience for users in macOS Monterey and iOS 15. Thank you, and have a great WWDC. [percussive music]