I suspect this is more of an Apple requirement than an jamf implementation.

No doubt at all with regard to an Apple-specific requirement.

Still, this is valuable info for those using Jamf Pro for deployment - given that multiple enrollment packages are a new thing, it would be great if Jamf could stress any Apple requirements in their documentation of the expanded feature. In other words, if a signed package is required for successful deployment at enrollment, regardless of who imposes that requirement, it should be noted in the feature documentation and not simply assumed.

Is there a FR written to change the language? If not the request will not be seen..

You can create your own Jamf Signed cert to do this. @pruokis Look at this guide from HCS to do this. HCS Link

@cdenesha - good call on that; I'll contact our account rep for that request, as it's not really a feature request, but a request for clarity in documentation.

@kericson - thanks for the link, but we already have an Apple dev installer signing cert to use for this - the disconnect is that the signing requirement is not currently documented by Jamf relative to the expanded enrollment package payload documentation.

I followed this setup from HCS but when I enroll a device with DEP the package fails and the MDM history in the jamf record shows: No Manifest could be created for the package.

Any ideas anyone?

Thanks for the suggestion about adding clarity to our documentation around enrollment packages! I've shared the feedback with our technical communications team and we'll work on making that information better.

Update: the team had already made some updates to the 10.20 admin guide in response to feedback on Jamf Nation. Check it out and let us know what you think. Some additional enhancements to the organization and layout of that information will be coming in 10.21 admin guide as well.

@cjatsbm, I was seeing this same thing and opened a ticket which eventually led us to PI-007954. Jamf Admin is supposed to create the manifest automatically when the package is signed, but we were seeing it not report the size of the package, which is apparently related. You could verify this in your own environment by seeing if you have package size info for whatever package it is in the database. Support gave me "select size from packages where package_name="<package_name_here.pkg">;" for the SQL to find that.