How are you installing the Jamf Connect package? 

Are you installing it in your prestage so that it gets installed during setup?

Do you you have your Jamf Connect configuration profile scoped in your Prestage AND properly scoped so it doesn't get removed after install?

If you are doing all that, when did you upload your package to Jamf? Was it in the last month or so? There is a Product Issue with Jamf 11.11 & 11.11.1 where uploaded packages are not being checksummed correctly and will fail to install in a prestage. It is supposed to be fixed in 11.12, which hopefully will be released soon. 

It you did just recently upload the package, contact Jamf support, I think they have a work around to correct the file upload so you can use it in your Prestage.  

Thanks for you reply! Yes, I've included the package in the prestage, scoped in on the same computers as configuration profiles. But I've re-uploaded the package today and our instance is on 11.11.2... So perhaps that is the issue. I've contacted the support as well, so we will see. 

If you are using jamfconnect 2.42, it fails to install on prestage. Use version 2.41

If you are deploying a branding package via prestage, it must be signed correctly.
Here is the relevant help files page - Packaging Jamf Connect Files and Images with Composer 
and here is a link to Creating a Signing Certificate Using Jamf Pro's Built-in CA to Use for Signing Configuration Profiles and Packages 

@mickgrant jamf connect packages are already signed by Jamf and notarized by Apple

Jamf Connect packages are, but any logos or branding being deployed to be used by Jamf Connect must be signed. Which is why I posted the links to the documentation where it says as much

I'm not.

Oh really? So both Jamf Pro and Jamf Connect latest versions are bugged? 😳

It really looks like the package didn’t even install. Account creation was skipped and admin account was hidden from the user as configured in the prestage. I tried deploying connect version 2.41.0 with the same result.

Check the management logs. Under history of management logs, you would see something like this if it is installed. 

cross check jamf connect configuration profile, make sure Idp is reachable on the network and url is mentioned correctly

We can now also observe the error with us. Account creation during the PreStage does not work.

So still no response from Jamf support. I’m really starting to question the decision to get Jamf in the first place.

What IdP do you use?

Yeah, well the log shows the entry and it’s not failed, but I think the application still isn’t running or maybe it didn’t even install.

Entra

Found the error in our system. In the PreStage Enrollment profile, the distribution point of the Jamf Connect package was set to None....

So I've got the same result with 2.41.0 as well

We have Cloud Distribution Point (Jamf Cloud)

So the tech support just replied, saying it's probably the same known issue as in version 11.11. They're suggesting this workaround:

PreStage Enrollment packages fail to deploy in Jamf Pro 11.11.0 due to missing MD5 value
Until [the upcoming version] , the workaround is to use Terminal to calculate the package's MD5 value, then use the Jamf Pro API to apply it to the package record.

The MD5 can be calculated in Terminal via the following command:

md5 /path/to/file

You can drag and drop the file into Terminal to automatically fill in the path.

Next, collect the package record from the Jamf Pro API using a GET command against the /v1/packages/{id} endpoint. Copy the resulting XML, and add the "md5" value, then use a PUT command against the same endpoint to insert the MD5 value.

::Workflow example::
The correct checksum can be calculated in Terminal against a package with these methods:
md5 /path/to/package.pkg

shasum -a 512 /path/to/package.pkg

Package records can be checked and updated in Jamf Pro via the API. For example, we'll check for example a package with ID 116, "AdobeReaderDC-latest.pkg":
curl -X 'GET' \\
 'https://'instance name'.jamfcloud.com/api/v1/packages/116' \\
 -H 'accept: application/json' \\
 -H 'Authorization: Bearer <token>'
Returns the following response:
{
 "id": "116",
 "packageName": "AdobeReaderDC-latest.pkg",
 "fileName": "AdobeReaderDC-latest.pkg",
 "categoryId": "-1",
 "info": "",
 "notes": "",
 "priority": 10,
 "osRequirements": "",
 "fillUserTemplate": false,
 "indexed": false,
 "fillExistingUsers": false,
 "swu": false,
 "rebootRequired": false,
 "selfHealNotify": false,
 "selfHealingAction": "nothing",
 "osInstall": false,
 "serialNumber": "",
 "parentPackageId": "-1",
 "basePath": "",
 "suppressUpdates": false,
 "cloudTransferStatus": "READY",
 "ignoreConflicts": false,
 "suppressFromDock": false,
 "suppressEula": false,
 "suppressRegistration": false,
 "installLanguage": "en_US",
 "md5": "dbc11b91d3812a32f31ba077249bba7e",
 "sha256": "",
 "hashType": "MD5",
 "hashValue": "",
 "size": "",
 "osInstallerVersion": "",
 "manifest": "",
 "manifestFileName": "",
 "format": ""
}

But the actual package could show a different MD5 value when checked locally:
md5 /Users/‘Username’/Desktop/Replication\\ Folder/AdobeReaderDC-latest.pkg 
MD5 (/Users/’Username’/Desktop/Replication Folder/AdobeReaderDC-latest.pkg) = 56d5629a12bb19d898d155acfa55f503

We would then need to update the package record with the correct MD5 value:
curl -X 'PUT' \\
 'https://'instancename'.jamfcloud.com/api/v1/packages/116' \\
 -H 'accept: application/json' \\
 -H 'Authorization: Bearer <token>' \\
 -H 'Content-Type: application/json' \\
 -d '{
 "packageName": "AdobeReaderDC-latest.pkg",
 "fileName": "AdobeReaderDC-latest.pkg",
 "categoryId": "-1",
 "info": "",
 "notes": "",
 "priority": 10,
 "osRequirements": "",
 "fillUserTemplate": false,
 "fillExistingUsers": false,
 "swu": false,
 "rebootRequired": false,
 "selfHealNotify": false,
 "selfHealingAction": "nothing",
 "osInstall": false,
 "serialNumber": "",
 "parentPackageId": "-1",
 "basePath": "",
 "suppressUpdates": false,
 "cloudTransferStatus": "READY",
 "ignoreConflicts": false,
 "suppressFromDock": false,
 "suppressEula": false,
 "suppressRegistration": false,
 "installLanguage": "en_US",
 "md5": "56d5629a12bb19d898d155acfa55f503",
 "sha256": "",
 "hashType": "MD5",
 "hashValue": "",
 "osInstallerVersion": "",
 "manifest": "",
 "manifestFileName": "",
 "format": ""
}'

Is FileVault enabled?  If yes, this is the expected behavior.  If you want the IDP login screen to appear with FV enabled, you must modify your plist.  https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Turning_On_FileVault_with_Jamf_Connect.html 

Hi liska,

I have recently signed up with Jamf and already started to question my decision because of the extreme LACK of support.