+3Hello all,
We are working on leveraging the DDM managed-software-uodate API feature for pushing out enforceable updates to our endpoints. One of the issues we are seeing, however, is that some machines get stuck where the machine never updates but when I try to push and check a new plan, I get the error
EXISTING_PLAN_FOR_DEVICE_IN_PROGRESSMy question is, how do we go about canceling a plan that is already in progress?
Thank you,
Alex Weiner
Best answer by Chris_Cover
Thanks to those who have responded. I've seen similar threads from the past year or so, who have also received replies of "Turn the Software Update feature" but how is that the only solution at this point?
We commonly get scenarios such as: Computer 123 received a DDM Software Update command and is assigned to PlanID ABC-456. Days later, reports show that the machine hasn't updated yet and the DDM workflow looks to be hung, so we need to remediate it. All I want is a mechanism to say "Cancel PlanID ABC-456" and yet the only solution is "pull an IT Crowd on the Software Update feature for your entire Production Environment."
Not trying to be aggressive towards those that responded, just incredulous that Jamf/Apple have no better solution at this point.
I was digging into the API for other reasons and I think I noticed that if you nuke the OSUpdateStatus command in the pending queue it may nuke the plan for that device.
+20We go to the Software Updates tab and turn off the feature. Wait a bit. Then cycle it back on. Send DDM again.
+3Thanks to those who have responded. I've seen similar threads from the past year or so, who have also received replies of "Turn the Software Update feature" but how is that the only solution at this point?
We commonly get scenarios such as: Computer 123 received a DDM Software Update command and is assigned to PlanID ABC-456. Days later, reports show that the machine hasn't updated yet and the DDM workflow looks to be hung, so we need to remediate it. All I want is a mechanism to say "Cancel PlanID ABC-456" and yet the only solution is "pull an IT Crowd on the Software Update feature for your entire Production Environment."
Not trying to be aggressive towards those that responded, just incredulous that Jamf/Apple have no better solution at this point.
Thanks to those who have responded. I've seen similar threads from the past year or so, who have also received replies of "Turn the Software Update feature" but how is that the only solution at this point?
We commonly get scenarios such as: Computer 123 received a DDM Software Update command and is assigned to PlanID ABC-456. Days later, reports show that the machine hasn't updated yet and the DDM workflow looks to be hung, so we need to remediate it. All I want is a mechanism to say "Cancel PlanID ABC-456" and yet the only solution is "pull an IT Crowd on the Software Update feature for your entire Production Environment."
Not trying to be aggressive towards those that responded, just incredulous that Jamf/Apple have no better solution at this point.
I was digging into the API for other reasons and I think I noticed that if you nuke the OSUpdateStatus command in the pending queue it may nuke the plan for that device.
+3I was digging into the API for other reasons and I think I noticed that if you nuke the OSUpdateStatus command in the pending queue it may nuke the plan for that device.
@Chris_Cover thanks for the input. What API domain were you seeing that in?
+3I was digging into the API for other reasons and I think I noticed that if you nuke the OSUpdateStatus command in the pending queue it may nuke the plan for that device.
I just tested it out and can confirm that, after manually deleting the pending OSUpdateStatus command, the Management > Operating System menu no longer showed the Plan info and I was able to send a new DDM command which registered a new PlanID that was not canceled due to an existing plan.
This should be good enough for now to nuke pending commands before pushing out new updates. Thanks Much!
I just tested it out and can confirm that, after manually deleting the pending OSUpdateStatus command, the Management > Operating System menu no longer showed the Plan info and I was able to send a new DDM command which registered a new PlanID that was not canceled due to an existing plan.
This should be good enough for now to nuke pending commands before pushing out new updates. Thanks Much!
Hey, glad that worked out for you. I've had to modify my script to account for the plan toggle, and then to not get repeated plans. It would be nice if they would allow the API to get the plan ID for a device. I've ended up writing it to a PLIST at time of the plan creation so I can check the process.
honestly I think the old means of doing updates was better..at least for those using the API. I can see some issues that the new way "solves".
+1I just tested it out and can confirm that, after manually deleting the pending OSUpdateStatus command, the Management > Operating System menu no longer showed the Plan info and I was able to send a new DDM command which registered a new PlanID that was not canceled due to an existing plan.
This should be good enough for now to nuke pending commands before pushing out new updates. Thanks Much!
I haven't worked with the API much. Would you be able to provide a little more detailed explanation for how exactly you did this?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
