Hey @j_allenbrand1! I would recommend signing profiles from Configuration before uploading to Jamf Pro. Otherwise if signing isn’t something available to you (really you can sign with any sort of a certificate), it may be easier to recreate the profile within Jamf Pro’s configuration profiles interface. 

@mikevandelinder  re-creating the profile would be using a plist upload vs mobileconfig? 

Got any information on manually re-creating them instead?

oh, yes, uploading the plist would definitely work, otherwise by going to Computers > Configuration Profiles > New > Application and Custom Settings > Jamf Applications > Add > com.jamf.connect* to create profiles for the different apps.

the info from the created Plist in Jamf Connect Configuration, We want one for Login and Menubar 

would  "com.jamf.connect* be for both of them? 

or would the menubar URL be different for that one? 

Our profiles weren't signed, we uploaded both the Login and Connect .plist from Jamf Connect Configuration. The three .pkg were signed in PreStage Enrollment Packages were Jamf Connect, the LaunchAgent, and the Menubar pkg that contains icons and logos. We don't use Okta, so I can't help with that. 

@YanW Where did you get the menubar package?  

We put our Jamf Connect packages in PreStage Enrollment. 

We use Composer to customize the Menu Bar, it's just background, icons and logos.

Then we uploaded them to the PreStage Enrollment Packages, but you the they must be signed.

com.jamf.connect is the domain used for the menubar application

com.jamf.connect.login is the preference domain used for the login window plugin

We have this exact issue as well. My understanding was that configuration profiles would be auto-signed by the JSS. I have a case with a senior Jamf engineer open and will update this with their response. In the meantime, I've expoted the plists from the JCC app and pushed those instead.

The engineer did recommend not configuring Connect via the Jamf Pro UI, as apparently it always results in a very cluttered plist as it specifies many options unless you override them.

Thats the same as me. One question, how did you get the login screen pgk to install and run?  I am able to get jamf connect to instal and prompt and reboot, but not re-directing to the jamf connect login screen. 

@j_allenbrand1 you'd want to make sure that a profile configured for "com.jamf.connect.login" is deployed to the Mac prior the Connect installer running. The installer package looks for settings in that profile to determine how to configure the login window. If there's no profile, the Connect login window will not be enabled. If you're just testing, after installing the profile run the Connect installer package a second time for it to pick up on the changes.

Just FYI, we resolved this by ultimately just pushing out PLISTs generated from the JCCU app and adding them into a 'Custom Settings' profile payload. I actually prefer the app to the UI in Jamf Pro for configuring Connect, and think UI improvements need to be made within Pro to better match the app.

Also, the discrepancy in what gets deployed in the profiles deployed from the Jamf Pro UI vs the JCCU app needs to be addressed as absolutely no mention is made that this is the case when using the Jamf Pro UI to configure Connect.

Hi @j_allenbrand1, only just clocked that your reply was addressed to me so I apologise for the delayed response.

We aren't deploying Connect via a PreStage PKG; I just deployed the Connect PKG as I would for any other app install policy and it worked. The user was directed to the Connect log-in screen at the next reboot. I have deployed it previously via a PreStage PKG, and that worked immediately - the user never saw the stock macOS log-in screen. My issue with that method, though, is that you don't get a Bootstrap Token for FileVault and OS updates for Apple Silicon Macs if you deploy an Admin account via the PreStage and the local account the user syncs with their M365 credentials via Connect is just a Standard account.