'Enrollment Complete' trigger ignored on Big Sur deployments?

You run multiple policies with the enrollment complete trigger?
Would have a look on this: https://github.com/Yohan460/JAMF-Enrollment-Kickstart/wiki/10-Reasoning

Thanks @slang

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.

@alexjdale I totally agree that stale computer policy history can be problematic but in my current situation Im very careful to always scrub old Mac computer records prior to enrollment (assuming they have been in Jamf before).

I'm seeing hit and miss on my Enrollment triggers, Jamf 10.26.1 and BigSur 11.1, sometime they work as expected, other times they are not. I am also careful to delete the test device's record from Jamf prior to wipe-reinstall macOS-PreStage.

My scenario is that DEP enrolment completed as normal but i find myself on the finder / desktop for about 5 min before DEP Notify kicks in .. very annoying ..

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.

What I do is deploy as a Prestage package a launch agent and script that will call the Jamf enrollment policy through the jamf binary, using jamf policy -event enroll_event_name. This fixes the issue for us.

@ggetenj Can you elaborate on this one??
thank for posting :)

@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. 

@anuj530 Are you using FileVault drive encryption? If so, nothing is going to run until a user logs in because the FileVault login screen is actually a pre-boot system waiting for a user with permission to decrypt the drive, and macOS isn't actually booted until that happens.

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.