Connect 2.0 deployment

Did Jamf Connect install the first time the machine was enrolled? Is this issue only happening on the next enrollment of the same machine and going forward?

What version is the OS?
I've had a ton of trouble with 10.15.6 doing this exact thing - I've been running the installs on a virtual machine enrolled in DEP.
It would do exactly what you were describing there, then after another reboot, suddenly it would behave itself.

Also make sure you didn't do what I did - I cloned our default enrollment, removed the packages, then added the 2.0 package. In the process it reset my distribution from CDP to None. Took a couple of retries before I realized my mistake!

I should note that those two issues are separate - even after I fixed my 'duh!' moment, the machine still refused to install the package a couple of times. I've had the same thing happen with the old Jamf Connect on physical machines so I think it's the OS + DEP.

@morsepacific That is pretty much what I'm seeing. The test machines are 10.15.6. They are DEP enrolled and scoped. The distro is set to cloud.

On a side note, how'd you get your VM in DEP?

This works like a charm for Parallels VM. I've used it for testing 10.15.6 and 10.14.6 VMs

DEP VM using Parallels Desktop

@waqas.khan That link doesn't load

@rpayne I've had success with these:
- Test Apple DEP with VMware, Parallels, and VirtualBox
- https://github.com/chilcote/vfuse (If you're using VMware Fusion)

Created NEW prestage, configured to skip user creation, added config profile with settings for connect, and added the connect 2.0 package. I scoped it to my test machine, wiped it, Went through the DEP process.... no package installed.

I had a similar issue a couple of days ago where I wasn't seeing the Jamf Connect login screen pop up and instead was seeing the default login. As it turned out, I'd deleted some older version configuration profiles for Jamf Connect and hadn't included the new ones in my prestage enrollment settings. Fixed that and all was happy again.

I had similar issue too. Not getting Jamf Connect login screen. Testing on macOS 10.15.7 (DEP enrolled).

I had a similar issue as well. I was using the default install package which runs authchanger at the end without arguements. According to the documentation, authchanger will look for Jamf Connect Login preferences and, if found, will configure the login screen with the correct settings. However, my Configuration Profiles were scoped to install when Jamf Connect was installed. So, they were not getting pushed down until after the installation package was installed. I need to change my scope to install the managed preferences to before I install the Jamf Connect package.

I am doing exactly that. I created the config profile in the new "jamf connect configuration" application and verified it was uploaded. It is included in the prestage enrollment.

Forgive me if this has already been suggested, but have you signed your prestage package?

@nixsky No need for forgiveness. It is not. When exporting the config profile, the signing part does not show our signing auth.

If your prestage package hasn't been signed, it won't get installed. So there be your problem.

There is a issue in 10.15.6 that is known to do exactly what you are describing. If you upgrade the machine to 10.15.7 and rebuild, do you have the same issue?

The package itself is an unmodified package straight from jamf. Should already be signed.

Is Jamf Connect.app in /Applications because if so, the pkg installed and it has to do with the authchanger and or config profile. That would at least tell you where to dig.

Any progress on this yet? I am having a similar issue. Mine works when testing with the JamfConnect.pkg directly from Jamf, but when using my own custom package it does not work. I have signed my package with an Apple dev account, and notarized it, but still my package does not install. My package also works when manually installed, or pushed via Jamf Remote, but just not in a prestage. I have checked the package with "spctl -a -vvv -t install & xcrun stapler validate" and suspicious package and both confirm it is signed and notarized.

@mbailey None. I can't get it going.

macOS does not have a mechanism to hold the setup assistant until the prestage enrollment packages are installed as there is no way to know how large the packages are when downloading them.

One option is to wrap the JamfConnect.pkg file in a metapackage and include a post installer script in the outer wrapper that does something like:

#####################################################################
# For zero touch enrollment only!  If an enrollment computer is on a slow
# network connection, the user may be presented with a standard macOS login
# window asking for a typed user name and password.  We must kill the loginwindow
# IF and ONLY IF we're at the Setup Assistant user still.  If we kill the loginwindow
# process while a user is actually using the computer, they will be unceremoniously
# kicked out of their current session.
#####################################################################

# For macOS Big Sur - Wait until they've decided that Apple Setup is Done.

while [ ! -f "/var/db/.AppleSetupDone" ]; do
    sleep 2
done

# Now we need to ensure Jamf Connect is running properly.
# Conditions are:
# 1) User initiated enrollments are not summarily logged out before the enforced restart
# 2) Devices that are still running the setup assistant are simply exited at this point
# 3) If setup assistant is NOT running, then we kickstart loginwindow to force a Jamf Connect load.
# Phew.
# Thanks to Richard Purves for the redesigned look for user and logic to exit the script 
# without a killall loginwindow if the Setup Assistant is still running.

# Look for a user
loggedinuser=$( /usr/sbin/scutil <<< "show State:/Users/ConsoleUser" | /usr/bin/awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}' )

# If loginwindow, setup assistant or no user, then we're in a automated device enrollment environment.
if [[ "$loggedinuser" == "loginwindow" ]] || [[ "$loggedinuser" == "_mbsetupuser" ]] || [[ "$loggedinuser" == "root" ]] || [[ -z "$loggedinuser" ]];
    then
        # Now check to see if Setup Assistant is a running process.  
        # If Setup Assistant is running, we're not at the login screen yet. Exit and let macOS finish setup assistant and display the new Jamf Connect login screen.
        [[ $( /usr/bin/pgrep "Setup Assistant" ) ]] && exit 0

        # Otherwise, kill the login window so it reloads and shows the Jamf Connect login window instead.
        /usr/bin/killall -9 loginwindow
fi
exit 0

Refer to https://www.jamf.com/jamf-nation/articles/651/customizing-the-jamf-connect-login-package-with-composer for details on how to make a metapackage with Composer