Seeing failed Kext Config Profiles on Apple Silicon Macs even though they are scoped out

[tsylwest]

Is anyone else seeing failed Kext Config Profiles in the Management section for M1 Apple Silicon macs?

I know kexts will fail on this hardware, so I created a Smart Group for 'arm64' architecture macs, and have 'excluded' this group from the scope (which is aimed at All Computers) of these Kext related CPs thinking this would be the correct way of things, yet I am still seeing these attempts in the Management tab (as in the attachment below).

I should add that I am seeing this at enrollment time, is it possible that JP tries to apply these CP's before it actually realises which Smart Group they are in?

[jgaitherccu]

I've been having this issue with multiple M1 things and came to the same conclusion you did. Smart Groups must happen somewhere "After the fact." I'm trying to get a Rosetta2 install script to run first but that seems impossible if Smart Groups aren't triggering first.

[garybidwell]

How's your smart group scoped?

As both "Architecture is arm64" and "Architecture Type is arm64" will both seem to get the same device count, but I have found will give different results.
Ive been using Architecture Type in Jamf Pro 10.26 and it is scoping correctly for me to exclude Apple Silicon devices from SKEL profiles
(its opposite is Architecture Type is x86_64 if you want to just find Intel devices)

[tsylwest]

@garybidwell I was indeed using "Architecture Type is arm64". I'm thinking of just not using the All Computers group any more... and having 2 smart groups going forward, one for M1's and one for Intel's. Not ideal, but I think it should work better... I hope!

[jgaitherccu]

@tsylwest Hate to redo all my mess but that might be the only way to really keep this straight for now.

[A_H]

Re: (SPErrorDomain error 10)
I'm on 10.26

For KEXT configs scoped when a device is enrolled (DEP/ADE), I saw this error getting spammed out every push. (Several times a minute.) After a reboot, the commands go through.

Jamf support said this was normal/expected and a Third-party issue. Didn't give me much sympathy, nor a PI, but it sure sounds like PI-009052.

To me, getting hundreds of failed commands per enrolled device sounds like it deserves more than a shrug, but hey I just work here.