Failed management commands generated during DEP enrollment (on machines that already exist in jss) PI-005972

Seeing the exact same. Jamf Cloud 10.4, 10.5 and still present in 10.6

only one who has reported this PI lolwut. I've raised this issue multiple times. At one point they suggested we clear the existing record on every re-enrollment and maintain a shadow database for historical data.

@Kaltsas @rypowell88 can you please make sure if you have tickets in they are tied to the PI-005972? thank you.

I reported this back in April and was referred to PI-005744. I just sent off a note asking for an update and referenced this post.

@CasperSally any updates on this PI? we are experiencing this with our existing device rebuilds. I sent your PI number over support.

@hstanley @ginakung I haven't heard anything. I know they plan to improve config profile deployment, but no idea if it will help this issue. I'm still manually canceling commands via sql (bleh). I just asked for clarification on the difference between PI-005972 and PI-005744.

@CasperSally how often are you canceling commands via sql? is that something that can be automated? thank you for sharing your knowledge!

@ginakung - i cancel failed commands at least once a week. During our busy period where we reprovision thousands of machines over a few weeks, I was doing it daily. It stinks.

from jamf below. I have asked again if 5972 can be broadened because this race condition is happening regardless if profile is scoped to smart group based on computer name or not. It happens on profiles I have scoped to "all 10.13 machines."

PI-005744 speaks to a situation when the re-enrollment of a computer without deleting that computer record from Jamf Pro inventory will result in Configuration Profiles we expect to be deployed to a device to not actually be deployed until an inventory update occurs. What we usually end up seeing is that MDM commands are pushed earlier and faster than binary commands (like an inventory update). PI-005972 speaks to a situation when a computer is wiped and re-enrolled via DEP (again without deleting the computer from Jamf Pro inventory), and the name of the computer is changed, which can change whether the device is in scope of a Configuration Profile, especially if those Configuration Profiles are scoped to smart groups that may involve the name of the device in some way. The wipe/re-enroll/name change would remove the device from the scope of previously-scoped configuration profiles, which triggers Jamf Pro to send Profile Removal commands to the device. But because the device is no longer in scope because the name changed, Failed Commands are shown in management history. These failed commands will prevent new commands from being deployed to the device until they're cleared.

Agreed, this should be getting fixed, sooner than later. Seems silly to have to manually work around something that Jamf should be fixing.

K12 here as well, also getting this "PI-005972" 'bug'. Really annoying since we have tons of these errors every day. I really hope the next release will fix that even though I doubt it.

"Jamf has said I'm the only one who has reported this PI and it's unlikely to get traction" So JAMF doesn't have any intention of fixing bugs, only those which affect N number of people???? I can't wait for a comprehensive challenger to come on the market.

It's almost easier to just delete the devices and re-enroll them in mass. Clearing those commands is a burden I'll quickly pass on.