Skip to main content

Hello Gents,
My jamfnation-fu didnt yield anything so thought to ask this in a new post.

Currently our DEP zero touch workflow pushes two things immediately upon DEP enrolment complete that require the desktop adn user input (You cant prevent that enrollment complete "acknowledgement) as it stands and Im positive someone else has come across this problem) – This means that if you leave the setup assistant window for few minutes too long after confirming DEP enrolment, it wont launch the policies/scripts correctly and it breaks the whole Zero touch setup.

The policies are 0 and 00 – so run before anything - a “lock screen” to say whats being installed and an input window for populating user and location info (essentially assigning a user and tag to the inventory record) – As there is no way to “pause” these events as they run as soon as they check into the Apple APN’s and confirm it needs to contact our JSS and start running policies, they try to run over the top of the setup assistant which, has mixed results in how it shows/fails, but ultimately means our subsequent policies fail and stops the rest of the waterfall.

I was thinking perhaps a launchdeamon that looks for the .applesetupdone file to be created before it triggers off anything (completion of setup assistant)
OR
If we knew what the process was for the setup assistant that runs upon every first boot (OOBE -I cant find out what the ACTUAL process is) then we could put one policy that runs enrolment complete and ONLY once that confirms that the process of choosing a user/setting location/setup assistant done and that whole window disappears and it goes to the desktop will the next policies run.

Is this possible? Perhaps a little bit more involved then Im making out but unsure where to sink our time into just yet, so hoping someone has come across this

PS. Yes we are looking to move the "user input" policy to the end, but still doesn't address the issue

This might help...

Sudo launchctl unload /Library/LaunchDaemons/com.jamfsoftware.task.1.plist

Sudo launchctl load /Library/LaunchDaemons/com.jamfsoftware.task.1.plist

We just stall our our with sleep in the bash script and trigger jamf events in that scrtip!

D

You can create a policy to run at "Enrolment" trigger and have a script with these in it.

#!/bin/sh

#
# Check if Setup Assistance Process is Still Running.
# If yes, wait till it finishes so this script will NOT proceed while running the Setup Assistant (Location Settings..etc)
#

SetupAssistance_process=$(/bin/ps auxww | grep -q "[S]etup Assistant.app")
while [ $? -eq 0 ]
do
    /bin/echo "Setup Assistant Still Running... Sleep for 2 seconds..."
    /bin/sleep 2
    SetupAssistance_process=$(/bin/ps auxww | grep -q "[S]etup Assistant.app")
done

#.....

@Kumarasinghe

Nice that is great, going to steal that!!! Thanks for sharing !!!

C

Gents, thanks for getting back to us.
@Kumarasinghe thats working for us!
Cheers

@Kumarasinghe I added the above to my computer renaming script, which I have in a Policy to run at Enrollment Compete. DEP enrollment being used. Still did not work for me. What could I be doing wrong?

Is it a scoping issue? I currently do not have any computers scoped...because I only what this Policy to hit computers freshly DEP enrolled. If I change my scope to all computers or anything that may hit current computers in the system, I start seeing the policy execute to existing computers in JAMF, even though the trigger is Enrollment Complete. I observed this as computers started showing in the logs as "pending".

Am I missing something?

Similar to @Kumarasinghe but we just wait for the Dock to start:

dockStatus=$(pgrep -x Dock)
while [[ "$dockStatus" == "" ]]; do
    sleep 5
    dockStatus=$(pgrep -x Dock)
done

Not the best method probably, but it seems to work well enough.

one thing that seems to work pretty well is to make a policy exclusion for the user _mbsetupuser to prevent policies from kicking off during setup assistant

You will see it as pending. That is normal. The policy won't execute until it gets triggered by a re-enrollment.

The Jamf DEPNotify sample scripts build this in, and it works flawlessly for us. It waits for the "Setup Assistant" process to stop running (runs a pgrep every second until it's not detected), then similarly waits for the "Finder" process to be running.

Our enrollment scripts starts with this, and then kicks in pretty much immediately after the desktop loads.

Terms & ConditionsCookie settingsAccessibility statement