Enrollment Complete Policies Not Running + DEPnotify

[al_c]

My DEPnotify policy is set to trigger on "Enrollment Complete". It seems as though the trigger only works half the time. I just tried enrolling 3 machines and the policy never ran. I ended up having to run the "DEPnotify (do not delete)" policy manually from Self Service. Any tips? I already tried disabling "Network State Change" Attached is a screenshot of one of the machines.

[seanism · Accepted solution]

I'm having similar issues as well. Have you tried creating a brand new depNotify.sh script from the site and launching that without any edits?

[tlarkin]

I have modified my enrollment complete policies to a single tiny shell script that bootstraps the Mac and then runs DEP Notify from a PKG and not a policy. It has highly reduced my failures. When I iron it out I will update my github, but there are many github examples of this flow.

There are race conditions sometimes with the setup assistant user env to the actual human user env, and I have had to write a ton of code around detecting that. So, I just decided to use a PKG for DEPNotify now with a launch daemon. In fact in your screen shot I see the exact race condition I am talking about. It is trying to run policies as _mbsetupuser and not the actual user

[gachowski]

@tlarkin

While it might be hard to go back and manually exclude _mbsetupuser from all user policies, do you think that would help ?

C

[tlarkin]

@gachowski

So the _mbsetupuser doesn't exist in actual user space and is only using during Mac Setup (or Mac Buddy I guess) and you can script around it by pausing your code until the Finder and Dock load. I wrote this heavy boilerplated code, here is the relevant snip

def wait_for_userspace():
    """this function will check to see if the Dock and Finder are present to ensure user space
    has fully loaded.  This will stop that race condition"""
    # give the system a few seconds to log into user space
    time.sleep(7.0)
    # check to see if still in the "mac buddy" user context
    while USER == "_mbsetupuser":
        user, uid, gid = SCDynamicStoreCopyConsoleUser(None, None, None)
        logging.info("detected Mac Buddy user context...")
        time.sleep(1.0)
        if user != "_mbsetupuser":
            break
    # test to make sure both the Finder and Dock are running by bundle ID to ensure user space is fully loaded
    app1 = None
    app2 = None
    while not all([app1, app2]):
        app1 = NSRunningApplication.runningApplicationsWithBundleIdentifier_(
            "com.apple.dock"
        )
        app2 = NSRunningApplication.runningApplicationsWithBundleIdentifier_(
            "com.apple.finder"
        )
        logging.info("waiting for apps to appear running..")
        time.sleep(0.5)

So, even when the system swaps from _mbsetupuser to the first user that got created, there is still a transition period while that user context swaps (as seen in the logs from OP) thus I do an infinite loop until the Finder and Dock are actually running. That seemed to fix my conditions, but I am moving to a launch daemon now.

hope this helps. Also, I have seen bash examples on the GitHubs if you search you'll see similar things using like pgrep or what not

[jobscommasteve]

Seems like exactly what I need. Where in the script should this be placed, or does it not matter?

[Shaun]

@tlarkin

Would this explain why our Self-Service installs fine and DEPNotify runs if we are quick enough to run through the setup process and login the user, but if someone stalls at the user login and leaves it for a few minutes then it never works because it then takes _mbsetupuser as the default and tries to run with it?

Where/how do you run that script or yours? I'm not quite understanding where in the process it would happen to prevent this.

I would imagine if we packaged DEPNotify and relates policies and went through the whole motion of certificates and all that this would also go away?

[mickl089]

Could it simply be that the DEPNotify is outdated? The version used here is 1.1.0 - I recently updated my JAMF Cloud to 1.1.6, which enabled me to integrate M1 devices cleanly first.

[al_c]

This ended up working after starting from scratch (updated script and pkg)