I recently had my Jamf instance moved to a new server. Then I noticed I started having problems with my DEP syncing in Jamf. Devices that were added to the DEP pre-move would setup correctly but new devices added after the move wouldn't start the DEP process. When I go to the Settings/Global Management/Device Enrollment Program my account has a red triangle next to it. In the settings of my DEP account there's an error that says 'Sync failed. Awaiting next sync'. When I open Apple School Manager and download the token, I receive the following error when I try to import the server token file into Jamf 'The file received was not valid'. Has anyone come across this error before?
Same here. JSS alerted me to the fact that my server token file is expiring. I downloaded a new server token file from Apple, and I received the same error when I tried to upload the new token file in JSS.
EDIT: I had to replace the public key for our MDM server on school.apple.com, but now JAMF won't upload the server token file and throws an error about "Unable to contact https://mdmenrollment.apple.com to get the list of devices".
EDIT 2: It took a few tries and a Tomcat reboot. We're back in business.
Having similar issue since the upgrade. Every server on my DEP screen has a red triangle next to it reading "Sync failed. Awaiting next sync".
Occasionally they will go away, but after a while they come right back.
I was having the same issues as everyone else. Rebooted Tomcat, the public key, and server token, and still nothing.
I spoke with Jamf Support and they suggested signing in as a different admin under Apple School Manager to reload the key and server token, and it FINALLY worked.
Both ASM accounts have the same access/privileges (site manager), so they SHOULD have both worked just fine. Who knows!
In case anyone else encounters this, I'll my observation and self-mitigation...
Per earlier comments, I confirmed ntp/time was correct and checked firewall, but that hasn't changed in months/years (we maintain our private AWS VPC, including security groups), but I noticed this in JSS with debug logging enabled...
2019-07-30 14:14:52,938 [DEBUG] [duledPool-2] [ccountDetailsSynchronizer] - Could not update Account Details for MySuperSpecial-DEP-Instance-Name com.jamfsoftware.jss.objects.streamlinedenrollment.service.DeviceEnrollmentProgramException: PROBLEM_CONTACTING_APPLE_SERVICES at com.jamfsoftware.jss.objects.streamlinedenrollment.DeviceEnrollmentAccountDetailsConnectionService.getAccountDetails(DeviceEnrollmentAccountDetailsConnectionService.java:60) at com.jamfsoftware.jss.objects.streamlinedenrollment.instance.sync.DeviceEnrollmentAccountDetailsSynchronizer.run(DeviceEnrollmentAccountDetailsSynchronizer.java:36) at com.jamfsoftware.jss.objects.streamlinedenrollment.synchro.DeviceEnrollmentSyncRunnable$DeviceEnrollmentSyncThread.run(DeviceEnrollmentSyncRunnable.java:75) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: com.jamfsoftware.jss.objects.streamlinedenrollment.service.DeviceEnrollmentProgramException: An error occurred during oauth token refresh at com.jamfsoftware.jss.objects.streamlinedenrollment.service.comm.OAuthConnection.getSessionToken(OAuthConnection.java:43) at com.jamfsoftware.jss.objects.streamlinedenrollment.service.comm.OAuthorizer.obtainFreshSessionToken(OAuthorizer.java:54) at com.jamfsoftware.jss.objects.streamlinedenrollment.service.comm.OAuthorizer.getSessionToken(OAuthorizer.java:33) at com.jamfsoftware.jss.objects.streamlinedenrollment.service.comm.DeviceEnrollmentProgramRequest.sendOneTime(DeviceEnrollmentProgramRequest.java:52) at com.jamfsoftware.jss.objects.streamlinedenrollment.service.comm.DeviceEnrollmentProgramRequest.send(DeviceEnrollmentProgramRequest.java:44) at com.jamfsoftware.jss.objects.streamlinedenrollment.service.comm.DeviceEnrollmentProgramConnection.sendRequest(DeviceEnrollmentProgramConnection.java:32) at com.jamfsoftware.jss.objects.streamlinedenrollment.DeviceEnrollmentAccountDetailsConnectionService.getAccountDetails(DeviceEnrollmentAccountDetailsConnectionService.java:58) ... 9 more
Maybe that helps Jamf support identify and resolve the issue, but I thought I try something first...
To test general DEP-access, I thought I'd create a new DEP instance in webapp, using the newly-acquired DEP token (from ABM).
Bingo! It was able to upload the token and complete the setup. Computer PreStage Enrollments we associated to the old/revoked instance, but I was easily able to rectify that by changing the "DEVICE ENROLLMENT PROGRAM INSTANCE" to the DEP instance in my PreStage Enrollment, all my assignments showed all previously assigned computers.
Now, I can file a case w/ Jamf to get to the underlying issue, while still having a simply work-around.
FYI: running Jamf Pro v10.13.0-t1559772983 on Ubuntu 18.04.2 LTS and openjdk version "1.8.0_212" (in case that's relevant)
Hope this helps others.
@dstranathan Are you talking about the time displayed in the Last Sync column of Computers->PreStage Enrollments? As near as I can tell that time is when anything was changed in the Options settings for the enrollment. Changes to the Scope, be it adding or removing devices, doesn't trigger a sync for me.
@sdagley Yes, that's what I'm referring to (I should have posted a screenshot). I have been "tickling" the Last Sync timestamp by making a simple text change in the PreStage and saving it to see if the timestamp changes (it doesn't).
I usually don't make many changes to my PreStages, but it just so happens that I am currently making a lot of changes to a prototype PreStage (I'm going to quit relying on fragile 'Enrollment Complete' triggers in with a kickstart LaunchDaemon via a signed PreStage package). Lots of testing and tweaking right now...
I'm going to renew the token and restart Tomcat one more time before opening a support case.
@dstranathan Are you seeing that changes in your PreStage aren't being picked up when a Mac enrolls? I've also been making a lot of PreStage changes lately (breaking out Catalina and Big Sur versions, plus separating x86 and ARM architectures for Big Sur), and as long as the Last Sync Time for my Automated Device Enrollment shows a recent sync I haven't had any issues with PreStage changes not being picked up despite the old sync dates they're showing.
For your Enrollment Complete triggers, are you running multiple policies? I use DEPNotify, and customized version of Jamf's DEPNotify-Starter script to drive it that is triggered by a single Enrollment Complete policy and it's been working reliably for a couple of years.