There was some discussion on the Mac Admin’s Slack this morning about macOS pkg files not deploying via ADE prestage configuration. I’ll give you the quick guide on how to avoid this first, the explanation of what I think is happening is later.

EDIT: I am assuming you are correctly signing your custom pkgs with an Apple Developer Installer certificate here. Notarizing is not necessary for this process.

For maximum reliability when adding replacement packages to a prestage, do the following:

• Upload your package as a totally brand new upload. Do NOT upload over an existing pkg.
• Let Jamf Cloud settle and do it’s backend processing. A minute or two at most.
• Go to your prestage. Remove the existing old package from it.
• Click save and wait a couple minutes for the system to process and sync up to Apple.
• Back into the prestage. Add your new package.
• Save and wait again.
• Test a deployment.
• If ok, remove your old package.

I personally do not care for this process but it’s how I found to make it reliable in operation.

Now onto what I think is going on.

Apple requires as part of the InstallEnterpriseApplication mdm command that the supplied pkg have a fully computed SHA256 hash.

Jamf Pro does indeed compute a SHA256 hash when you upload a pkg to it and stores that as part of the pkg record in it’s database.

Adding a new package to an ADE prestage means that a separate manifest file is generated based on the existing pkg record details. This in turn is then uploaded to Apple.

There’s two potential points of failure here (and I must stress I am guessing at this point based on observed behaviour and a couple chats with Jamf support in the past):

First is the upload to Apple. We don’t know the behaviour of Apple’s own backend when confronted with a pkg that’s suddenly just been replaced.

EDIT: I’ve had a private message from a very knowledgeable engineer at Jamf about this process. I’ll direct quote:

Jamf Pro just uploads an enrollment profile to Apple containing things like org info, enrollment URL, and skip steps, also including the setting to enable await_device_configuration

Once MDM enrollment happens, macOS keeps the computer in Setup Assistant hold until it hears the “all clear” from MDM.

During this stage, Jamf Pro sends any Enrollment Package install commands, possibly some config profiles, and sends the AccountConfiguration command, if applicable for the PreStage.

After commands are sent, then the DeviceConfigured command is sent to release from Setup hold.

So there’s a good chance my waiting for sync to Apple is totally unnecessary. End EDIT.

Second is (and I have seen this) the possibility that the Jamf pkg record can either not update or completely drop it’s SHA256 hash entry. In ordinary use this isn’t even an issue: it’s only Apple’s requirements that cause whatever bug this is to be an issue.

Anyway the above is a combination of guess work, observed behaviour and things I’ve been told. The workflow above is what helps you avoid all that.