Open mpalexl opened 3 weeks ago
Hi @mpalexl, thank you for filing!
Which version of the macOS AMI are you testing with? There was a bug with Apple silicon (mac2*.metal) instance types in earlier versions of Sonoma, specifically in the ec2-user
account, which has been resolved in AMIs running 14.4.1 or greater (amzn-ec2-macos-14.4.1-20240411-223504-arm64
or later).
Also, this may or may not impact your fix, one thing to clarify is after clicking OK, it's "setting up" for subsequent logins and won't run immediately. Logging out then in again or unloading and re-loading the LaunchAgent with launchctl unload -w /Library/LaunchAgents/com.amazon.dsx.ec2.enrollment.automation.startup.plist ; launchctl load -w /Library/LaunchAgents/com.amazon.dsx.ec2.enrollment.automation.startup.plist
will trigger the script to run immediately after.
@ds0x thanks for such a quick response.
for mac1.metal - sonoma 64-bit (Mac) macOS Sonoma 14.4.1 AMI for mac2.metal - macOS 64-bit (mac-arm) macOS Sonoma 14.4.1 AMI.
I believe i have tried
launchctl unload -w /Library/LaunchAgents/com.amazon.dsx.ec2.enrollment.automation.startup.plist ; launchctl load -w /Library/LaunchAgents/com.amazon.dsx.ec2.enrollment.automation.startup.plist
on mac1. I haven't tried this on mac2.
On mac1, even manually i did not have success. However, on mac2 i was able to succesfully enroll manually.
I will try with script again on mac2 and the command you've recommended.
I've also checked cloudtrail and it seems like it grabs the secret successfully, so that part definitely works.
quick update, re did the whole flow on mac2.metal on Sonoma 14.5. tried both rebooting, logging out and back in and launchctl unload -w /Library/LaunchAgents/com.amazon.dsx.ec2.enrollment.automation.startup.plist ; launchctl load -w /Library/LaunchAgents/com.amazon.dsx.ec2.enrollment.automation.startup.plist
. However, still no luck with auto enrollment.
however, manual enrolment works.
It seems like it's gone through the full flow and preparation with the permissions dialog above, too. Accessibility permissions were given for osascript
as prompted, correct? I'm working on linking deeper into System Settings, but there's some oddness in my experience so far.
yep, that is correct. the accessibility permissions were given for osascript
as prompted.
I have also noticed on mac1.metal it also adds System Events to accessibility permissions (maybe not initially but if you rerun). However, i did not notice this on mac2.metal
Thanks—the prompt for System Events to control System Settings should appear on either architecture. The permissions check routine actually runs 3 times because of exactly this sort of behavior, and can be re-run on failure. Is there a permission in Privacy & Security -> Automation for osascript and System Events on mac2?
i will test again on mac2 in the next few days, will keep you posted. however, as far as i remember i just had osascript in accessability and that's about it.
I have tried running through the whole flow multiple times on mac1.metal, then I have switched to mac2.metal and the instance does not get any profiles at all. try rebooting as well does not seem to have any effect. i looked through MMErrors.log and MMOutput.log and jamfErrorCheck.txt and nothing there either that would indicate if something went wrong.
I get the success window every time, however nothing seems to happen.
When i try to enroll manually i just get certificate and a profile with 3 settings; however, no jamf.