Mac OS 12 Monterey

Phil,

We have started initial testing with Monterey and it looks like we should be able to support it at GA. It looks like it is an evolution of Big Sur rather than the revolution that Big Sur was. 

We have changed EAPs now so that MSP customers have access to them provided it does not add licensed features, clearly, the previous BIG Sur EAP and the current M1 EAP do not and so access is available.

At this stage we may not need to do an EAP for Monterey, we wouldn't normally do an EAP for a new macOS variant but did for Big Sur due to the scale of the change.

Darren.

Hi Darren,

We need a supported version of Sophos before the release of Monterey. Sophos wasn't ready for Big Sur and Apple Silicon for months this has damaged the position of Sophos for Mac environments.

I'm currently running Beta 2 and Sophos is a real pain. System is flooded with Crash Reports for SophosDeviceControlD. I've created the diagnose file: fbf79015-2610-449a-b846-1cf5b531308f_2021-07-13-22-00-50.zip.

Sending out a supported version for Monterey after the GA release would be really bad.

Maybe I didn't describe it very well but what you suggest is exactly what we do and have done for the last 10+ years, for "on release day" we take that as Apple's GA and not any early or beta version they may release. Usually, our product will work, albeit with some minor glitches (often UI related) with the early versions but we don't offer official support until Apple GA's due to the changes they often make late in the day.

I'll say it again just in case....we intend to have support for Monterey when it GA's.

Big Sur was an exception due to the scale of the changes made, we do not forsee the same issues with Monterey.

Thanks Darren, we hope that will come true!

We appreciate that the community would like and be willing to give feedback prior to GA, however, if we see no driving reason to need to get feedback/give early access all we would be doing is delaying official support. We will of course be running Monterey internally on as many devices as possible as well as doing our product testing. EAPs are most useful where we believe that customer environments or third party products may impact the product in some way, this was clearly the case with Big Sur but as stated previously, we currently see Monterey as a small evolution of Big Sur. 

I am not saying we will not run an EAP just that at this stage we do not intend to, that could change.

Feedback: with my Monterey test machine (MBP 13, 2017) with the newest Beta of Monterey, SophosDeviceControlD is not working.

Thanks for the feedback, I will pass this on to engineering.

DarrenTeagles I mentioned this on July 13th. I got zero response from that. The only solution for now is to disable peripheral control.

This is exactly my point which I mentioned earlier.

Apologies, I did ask and the team to check this on our systems and they could not reproduce the issue. This is what they said:

"A test with Wi-Fi blocking, removable storage (block and read-only) proved to be fully functional on macOS 12 beta 5" 

After selecting "Monitor but do not block (all peripherals will be allowed)" in Peripheral Control macOS Crash Reports are created continuously. You can view them in Console.

Process: SophosDeviceControlD

Application Specific Information:
terminating with uncaught exception of type NSException
abort() called
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[1]'

macOS 12.0 beta 5.

So I'm wondering why I'm seeing this and not you as I can easily reproduce these issues.

I just checked in again and the team can now reproduce this issue and are investigating.

Hi Martin,

The engineering team has reproduced this, it turns out it's triggered on the evaluation of policy and only on particular hardware. The "Monitor but do not block" was key here, thank you for providing the details.

It appears a new layer has been added to the device tree for Wifi and it's of a non-standard format which is tripping up our service and we're working to correct that.

In the meantime a workaround would be to create a policy that will explicitly allows WifI for Monterey machines instead of using monitor mode.

Hi Martin,

The engineering team has reproduced this, it turns out it's triggered on the evaluation of policy and only on particular hardware. The "Monitor but do not block" was key here, thank you for providing the details.

It appears a new layer has been added to the device tree for Wifi and it's of a non-standard format which is tripping up our service and we're working to correct that.

In the meantime a workaround would be to create a policy that will explicitly allows WifI for Monterey machines instead of using monitor mode.

David Lancaster thank for the update. For now I've disabled Peripheral Control. Please let me know when I can test this again.

Have you also seen my other reply below regarding com.sophos.endpoint.scanextension?

Thanks.

Hi Martin,

We have an engineer analyzing the SDU you posted for the scan extension, thanks for that it'll be very helpful. May we reach out via  private message if we have more questions?

Sure!