DEP Sync failed

a_simmons
Contributor II

39d356eb1db54b079c864c747a11d6fb
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?

15 REPLIES 15

iPad_Sheriff
New Contributor III

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
Contributor

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
Contributor III

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
New Contributor II

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

JenT
New Contributor III

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
Contributor

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
Contributor

@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
New Contributor II

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
New Contributor III

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
New Contributor II

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

dstranathan
Valued Contributor II

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
Esteemed Contributor II

@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
Valued Contributor II

@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
Esteemed Contributor II

@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
Valued Contributor II

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