Preparing for a new OS release

Introduction

Apple has recently released a new set of iOS updates (iOS, iPadOS, tvOS and watchOS) and is in the double digits for betas of the next macOS release which, based on previous years, is set for a November launch. We have taken this opportunity to discuss the strategies and best practices organisations can adopt to prepare for the latest iterations of Apple’s operating systems.

Going through changes

Commonplace for the last few years, Apple has been working through an annual release cycle for their core operating systems. With new OS versions come changes aplenty, some of which are really helpful (all the new things added to configuration profiles) and some bring more challenges (randomised MAC addresses, discouragement of kernel extension support etc). Some of these changes will help you or your users work better, whereas others will cause incompatibilities with your tools, software and/or security tools. It helps to be prepared.

What should I do to prepare?

There are a few things we would recommend when preparing for new OS versions from Apple.

Join the AppleSeed for IT beta program

Apple has opened up the AppleSeed for IT beta program to any users with an account in an Apple Business Manager or Apple School Manager portal, and you should take advantage of this to gain early access to beta versions of OS releases. For more details, check out Apple’s page here: (https://support.apple.com/en-gb/guide/deployment-reference-ios/apdcc914230f/web) 

Read the documentation

Although not yet available for Big Sur, Apple often releases knowledge base articles for their new releases, such as:

• Prepare for smart card changes in macOS Catalina (https://support.apple.com/en-us/HT210541)
• Prepare your institution for iOS 11, macOS High Sierra, or macOS Server 5.4 (https://support.apple.com/en-gb/HT207828)
• Prepare for APFS in macOS High Sierra (https://support.apple.com/en-gb/HT208018 )
• Prepare for changes to kernel extensions in macOS High Sierra (https://support.apple.com/en-gb/HT208019 )

In addition to the public documentation, Apple will have further information and release notes in the beta portal, which you can access if you have signed up for this, as mentioned above.

Testing (for parity)

With access to the beta version and new releases, you will need to test for any bugs or behavioural changes that might affect you. If any of these tests fail, you will need to log bug reports with Apple and/or the Vendor. This includes testing for:

• Basic functionality
  • Can I upgrade successfully?
  • Can I log in afterwards?
  • Do the core Apple applications work?
• Core management tools
  • Can my management system still report on the device? 
  • Can my management system still manage the device?
  • Can I enrol a clean updated device into the management system?
  • Can I continue to manage an in-place upgrade device with my management system?
• Core security and infrastructure tools
  • Can my security product still report on the device?
  • Does the security product still work if the device has an in-place upgrade or a clean install?
  • Can the device speak to my infrasture as expected (networking solution, proxy, radius/802.1x, Active Directory)?
• Applications 
  • Can the business critical applications still function as before?

Testing (for new features)

Also with new software releases, there are new features that should be tested. These may include usability improvements for your users, new support for solutions and integrations, or even just fresh management options which will open up new opportunities for your devices – all of which are worth testing and utilising.

Testing with beta releases

As a rule of thumb it is always good to test early and often with beta OS versions. However be aware that as beta releases, these can (and do) change often. How early you start your beta testing will always involve a compromise between testing early enough to find and resolve bugs, versus spending time testing on betas that may well change before final release (and require additional testing).

What about issues?

If you do find any issues with testing, the first task should be to log a bug report. These would typically be with both Apple and the vendor of the item you have had an issue with. Apple may fix the issue in a future release, or the vendor may have a beta release you can retest with. 

What if these issues are not resolved by the official release of the new OS version, and are classified as critical to your operations? In this case you will need to make a decision whether to limit access to the release. Jamf has options utilising the ‘Restricted Software’ feature (https://docs.jamf.com/jamf-pro/administrator-guide/Restricted_Software.html), but check with your management system of choice here. 

We would not suggest restricting access to the newer OS versions as a replacement for testing, but more of a last option if you have no choice. It is a great idea to aim for day-zero support (meaning to be able to support the new Apple releases on the day Apple officially releases them), but this might not always be possible. Bear in mind the work you need to do and be prepared to make judgement calls on how ready you are to support the newest release.

Do not forget, there is always likely to be a new release within 12 months, so try to keep up the work to support the newest releases as soon as you can.

Additional information for dataJAR customers

dataJAR will work on a best endeavours basis to provide day-zero support to new OS versions released by Apple. We will guarantee support for the core features of datajar.mobi within 30 days of a new OS version release. dataJAR will work with vendors where possible to support a new OS version, but this will be subject to the discretion of the vendor and is outside our control.

If you are unsure of anything discussed above, please contact our support team.