I’m highly interested in this aswell. Especially for Point 4!!
Self Service Plus has Jamf Connect embedded in the .app. It’s very strange.
We install Jamf Connect at enrollment to make sure it hits the login screen. SSP will auto-update it once it installs.
SSP does have some quirks - like if you’re leveraging kerberos tickets with AD. I can get into the specifics if you hit this unlisted PI that we found, but hopefully no one does.
Point 4: Install SSP (replace classic Self Service). It’ll auto upgrade Jamf Connect on install.
I can understand the confusion, as we ran into this ourselves. However I have to ask, “When was the last time you actually looked for and launched the JAMF Connect.app?”
As long as you have installed at enrollment “JamfConnectLaunchAgent”. Then the menu applet will be there for you to use. It’s when you don’t see it that you have to actually launch JAMF Connect to get the menu applet. This function is just to bring up the applet, it doesn’t imped the functionally of the JAMF Connect. It still works at login, it still creates account, it works. It’s just this little piece that is missing from our menubar.
When you install SS+, you notice that the JAMF Connect.app is no longer in your Application folder. It’s been removed as part of the install. However all of plumbing is still there. authchanger is still located in /usr/local/bin/. If you don’t see the new er] menu applet, all you have to do is launch SS+ to get the menu item.
From what I can see, it comes down to two things. The first part is the hardest, retraining our users. Need for comms will be crucial for this one. The second part is a better “migration process” to help not only our users, but us the “admins” as well. I feel that we have some opportunities here JAMF. We need a better documented process/method to help us get this across the finish line.
One can only hope that we’ll get some updates on this at JNUC. As SS+ is and continue to be an evolving and moving target we are all tracking.
Our docs for password change uses the menubar app. We effectively only changed our docs to the new menubar icon and everything else remains the same.
Granted, now they can use SSP to change their password now too, the OG workflow works the same minus the menubar icon.
Jamf Connect is essentially split into two separate and distinct apps now:
Jamf Connect Login - which handles user creation at the login screen.
Jamf Connect Menu Bar - which handles password syncing after a user has already been logged in.
In Jamf Connect 2.x.x the menu bar & login portions of the app were contained in the same install package, and most everyone thought of both apps together as just “Jamf Connect”.
In Jamf Connect 3.x the Jamf Connect Login installer in your account.jamf.com portal is exclusively for the login window and user creation. Jamf Connect Menu Bar is embedded into Self Service+. So if you install Self Service+ you have the Jamf Connect Menu Bar application. So if you move to Jamf Connect Login 3.x+, you have to have Self Service+ as well.
If you are utilizing Self Service+, and thus Jamf Connect Menu Bar 3.x+, you probably want to begin installing the Jamf Connect Login 3.x+ application during your prestage. The combination of Jamf Connect Login & Self Service+ will preserve the functionality we all knew as just “Jamf Connect” a few months ago.
The even more confusing thing is the embedded Jamf Connect Menu Bar application within Self Service+ reports as a different version number as Self Service (Self Service+ is 2.8.0 right now, Jamf Connect Menu Bar is 3.8.1). ALSO Jamf Connect Login has been moved from /Applications to /Library/Application Support/JamfConnect, so its version is not being inventoried natively by Jamf. Jamf Connect Login is currently version 3.3.0. The only way to inventory the Jamf Connect Login version is through a custom extension attribute. I’ll put my EA below.
#!/bin/bash
# Path to the Jamf Connect JCDaemon app
JAMF_CONNECT_PATH="/Library/Application Support/JamfConnect/JCDaemon.app"
# Initialize result
RESULT="Not Installed"
# Check if the app exists
if -d "$JAMF_CONNECT_PATH" ]; then
# Extract the version of the app
VERSION=$(defaults read "$JAMF_CONNECT_PATH/Contents/Info.plist" CFBundleShortVersionString)
# If a version is found, set it as the result
if u -n "$VERSION" ]; then
RESULT="$VERSION"
else
RESULT="Version not found"
fi
fi
# Output the result
echo "<result>$RESULT</result>"
In short this has been an extremely confusing change for most admins, and some of the decisions around this are fairly puzzling. Why does the login & menu bar app need to be contained in separate installers? Why can’t the login app live in /Applications so it can be inventoried natively? Why is the versioning so different?
I personally don’t like to have Jamf Connect Login update automatically via Jamf Pro - I like to test thoroughly and then push the update myself. Doing this for the 2.4.x release, where a lot of UI things changed with no advanced notice saved me a lot of headaches many other admins went though. And now the only way I can update this Jamf tool is with using logic from a custom extension attribute? That is sub-optimal and poorly thought though.
ALSO Self Service classic is being deprecated in favor of Self Service+ in March, so the use of the 3.x+ version of the menu bar app will be mandatory in a few months.
Jamf Connect is essentially split into two separate and distinct apps now:
Jamf Connect Login - which handles user creation at the login screen.
Jamf Connect Menu Bar - which handles password syncing after a user has already been logged in.
It’s regressed lol. It used to be Jamf Connect Login and Jamf Connect Verify...eerily similar to what it is today with JC 3+
