User Profile

I noticed the following issue in macOS Big Sur Beta 1: Popular video conferencing tools such as Zoom that allow screen sharing will request approval for Screen Recording before someone can share their screen. Expected behavior: In macOS 10.15, as a standard user I was able to go into System Preferences > Security & Privacy > Privacy > Screen Recording and add an app without needing to unlock the preference pane with admin credentials. Actual behavior: As of macOS 10.16 Beta 1 (20A4299v), as a standard user when I go to System Preferences > Security & Privacy > Privacy > Screen Recording, I need to unlock the preference pane with admin credentials. This is a regression from macOS 10.15 behavior. In our environment, our users do not have admin credentials to be able to unlock that preference pane. This will severely impact our users who rely on web conferencing tools and need to share their screen. With many of our users working from home, this will severely impact us and affect our ability to also provide remote support. In fact, we rely on Zoom's screen sharing feature for our end-users to show us their screens during remote support sessions. If they do not have admin credentials to unlock the preference pane, they cannot possibly provide screen recording to Zoom and other similar apps. We kindly request that the behavior go back to how it was in macOS 10.15. Apple at the moment is not providing an alternative way for standard users to be able to approve prompts for Screen Recording access. If you are impacted by this, I sincerely suggest you supply feedback to Apple at https://feedbackassistant.apple.com/. If you haven't already, please join AppleSeed https://appleseed.apple.com/ and supply feedback to Apple.

Moving forward, software updates across all platforms can only be delayed for 90 days. You can find more details in the WWDC session: "Discover AppleSeed for IT and Managed Software Updates" - https://developer.apple.com/wwdc20/10138 In macOS Big Sur, major and minor updates can be deferred by Configuration Profile Restrictions payload using the same preference key: enforcedSoftwareUpdateDelay (Documented here: https://developer.apple.com/documentation/devicemanagement/restrictions) This would be problematic for our environment for multiple reasons, three of which include: 1) we cannot just allow users to upgrade to the latest major version of macOS without ensuring all third party software works. 2) we do not want to delay minor updates in most cases, but if we did use this preference key then minor updates would be delayed simply because we're trying to delay the major version of macOS. 3) it also implies that the previous version of macOS will no longer get security updates. We want to allow users to install minor software updates like 10.16.1 for 10.16.2, but not allow them to upgrade to the latest major OS (e.g. 10.17). We want our OS to have some support for at least security updates after it has been superseded by another major OS release. In many instances, many software vendors provide extended support (or long term support) for some major software releases. I'm not asking that Apple support OS updates indefinitely on older operating systems. But at least one year would be sufficient to ensure a smooth transition to the newest release. My feedback here would be to have two separate preference keys to achieve different purposes to allow us to distinguish annual major releases from regular minor software updates when creating a delay:enforcedSoftwareUpdateDelay which applies to minor software updates as it previously in 10.15. This can continue to be limited to 90 days as is today. enforcedMajorSoftwareUpdateDelay which applies to major OS updates to prevent new versions of macOS from being advertised on managed computers. Sets how many days to delay a software update on the device. With this restriction in place, the user doesn't see a software update until the specified number of days after the software update release date. This should be limited to 365 days. We'd also like to request that the enforcement for major OS updates supports a delay longer than the 90 day maximum. Again, unlike a minor release, it could take significantly longer to adopt a new macOS release. I suggest a 365 day maximum instead which provides a year for organization to transition to the new major OS release. The goal as a business is that we would also like to control how long we can ignore the major OS updates/upgrades and 90 days may not be sufficient. But we also don't want to ignore minor OS updates at the same time leaving our computers vulnerable. Although we typically make every effort possible to support the latest major version of macOS on day 1 release, in some cases, that's simply not possible due to third party incompatibility issues and/or outstanding major OS issues that Apple has not addressed (and may not address in some cases until the next major release). If you are impacted by this, I sincerely suggest you supply feedback to Apple at https://feedbackassistant.apple.com/. If you haven't already, please join AppleSeed https://appleseed.apple.com/ and supply feedback to Apple.