Self Service+ replacing Jamf Connect? Confused after upgrade

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 [ -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. 

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+

I´m interested in this either.

I also found this transition between Self Service+ and Jamf Connect quite confusing.
To provide some context: I had no plans to migrate to Self Service+ at this moment, as I’m still structuring the Mac infrastructure in Jamf. Moreover, support for the classic Self Service runs until March 2026, so I still had time to plan this change properly.

However, I was forced to move forward with the update after the release of macOS Tahoe 26.1.0, where the issue mentioned in

 started occurring. From what I found, the suggested solution is to update Jamf Connect to version 3.5.

That’s where the confusion began: it’s unclear whether I should update only Jamf Connect Login, Jamf Connect MenuBar, or both. I’ve been running several tests, but none have been successful so far. Even after installing version 3.5.0 downloaded from the Jamf Portal, the application doesn’t seem to actually update.

Without official documentation explaining these changes clearly, the whole process becomes quite complicated.

I am also trying to resolve the Tahoe ‘keychain’ issue we are seeing with JAMF Connect.  I downloaded the JAMF Connect 3.5 updater and tried running the install package which is now called “JamfConnectLogin.pkg’.  The package installer says that it runs and completes, but doesn’t install the app.  As far as I can tell it installs some support files, but not the app itself.  

THIS! First time posting in Jamf Nation just to say that 😅 I was planning to use the next month or so to get ready for Self Service+ and prepare an overhaul of Self Service items/policies at the same time so the change would be a big improvement for users when switching in the new year. Now I need to rush it out the door to fix the keychain issue.

Working on identifying the best migration path now. Per the deployment documentation, there’s an automatic option or a manual policy option:

#1: The automatic option is the “Use Self Service+ as the default end user application” checkbox in settings (Jamf Apps > Self Service+) that handles (1) deployment of Self Service+, (2) removal of Self Service classic, (3) automatic application of Jamf Connect password sync and privilege elevation configs to Self Service+ (that might happen anyway though?), (4) uninstallation of the legacy Jamf Connect menu bar app which SS+ also replaces, and (5) automatic updates of Self Service+ going forward. That all sounds amazing, but there’s NO way I’m trusting a global checkbox without being able to test it first. I wish they had the option to apply that to a group first instead of everyone!

#2: The manual policy option seems like a headache as Self Service classic and Self Service+ would coexist at first which could cause confusion, and then you’d need to do all the other removals/updates/etc. yourself. I’m fine using that to test Self Service+ itself, but that doesn’t really validate the automatic process above which makes many more changes at once.

I think I’ll go with the automatic option as long as I can test it in the sandbox instance that came with our Jamf Pro purchase. Just need to replicate a lot of the Jamf Connect / Self Service configs and enroll some test machines first which is a pain, but hopefully it’ll pay off in the long run.

Hey dsonzera, MatthewPalasz, samuel.24323 - I just wanted to jump in to help try and clear some things up. The fix that was released for the keychain issue is resolved by updating to Jamf Connect Login 3.5.0. When you install the Jamf Connect Login 3.5 package available on Jamf Account - you will only see that the Login piece is updated to 3.5 as Menubar is no longer packaged with Login since the 2.45 series. That is why you don’t see the app within the installer package. With that said -  there are folks out there running Login 3.5.0 and 2.45 menubar without Self Service Plus just fine. Generally speaking though it is best case scenario to be fully updated on all fronts to ensure the smoothest experience in case that changes. For this issue though - the only piece needing updated is Jamf Connect Login 3.5.0. I hope that helps clarify!

Tyler Wehrman
Jamf
Senior Technical Support Escalation Engineer

Ahh, that’s so helpful ​@tyler11, thank you!! Since the keychain pop-up was the menu bar app (or SS+ in that linked post) requesting access, I missed that the root issue is just on the Login side.

Our normal method of updating JC has been the “Jamf Connect Deployment and Update Settings”, and version 3.x isn’t available in the dropdown. I assumed that’s because we’re still on Self Service classic, which took me down the SS+ path.

But if grabbing the 3.5 Login package and deploying it in a policy is all that’s needed for the keychain issue, that’s much easier! (Though yes, we’ll still prioritize the SS+ transition afterward :)

Hey ​@tyler11, 

Thanks a lot for clearing that up! That makes way more sense now about the Login and Menubar packages. I’ll give the Jamf Connect Login 3.5.0 update a try and see how it goes. Really appreciate the help!

Hey guys,

Quick update: everything’s working fine now! I tested the Jamf Connect Login 3.5.0 package on a few MacBooks in my environment, and the prompt finally stopped showing up, even though we’re still on the classic Self Service.

I just updated Jamf Connect for the macOS Tahoe macbooks that were having the issue. Now I can take my time planning the move to Self Service+.

Thanks a lot! 🙌

I can't understand how it works now.

I previously had Jamf Connect version 2.45.1, and when I activated Self Service+, it updated me to version 3.11.0.

I was advised to standardize to version 3.5.0, but I can't install it. I install the pkg, but it doesn't install.

At the same time, SSO login stopped working. Activating Self Service+ is truly catastrophic.

What an absolute dumpster fire this turned out to be.  I pushed 3.5.0 simply to get the keychain issue fixed but having 3.5.0 installed with the old 2.45.1 on the menu bar isn’t confusing at all (no sarcasm detected).  We don't even use Self Service, so why do I want Self Service +??  We just automatically push apps… did Jamf tech not consider that some customers do this and have no use from Self-Service?  Now we HAVE to have SS+ just so Jamf Connect IDP will work???  Funny how the “poop” emoji isn't available here, cause it’s required for this conversion (lots of em!)