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.
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.
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.
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.
@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.)
@dtmille2 strange, what Jamf Pro version are you running? The full path (with my username changed to 'david' in this example) is:
@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.
@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 
Path: /Applications/Software Center.app/Contents/MacOS/Self Service
Version: 10.27.0 (10.27.0-t1612450030)
Code Type: ARM-64 (Native)
Parent Process: ??? 
Responsible: Self Service 
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
@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.