Jamf Connect, Self Service+ and OKTA

​@paczo Self Service + integrates the Jamf Connect menubar functionality (Jamf Connect.app). Self Service + removes the older menubar app bundle upon deployment, but it doesn’t touch the JC Login component; that needs to be deployed separately, which it sounds like you are doing. 

It seems to me like what you are describing is that the legacy, full Jamf Connect 2.45.1 suite got deployed onto a system after Self Service +  and the newer JC Login were deployed. I would check your Jamf AppInstaller and Jamf App deployments to ensure that the legacy 2.45.1 JC suite isn’t still enabled for deployment. Once you’ve toggled all of that off, you could manually create a policy to reinstall the SS+ and JC Login PKGs, which should cleanup all those old components. You could likely script that process, too, but deploying the PKGs might be the simplest route.

Thanks a lot for the detailed explanation!
This also lines up with what I’m seeing on our side. At the moment, the legacy Jamf Connect 2.45.1 suite is still scoped to all managed clients, which explains why the old menubar component keeps showing up even on devices that already have Self Service+ and the newer JC Login.

It’s also worth mentioning that our Jamf environment hasn’t really been touched for about three months because there was no administrator in place. I’ve just stepped into this role and I’m trying to get a clear picture of what should (and shouldn’t) be deployed going forward.
Just to confirm that I’m understanding this correctly:

The item shown in my screenshot the old “Jamf Connect” menubar app shouldn’t be deployed automatically anymore via Mac Apps, correct? Instead, Self Service+ replaces that part, and I should separately deploy the latest JC Login PKG.
So the ideal state for our environment should simply be:

Self Service+
Jamf Connect Login

And no legacy JamfConnect.app menubar components, right?

​@paczo Yeah, so moving forward, you would disable the “Jamf Connect” deployment and instead turn on the deployment for “Jamf Connect Login.” Self Service+ will be kept up to date automatically by Jamf Pro, so nothing special needed there. Self Service+ will take care of the Jamf Connect menubar functionality moving forward.

Thanks a lot, i’ll do it, i do appreciate it.

Well, but i can see that i need to do one more thing, because during the prestage enrollment, those packages are being deployed.

Any advices how to deal with it, what should i replace it with?
 

That’s what i thought.

I’ll do it and enroll a test device.

Thanks for yor help! 

Have a good one 

I’m coming back with one more finding.

Here’s what I did step-by-step:

In Mac Apps, I removed my test device from the scope of Jamf Connect 2.45.1.
In Mac Apps, i add my test device to the scope of Jamf Connect Login 3.5.0

I then manually forced a re-installation of Self Service+.

After the reinstall, the versions updated correctly:

JamfConnect:Menubar
Version: 2.13.0
Build: 2.13.9251104.1
****************************
JamfConnect:Login
Version: 3.5.0
Build: 6785
****************************
JamfConnect:Daemon
Version: 3.5.0
Build: 621
****************************
JamfConnect:SSPDaemon
Version: 3.11.0
Build: 619

Everything looks perfect at the component level.

But from that moment on, my profile that grants temporary admin access stops working.
I’m using the same command as before, and it simply does nothing now.

 

sudo defaults delete com.jamf.connect.state TimeTamperingDetected; sudo -u $( /usr/sbin/scutil <<< "show State:/Users/ConsoleUser" | /usr/bin/awk -F': ' '/[[:space:]]+Name[[:space:]]:/ { if ( $2 != "loginwindow" ) { print $2 }}                        ' ) /usr/local/bin/jamfconnect acc-promo --elevate

Any idea what could be causing this after replacing the legacy Jamf Connect with the new 3.5 components?