Re-Imaging with DEP causing device signature error until record is deleted first in the JSS

I believe this is related to LDAP, because I found if we remove the user data from the computer record, DEP re-enrolls just fine. The computer record did not have to be deleted.

@gshackney Which version of JSS does this issue occur? And is the signature error listed once or twice first few lines of the device's jamf.log?

@jhalvorson We are on 10.15.1 currently. Its only listed once, unless I try to call a policy manually. Basically won't enroll or trigger any policies after I wipe the unit and install 10.14.6. I run through the setup and it does create a management account per the pre stage enrollment, but once I log into that account it will not enroll or trigger enrollment complete to start my DEP notify script.

Again wiping the inventory record for that device out of the JSS fixes the issue, but of course this is not ideal.

Gabe Shackney
Princeton Public Schools

Are you still having this issue? I've seen it, but only occasionally and we regularly reprovision machines through DEP.

@ndelgrande2 Do you have it set to wipe user and location information at re-enrollment only or do you have it also wipe the user and location history?

Gabe Shackney
Princeton Public Schools

Since I'm going through all my old threads on the community for JAMF, I figured Id let you know this I think was a PI that got resolved in one of the updates since then.

Hi Gabe,

don’t suppose you ever got to the bottom of this?

I’ve been testing DEP ahead of summer lab imaging and every other time I erase the disk and reinstall MacOS I get a device signature error.

No response from JAMF support yet.

I recently tested staff DEP using the Monterey Erase and install and it bounced through no problem, but on student image with rooms and departments, it errors.

UIE on every device seems a bit ridiculous if you ask me.

I checked my re-enroll page and it’s configured the same as yours.

Saw in an older post to check extension attributes aren’t erroring. I was thinking I’d disable them all and reimage just to see if it has an affect.

How are you doing the erase and install? just the new wipe command from the management tab of the JSS? or from the user doing wipe in system preferences?  On Intel Machines We are seeing an issue with these commands conflicting with the firmware password (but thats not causing any device signature errors that I've seen).  Since the wipe command isnt updating actually updating the machine, just keeping it at the same system, we are running the erase/install script to perform erase and upgrades all in one for anything less than 12.3.  But so far in all of our testing I haven't seen device signature errors on any.  

Do you have a lot of packages installing during the enrollment?

For Intel devices I've been doing the tried and tested CMD + OPTION + R, for devices. We don't have many T2 chipped devices that allow the 'Erase Contents and Settings' options in our student environment (for now...).

After reading your message Gabe, I tried the 'Wipe' command from JAMFcloud. It wiped the device wonderfully... except it returned my test device back to it's earliest MacOS... so had to wipe it again. Cool to know it works, at least for devices going to the scrap heap!

I'm not sure if I've totally fixed the problem but the issue hasn't occurred the past 3 DEP enrollment repetitions. We use NoMAD-Login-AD (NoLOAD) in our lab environment. It appears our JAMF technician configured NoLOAD to go onto machines as a pre-stage PKG, not an enrolment one. I've removed this PKG and set it up as regular Enrollment policy. Having done that - it's at least reduced the occurrences of Device Signature Errors.

Even if we're down to 25% occurrences, then that's far better then it was previously! Was costing me a lot of time and I have some 350 devices to wipe annually :D

Naturally our End User team don't like the idea of leaving a device without a management account so really wanted to get this fixed. Hopefully we're finally there - will find out in a few months :)

Best

Just to clarify, I spoke to JAMFsupport - they said it's absolutely not related to the management account having a random password (that configuration was looking at me like "I'm the answer to your problems...).

@Qwheel I believe this only wipes with the same system after its up to MacOS 12.  At least that is what is working for us currently.