I am seeing issues with Jamf Pro 10.26 and new Big Sur 11.0.1 Macs (Intel). The required 'Enrollment Complete' (enrollmentComplete) Trigger is ignored and thus my deployment policies never execute.
-Target Mac appears in Apple Business Manager and in Jamf PreStage scope.
-Apple Device Activation (DEP) confirmation pane appears on target Mac.
-My enrollment admin account lands on the target Mac (from PreStage).
-Custom Apple Setup Assistant EULA panes appear (from PreStage).
-New device record appears in Jamf JSS.
...But my Jamf deployment policies (DEPNotify 1.1.6 and related kickstart script) never start because the 'Enrollment Complete' trigger is never acknowledged.
Is anyone else seeing this issue?
Yes. I start my deployment ("imaging") workflow which in turn calls a couple of Jamf policies to install apps and provision the target Mac for production. All of this starts with a Jamf policy that relies on Enrollment Complete to kick off (and starts DEPNotify).
For whatever reason, I don't have many issues with the Enrollment Complete trigger on macOS versions prior to Big Sur. But Big Sur fails 100% for me.
I'll look into Yohan's link you shared. Thanks again.
Just to add here, mine works fine. We have an enrollment trigger for ADE-enrolled devices that kicks off fine with Big Sur Macs.
I doubt this is the case, but I've had issues where a pre-existing Jamf record for a particular Mac can confuse Jamf if the old record would put it in a different smart group (ie Catalina vs Big Sur). During enrollment, Jamf would run the policy scoped to the old record instead of the new one. To be safe, I delete the old record before enrolling if the OS version is different.
I'm seeing the same thing @rkeleghan mentions - a long delay between the Desktop appearing and my enrollment complete policy triggering. It's not 5 minutes, but definitely longer than Catalina. From what I can tell the installation of Configuration Profiles is taking much longer, and even the install of Self Service is being delayed.
@ggetenj @rkeleghan After testing various methods and workarounds, I'm planning on doing something similar using a customized version of Arek Dryer's workflow (see https://hcsonline.com/support/white-papers/how-to-deploy-depnotify-as-a-jamf-pro-prestage-enrollment-package-with-custom-launching-scripts).
Basically, the workflow consists of a signed PreStage Enrollment package containing DEPNotify 1.1.6, a temp LaunchDaemon, and a postinstall script (and of course the usual Jamf enrollment policies/pkgs/scripts to deploy apps & settings - and then finally remove the temp LaunchDaemon). The LaunchDaemon is the 'secret sauce' that replaces the need to wait on the (fragile) 'enrollmentComplete' trigger.
Hi! Sorry to re-open an older thread. I am doing the same thing right now but does your LD run at the login screen or after a user logs in? I am trying to make it run at the login screen but not having luck. It runs immediately upon user login. Any help would be appreciated.
We are using FV but it is not enabled until the user logs in for the first time. So that should not be an issue after startup screen. I just realized that the DEPNotify app code itself waits for the dock to load so I don't think what I am trying to do will work regardless.