How are you deploying new mac laptops?

We don't bind to AD so that is not really a concern for us.

We use DEP for all new machines. Basically same as your process just how the enrollment gets triggered which for us is automatic on new machines.

For legacy machines that aren't in DEP for whatever reason where we re-image, we just wipe them back to a base OS, quickadd them, and then we have a self service policy that just triggers the exact same policy payload as DEP so everything is consistent and we eliminate as much duplicate effort as possible.

could it be how fast you're going through the setup wizard? we found if we stopped clicking next for about 90 seconds, and THEN completed the wizard, then things enrolled and got the profiles as expected.

@jwojda What do you mean how fast i am going through the setup wizard? The wizard will be stuck at "running package scripts" for 15 minutes (during this time, you can check the installer log, command + L, and you will see the software being installed in the background.

@chriscollins So basically, you allow the end user to install the software from self service and do not deploy any standard software, correct?

I am currently experimenting with enrolling using DEP (which only wors internally as we don't have external visibility as yet). This does only the enrollment and AD binding.
I then have a general Self Service policy with 11 or so packages and a 4 or 5 scripts that does everything else.
So far seems to work pretty well, it's not completely automated though which looks like what your after.

@baldiesrt Actually we do deploy standard software. After the user is out of the Setup Assistant and they are at the Desktop, a policy kicks in and a splash screen comes up that gives them a progress bar and a basic policy with some standard software like Office, AntiVirus, and a few others kicks off. Lastly it enables FileVault and directs the user to restart.

@chriscollins Can you explain how you setup the splash screen/progress bar? In JSS, what did you use as policy triggers, login?

Thanks all for your input

Hey @baldiesrt ,

I can't go into a ton of detail since it would be an incredibly long post, but basically here is what happens:

1. Machine enrolls into JAMF during the setup assistant via DEP
2. Machine then gets added to a smart group that is scoped to Enrollment method: US DEP Prestage
3. That smart group is scoped to a policy that runs a single script that checks for a .DEPSetupDone stub file in /var/db/ to check if the DEP policies have ever run before to avoid it running again by accident. If it isn't there, it then will check every 5 seconds to see if there are any processes owned by _mbsetupuser, which would mean the setup assistant is still active.
4. User creates their local account and then when at the Desktop, the script from step 3 sees that _mbsetupuser has no more processes running and calls the main policy via a custom trigger.
5. That policy then installs our customized progress screen app, and that tails the jamf.log file to update the progress bar as the policy runs scripts and installs our various standard packages. One thing we have found important to do here is to call caffeinate to make sure the machine stays awake and the monitor stays up so the user doesn't think the machine has shut off.
6. The last scripts in the policy run (we control when they run by setting the scripts in a particular alphabetical order) kill caffeinate, progress screen, check if the machine is a macbook and run a FileVault policy via another custom trigger (we don't encrypt desktop machines) and a last policy that pops up a jamf helper screen to tell the user to log out or restart (primarily to finish filevault enablement).

@chriscollins Could you provide or expand a bit more on your script from step 3? _mbsetupuser keeps taking our enrollmentcomplete policies if not watched carefully and this script is exactly what I came looking for.

@chriscollins I know this is an old post but i'm curious if you've changed how you do this or if you are still using this method. I'm running into the problem with the enrollment complete triggers are hitting _mbsetupuser instead of the new created user. Which throws everything off. Thanks in advance.

@LovelessinSEA -

I don't know if you've already solved for this on your own, but this is my work around for the _mbsetupuser issue that has been working flawlessly for us.

Combining what @chriscollins described above with an extra step to just wait until the dock appears before running anything else, our prestage policies have been kicking off in the user without issue.

#!/bin/bash

## Created by Kevin Wilemon - 2017 ##
## Last Update: ##
## 09/13/17 - Original ##
## 10/22/17 - Added DEPSetupDone dummy file to avoid unnecessary enrollment steps ##
## 12/02/17 - Added check for Dock status to verify polices are run as correct user and not _mbsetupuser ##
## 03/18/18 - Added flushjamfhistory trigger for redeployment cleanup ##

## This policy runs whenever a system is enrolled in the JSS. This policy verifies whether the system ##
## has already been through Onboarding and is merely re-enrolling to the JSS or if the system is ##
## enrolling for the first time and requires Onboarding. ##

    DEPsetupdone="/var/db/.DEPSetupDone"
echo -n "Verifying if $DEPsetupdone exists..."
    if [ -f $DEPsetupdone ]; then
       echo "  System has already been onboarded since it was last restored. Prestage enrollment not necessary."
       exit 0 
    else
       echo "  System has not been enrolled or onboarded since last OS restore. Continuing with Prestage Enrollment."
    fi

## If system has not previously been onboarded, proceed with prestage enrollment. ##

dockStatus=$(pgrep -x Dock)

echo "Waiting for Desktop..."

while [[ "$dockStatus" == "" ]]
do
  echo "Desktop is not loaded. Waiting."
  sleep 5
  dockStatus=$(pgrep -x Dock)
done

sleep 5
loggedinuser=$(/bin/ls -l /dev/console | /usr/bin/awk '{ print $3 }')
echo "$loggedinuser has successfully logged on! The Dock appears to be loaded with PID $dockStatus."

## Flush Computer's JAMF policy/User history for redeployment and reset "Run Once" policies ##
jamf policy -trigger flushjamfhistory;

## Mark system as having successfully completed DEP Prestage enrollment for future checks ##
touch /var/db/.DEPSetupDone

exit 0

I have other policies that kickoff via custom triggers before the exit, but that's personal preference and would be too long/unnecessary to post so I removed them. The flushjamfhistory trigger is also just a preference works for us.

EDIT: Credit where credit's due! Was trying to find where I got the Dock code from and have to thank @sepiemoini for enlightening me.

DEPNotify with a LaunchDaemon, so far it's worked every single time.

My writeup link. I also did a presentation on it (you can find that link on my site also). I'll have more in October ;)