DEP Sync failed

[a_simmons]

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?

[iPad_Sheriff]

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.

[snovak]

Same thing here, running 10.9.0.

Re-uploaded the public key to the MDM entry on school.apple.com, re-downloaded the token and it uploaded correctly. I did restart tomcat prior to re-uploading the public key, so I'm not sure if that was needed to fix the issue.

[swapple]

I t used to be when apple updated the T&Cs, you would have to log in to DEP and accept them before DEP would sync. Does that still happen??

[jkolman]

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.

[JenT]

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!

[seabash]

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.

[killer23d]

@JenT

I confirm similar behavior. We run JAMF 10.12 and to resolve this problem, I have to go to ASM and upload the public key again and download the token. Once this is done then JAMF will accept the new token.

[oit-jamf]

In my case just like @swhps mentions, I logged in to business.apple.com and after agreeing to the new terms and conditions for iOS, macOS, and tvOS, the DEP instances synced.

[Klenke_daniel]

I know this is an older thread but wanted to let people know I solved this issue, recently, by using a different browser to download the token from ASM and upload it to Jamf using Chrome. I usually use Firefox and it would always fail.

[stphnlee]

I was having this problem and tried restarting Tomcat, but it didn't work until I uploaded our public key into ABM again.

[dstranathan]

Is anyone else still having issues with DEP/Apple Business Manager staying in sync with Jamf PreStage Enrollments?

My only "fix" is to renew the token and then it syncs again for a hort time, but after a day or so it syncing stops...again.

[sdagley]

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

[dstranathan]

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

[sdagley]

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

[dstranathan]

@sdagley I'm basically doing the same things you are (preparing for Big Sur changes while maintaining Catalina, etc).

Ill be performing more PreStage testing soon and Ill follow up.