Self Service in M1

konfio
New Contributor II

You know why Self Service in M1 already with Rosetta Installed does not work when installing Intel Apps, it remains in a loop but does not install anything.

17 REPLIES 17

dtmille2
Contributor III

Just logged into Jamf Nation to find out why this is occurring on our M1 Macs as well. Is this a known issue?

davidhiggs
Contributor III

I'm trying to get this identified as an issue right now actually. M1 machines shipping with macOS 11.1 or 11.2 and going through ADE enrolment. Self Service will not install anything, policies don't finish executing. Jamf binary has no problems executing the same policies. Deleting com.jamfsoftware.selfservice.mac.plist and relaunching Self Service fixes it. This is not a Rosetta issue.

@konfio @dtmille2 could you try the above workaround and let me know if that fixes it for you? I also found that if I restore the M1 to the same macOS version it shipped with, I don't see the issue.

It would be great if someone could put Self Service into debug mode, reproduce the issue, and send the logs to Jamf Support. I don't do deployments and we don't have many M1 devices, so it's difficult for me to reproduce at the moment.

mickl089
Contributor III

I had the same problem, the solution was: update DEPNotifiy to version 1.1.6.

emily
Valued Contributor III
Valued Contributor III

I've seen similar behavior on Intel builds at previous employers. Self Service gets into a funky state and won't run anything until com.jamfsoftware.selfservice.mac.plist is deleted and Self Service is relaunched. The M1 chip may be a bit of a red herring here.

Out of curiosity, what version of macOS is running on the Macs exhibiting the behavior? I haven't found a way to replicate the issue on-demand so it's been tricky in the past to troubleshoot.

davidhiggs
Contributor III

I've seen macOS 11.1, 11.2 and 11.2.2 so far. A machine running 11.1 we took aside to upgrade to 11.2.2 first before touching Self Service and it was still bugged out.

I was able to reset two M1 machines using Apple Configurator, went through ADE again and it was fine - and I specifically grabbed the .ipsw for the OS those machines shipped with. So the older OSes aren't an issue, or I hit something temperamental.

I think you're right about the red herring, because the only thing I haven't been able to test is an Intel Mac with an Apple shipped OS. I want to eliminate the OS shipped from Apple vs. a clean OS without the iWork cruft and anything else they choose to put on top when they ship. But I still don't see the relationship with the data that's in the plist file.

Another circumstantial element to consider - the preference file domain changed recently from com.jamfsoftware.selfservice.plist to com.jamfsoftware.selfservice.mac.plist - something my support agent wasn't aware of and maybe because Enabling Debug Mode is outdated.

dtmille2
Contributor III

Hello!

Where is com.jamfsoftware.selfservice.mac.plist supposed to be located?

davidhiggs
Contributor III

The logged in user’s Preferences folder

~/Library/Preferences

dtmille2
Contributor III

That's what I thought. I do not have such a .plist. The closest I have is com.jamfsoftware.jamfHelper.plist.

emily
Valued Contributor III
Valued Contributor III

@davidhiggs the Apple-shipped OS versus vanilla-installed OS is an interesting angle. Is the thought there that it’s an OS issue? I wonder what the OS could be doing to bungle that preference set/cache that would require removing it to get things working.

Maybe security agents are at play here? (When are they ever not lol.)

davidhiggs
Contributor III

@dtmille2 strange, what Jamf Pro version are you running? The full path (with my username changed to 'david' in this example) is:

/Users/david/Library/Preferences/com.jamfsoftware.selfservice.mac.plist

@emily No security agents here, just a vanilla system that just gets to the desktop with a single enrolment trigger for setting up Rosetta 2 - which completes using the jamf binary successfully and exits clean.

emily
Valued Contributor III
Valued Contributor III

Do you have Self Service branding enabled? That's pretty much the only thing set in that preference file. I imagine deleting the file causes the app to re-check that branding or path to the branding. I have no idea if it's related but it's a strand I haven't tugged on yet.

dtmille2
Contributor III

@davidhiggs I am running Jamf Pro 10.28. Yeah, its not there, which might be the problem. Going to focus in on this today. Might call Jamf.

dstranathan
Valued Contributor II

@dtmille2 We just got a help desk ticket for this exact issue (Self Service is not opening on an M1 Mac mini running macOS 11.3.0) Jamf Pro 10.27 here. The user's Self Service plist is not getting generated (com.jamfsoftware.selfservice.mac.plist). Did you open a Jamf case?

Process: Self Service [19735]
Path: /Applications/Software Center.app/Contents/MacOS/Self Service
Identifier: com.jamfsoftware.selfservice.mac
Version: 10.27.0 (10.27.0-t1612450030)
Code Type: ARM-64 (Native)
Parent Process: ??? [1]
Responsible: Self Service [19735]
User ID: 1516754102
Date/Time: 2021-05-24 10:32:57.941 -0500
OS Version: macOS 11.3 (20E217)
Report Version: 12
Anonymous UUID: 81D4FE18-F9E4-6C4B-B8A2-EC231C4C05AE
Time Awake Since Boot: 340000 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread

davidhiggs
Contributor III

Since upgrading to Jamf Pro 10.29 and upgrading machines to 11.3.1 before using Self Service, we've not seen the issue reoccur.

dtmille2
Contributor III

@dstranathan I did open a case, and how gone back and forth with Jamf Support a few times, testing out some scenarios, getting them logs, etc.. Unfortunately, I got sidetracked with some other projects and have to circle back around to this and follow back up. Don't have anything helpful to share at the moment. Will look into @davidhiggs's information and see if this applies to my situation.

dstranathan
Valued Contributor II

Apparently, our case was a red herring. After a simple reboot, the user was able to launch Self Service and download apps on her M1 Mac.

Philein
New Contributor III

We had the same issue in Big Sur and it was resolved by unchecking this preference in our Config Profile:

Require admin password to install or update apps

Does it helps?