Push failed. Values for APN Token and Push Magic cannot be blank.

[patrick030]

Hi,

since yesterday we cant enroll new devices to our prestages (prod and int), the error is the following: "Push failed. Values for APN Token and Push Magic cannot be blank".
We have not changed anything and also all certificates up to date.
Has anyone similar problems for 1 or 2 days??

Thx
Patrick

[LangStefan]

same here.

First we had this issue: https://www.jamf.com/jamf-nation/discussions/36546/there-was-a-problem-communicating-with-a-push-server
And since it is resolved, I see the same error message in our environment.

[patrick030]

It looks like that the problem was solved from Jamf support some minutes ago for us.

Update issue still NOT solved!

[msc_i22]

Same problem here today!

[user-PSNfcUCjmc]

Same problem here, I have a case open with Jamf.

[sim_brar]

Also experiencing this. Incident ticket opened with Jamf.

[sim_brar]

Update: Someone on the MacAdmins Slack workspace shared the following workaround: In the JSS, hit Cancel on the following failed command: DeviceConfigured.

[patrick030]

@sim.brar yes that correct. there is another discussion for this topic where i already posted the "workaround": https://www.jamf.com/jamf-nation/discussions/36546/there-was-a-problem-communicating-with-a-push-server#responseChild206007

[JamelB]

Same issue for me since yesterday, working with the jamf support on it but still not soilved

[mntbighker]

My first ever pre-enrollment test was today, and I have the same issue. My boss wants to factory reset, and re-attempt when this is resolved, since nothing that was supposed to install happened. But since it now exists fully in Jamf I'm unclear if this is even possible. That ship has sailed yes? Can we perform a valid pre-enrollment test after the laptop has been added to Jamf already?

[mntbighker]

I just did a manual Recon adoption and had the same problem. I have a case open. Looks like I can't adopt anything into Jamf at the moment. At least not "fully".

[LangStefan]

is it working for everyone now? What did the Jamf support say?

[JamelB]

Still not working for me, waiting for jamf support feedback

[JamelB]

Workaround which works for the moment, from the JamF Support :

Could you please skip the enrollment at the setup assistant with the next device you will enroll (Other network options -> My device does not connect to the internet) and execute following command from the desktop: sudo profiles renew -type enrollment

[patrick030]

@JamelB valid workaround and i´m pretty sure this will work.
The problem is that we have designed a nice "zero touch" enrolment and tomorrow is onboarding day and we have to manage remote onboardings as well...i cant tell newbies please open terminal and enter the command (some of them never used a mac)...
I cant understand why this problem is still present, i reported this already early last week to jamf.
I´m a bit frustrated at the moment with the handling of such important topics.

[david_edgar]

Holy cow this is still an issue? We have fac arriving today having issues. How has this not been solved?

Update: In the JSS, hit Cancel on the following failed command: DeviceConfigured.

[mntbighker]

The problem with the so called workaround (hit cancel on DeviceConfigured) is that the Kerberos SSO deploy still fails. It appears in Profiles as a blob of XML instead of the way it's supposed to, and no menu bar key symbol ever appears. Also, one of the Jamf Profiles doesn't install. The system does appear in Jamf, but it's not adopted fully. The sudo command does not seem to address Recon enrollments. And if Jamf has workarounds they did NOT annotate my open ticket as such.

[JamelB]

Still same issue for me today, waiting for JamF Support... Do you have any answer on your side ?

[JeWe]

Same problem still here. (West Europe cloud)

Process , looping while enrolling.

[Jonathan_Kane]

Chiming in here with the same issue. The "workaround" got us hobbling along until the issue is fixed. Thanks so much @sim.brar and @patrick030 !

[patrick030]

@JamelB no, i have also no feedback on my request.

[JamelB]

Best workaround is clearly to use this. I was able to enroll some devices today with this process.
Please note you may have to click "Cancel All" multiples times refreshing the web page for the enrollement to continue on the device. I searched the device per SN in JamF. The name in JamF should be "DEP - SERIALNUMBER".

[mntbighker]

What would set the names to DEP - serialnumber? None of mine are set to that. Using Cancel All may get them to appear in Jamf, but they are fundamentally broken on the client side so it's hardly useful. With missing and/or broken profiles.

[andrew_nicholas]

In case anyone is stilling working at this and hasn't opened a case, PI-008754 was the product issue I received from support, though it doesn't appear in the Known Issues just yet.

[mntbighker]

I got:

In regards to the enrollment issue, the Jamf Pro Server log is confirming that what is being encountered is a known issue we have filed as PI-008661. This is reported fixed in an upcoming release of Jamf Pro.

And they would not say when it's getting pushed, but they marked my case inactive.

[patrick030]

Hi everyone,

i get this information back from jamf: "I'm really sorry for the problems you've been experiencing and the manual work you've had to put in to make the workaround possible. At the moment however, there is no estimation yet concerning this PI and when it will be fixed. I'm afraid the only temporary solution is the workaround. I understand this is far from ideal. Again, my apologies for the inconvenience caused by this."

[maffettb]

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.

[mntbighker]

Unacceptable

[mntbighker]

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".

[andrew_nicholas]

@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.

[mntbighker]

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.

[andrew_nicholas]

@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.

[martin_kouba]

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... :/

[GabeShack]

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

[sajancar2go]

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.

[jzarate]

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

[ronhunter212]

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...

[hlans]

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

[ronhunter212]

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