I ran into this issue Friday so I haven't filed a ticket yet but is it worth it to even bother?
Does this workaround actually work? Either hitting cancel or running the command.
Are the machines actually managed and supervised after doing this? The way I'm reading this is that it gets it into the JSS and essentially just makes JAMF and the machine shut-up and skip some steps.
I do way more by hand work when enrolling my machines than I care to admit but I'm new-ish to mac management and my users all have individual needs...and not the tech skills to meet them on their own.
I'm also needing to issue machines that are going right to the mail box to end up in student's hands with standard accounts for at home remote learning...if I don't have access to push config profiles to the machine or user account or the device isn't fully supervised, this workaround does me no good especially if I need to completely wipe the machine once the issue is fixed to get it through DEP enrollment and supervision properly.
I agree with all of these comments...how has this not been fixed yet??? And why do we get notified about security issues and Emergency updates through every line of communication JAMF has with us but something like this, I spent 4 hours messing around trying to get it working and resigned to searching here for info and found this...we often have several hats to wear every day, it would have been great to be notified before wasting time I didn't have in the first place.

Unacceptable

Does this affect only people using the JIM LDAP proxie for on prem AD? If we start paying the insane cost of Azure LDAP does it mitigate this bug? My boss says "Jamf is the market leader... seems like there must be some way to get this working".

@mntbighker I don't have an answer to your question, but I can say this issue only occurs for my devices when the prestage includes an account creation step, either the Apple default step or through an LDAP/AD lookup. Our prestage that only creates a local account works without issue each time. The provided workaround really is the only option currently and frankly is pretty disappointing given the amount of "setup zerotouch" emails I am still getting.

My attempts at a Recon adoption resulted in the same errors, and they have no LDAP lookup. Just the creation of the hidden account. That account gets created by Recon with the credentials entered in Recon locally. It seems the issue is with stuff (Profiles) getting from the Jamf server to the client via port 443. According to the tech this morning, Macs with the T2 chip are failing to receive the payload. Refusing might be a better word. He said they have many issues related to the T2 chip. This is just one of them that they claim to have fixed in the next release. Many other issues are not fixed.

@mntbighker I was incorrect in my PI and apparently it may be that this issue is closer to PI-008661, which states it as a problem with using the HTTP/2 protocol for APNS. You might want to roll this back to the binary method if you can to test. Also, I was getting the issue repeatedly on a non-T2 device so I don't think that really plays into it.

Bouncing off several people who mention canceling "DeviceConfigured" to get it to finish, I've figured out a more complete work around for people who have more complex pre-stage setups (such as installing pre-stage packages etc).
1.) Under Failed Commands, cancel every failed command OTHER than "DeviceConfigured"
2.) Refresh the page and ensure that the only command remaining under failed is "DeviceConfigured." If necessary cancel any other failed pushes.
3.) Cancel the failed "DeviceConfigured" push. The device should now finish enrollment and move on to the next step in your workflow.

Caveats: If you use a workflow that includes an initial config kickstart or something similar, you may find that a normal checkin will kick off before the kickstart runs, which may affect your policy order of operations.

I've tested it a couple times, but it may not work perfectly for every case... :/

Jamf support just told us this is not resolved in 10.24, but 10.25 with no release date.
We have 2500 devices that are needing to be configured. This is a nightmare!
What are we paying for? We have a provisioner working with Apple to set these devices up for us and our school year starts on Monday. This was introduced in one of the more recent jamf updates and yes the PI number isn't listed in the current list of issues.

Gabe Shackney
Princeton Public Schools

Jamf is premium product, and the price that we pay for per device is not justified with the various issues we are experiencing. Everything from inventory updates, APNS errors, etc. I think the quality of the product has drastically decreased with last 1 version of release (10.23.xx). Now it looks like you are only focused on the IPO and the listing and the stock markets. Product quality is no more a priority.

Can confirm that this is still an issue, amongst other errors like "Couldn't communicate with a helper application."

It's an old thread, but for the Googlers: Jamf has a page up about this error and more, including possible fixes:
Supporting Apple Push Notification Service (APNs) Over HTTP/2

im assuming these are cloud instances so the option to restart tomcat would not be available

uhm the best way i could see resolving the issue would be removing it from jamf  pro and deleting the record, next go into your pre-stage and remove it from the group wait a minute or so then assign it back to a group. restart the machine let it boot to the OS and run sudo profiles renew -type enrollment and see what happens...