(ABM) Prestage installation starting before initial login from user

[Nate1]

Hello all!

We have been having an issue lately where machines will start their prestage installation process (policies, app installs, scripts, etc) that we run on first setup BEFORE the user is able to even log into the machine via Jamf Connect 2.

Previously the user would boot the machine for the first time and it would go through language selection > warn them about Company MDM setup > ask for location > then prompt for a Jamf Connect 2 login. It would wait there until logged in by a user THEN begin the full 10-15 minute setup. It would finally end with a reboot and come back up to a local login and the user would be able to log in without issue because it created a local user for them during that 10-15 minute setup.

Now, the setup will begin nearly immediately after warning them of the Company MDM setup (about the same time as it asks for location. If a user gets distracted and doesn't log in at the JC2, it will go through its install then finish with a reboot and come back to the local login where they wont be able to log in because a local account was never created.

My questions is:

Where is the setting(s) that tell the Prestage Enrollment to begin? Somehow we had it to start AFTER initial JC2 login, but now it's starting immediately instead of waiting for the user

Thank you!

[akw0045]

In our prestage, we only have Jamf Connect and those profiles install. All the software are set on a different policy to install at login. We used to use Enrollment Complete on those policies but had similar issues.

[Tribruin · Accepted solution]

Using the enrollment trigger with ADE is always problematic. As far as Jamf is concerned, once the Jamf binary is installed, the enrollment is complete, there is no option to wait for the user to be created. (And, since Jamf Connect has taken over the login window, System Setup is complete as well.) 

I have code in my enrollment scripts to wait for the user to login and the desktop to appear. That way, if the script starts before the user has logged in, it just sits and waits. 

waitForSetupToFinish() {
# Wait until setup is complete and the user is logged in. 
	logToFile "Waiting for Setup to complete"
	currentUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
	while ( [[ $currentUser == "_mbsetupuser" || $currentUser == "loginwindow" ]]  ||  ! ( (pgrep -x "Dock") && (pgrep -x "Finder") ) ) ; do 
		# echo "User is not logged in and at Finder"
		sleep 5
		currentUser=$( scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ && ! /loginwindow/ { print $3 }' )
		# echo $currentUser
	done 
}

[mm2270]

Yeah, you need to do something like what @Tribruin is doing. Have a loop in your script that waits to start the actual core of your enrollment policies until after something like the Dock appears, or some other easily detectable process that would not be running when at the Jamf Connect login window.

I do something like this as well in my device setup script.

[Nate1]

We got it! Thanks for all the help everyone.

A bit of an oddity: we did have a script to wait until the Dock came up, as well as wait for a few users (_mbsetupuser, loginwindow) but we added some better logging to our script and noticed that when it wasn't waiting for a login, the user it was accepting was either "root" or "" (yes, blank). We added those two as additional users to wait on and it works!

It's not a perfect solution and not really a long-term one, but it works for now while we work on something more permanent.

Oddly enough, in my testing of this issue it never happened on Monterey and previous, it only started when imaging with Ventura. I'm curious if something changed there.