Posted on 08-25-2020 12:34 AM
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??
Posted on 08-25-2020 01:54 AM
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.
Posted on 08-25-2020 04:19 AM
It looks like that the problem was solved from Jamf support some minutes ago for us.
Update issue still NOT solved!
Posted on 08-26-2020 05:44 AM
Same problem here today!
Posted on 08-26-2020 12:10 PM
Same problem here, I have a case open with Jamf.
Posted on 08-26-2020 04:44 PM
Also experiencing this. Incident ticket opened with Jamf.
Posted on 08-26-2020 04:50 PM
Update: Someone on the MacAdmins Slack workspace shared the following workaround: In the JSS, hit Cancel on the following failed command: DeviceConfigured.
Posted on 08-27-2020 12:37 AM
@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
Posted on 08-28-2020 06:39 AM
Same issue for me since yesterday, working with the jamf support on it but still not soilved
Posted on 08-28-2020 12:46 PM
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?
Posted on 08-28-2020 02:11 PM
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".
Posted on 08-31-2020 12:18 AM
is it working for everyone now? What did the Jamf support say?
Posted on 08-31-2020 02:16 AM
Still not working for me, waiting for jamf support feedback
Posted on 08-31-2020 02:29 AM
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
Posted on 08-31-2020 08:01 AM
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.
Posted on 08-31-2020 08:41 AM
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.
Posted on 08-31-2020 10:09 AM
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.
Posted on 09-01-2020 01:32 AM
Still same issue for me today, waiting for JamF Support... Do you have any answer on your side ?
Posted on 09-01-2020 05:22 AM
Same problem still here. (West Europe cloud)
Process , looping while enrolling.
Posted on 09-01-2020 05:23 AM
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 !
Posted on 09-01-2020 05:24 AM
Posted on 09-01-2020 07:02 AM
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".
Posted on 09-01-2020 12:50 PM
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.
Posted on 09-04-2020 12:35 PM
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.
Posted on 09-04-2020 09:20 PM
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.
Posted on 09-07-2020 05:51 AM
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."
Posted on 09-08-2020 08:34 AM
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.
Posted on 09-08-2020 09:42 AM
Posted on 09-08-2020 09:58 AM
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".
Posted on 09-08-2020 12:57 PM
@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.
Posted on 09-08-2020 07:24 PM
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.
Posted on 09-09-2020 08:22 AM
@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.
Posted on 09-10-2020 08:06 AM
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... :/
Posted on 09-11-2020 06:52 AM
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.
Princeton Public Schools
Posted on 09-11-2020 08:31 AM
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.
Posted on 09-23-2020 01:18 PM
Can confirm that this is still an issue, amongst other errors like "Couldn't communicate with a helper application."
Posted on 01-24-2022 11:28 PM
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...
Posted on 12-07-2020 03:01 AM
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
Posted on 01-24-2022 11:22 PM
im assuming these are cloud instances so the option to restart tomcat would not be available