How do I get rid of this message for good ? Even after I 'cancel all' the next day there are a bunch of them again.
Is it trying to install a configuration profile that has been deleted from my configuration profile payload?
What's actually causing this?
Best answer by AJPinto
Recently, i had to clean up this issue; i've seen it occur; under the following conditions;
a configuration profile is scoped; and active on devices; an employee; deletes the config profile; while it is still scoped to devices; this can lead to this sort of looping error that can even slow down jamf pro, if the number of orphaned APNs, becomes excessive.
The fix is sort of nasty but does work; if oyu create a new config profile, and manually edit the generated URL; to match the ID of the deleted (orphaned profile, and go to the edited URL; your deleted profile will reappear. Save the profile and scope it to nothing;
During the next checkin process, JAMF Pro will clear out the profile and the orphaned commands.
If you can't recall the id= var of the deleted profiles; jamf support can assist after you delete the config profiles.
To avoid this in the future, I usually rename config profiles, i no longer want with del-xxxx and just set the scope to nothing.
Hope that helps,
M
Agreed. It's usually a best practice to unscope and "archive" configuration profiles for a few weeks/months before deleting them. Stops issues like this and saves them for future reference if needed.
+11Recently, i had to clean up this issue; i've seen it occur; under the following conditions;
a configuration profile is scoped; and active on devices; an employee; deletes the config profile; while it is still scoped to devices; this can lead to this sort of looping error that can even slow down jamf pro, if the number of orphaned APNs, becomes excessive.
The fix is sort of nasty but does work; if oyu create a new config profile, and manually edit the generated URL; to match the ID of the deleted (orphaned profile, and go to the edited URL; your deleted profile will reappear. Save the profile and scope it to nothing;
During the next checkin process, JAMF Pro will clear out the profile and the orphaned commands.
If you can't recall the id= var of the deleted profiles; jamf support can assist after you delete the config profiles.
To avoid this in the future, I usually rename config profiles, i no longer want with del-xxxx and just set the scope to nothing.
Hope that helps,
M
+26Recently, i had to clean up this issue; i've seen it occur; under the following conditions;
a configuration profile is scoped; and active on devices; an employee; deletes the config profile; while it is still scoped to devices; this can lead to this sort of looping error that can even slow down jamf pro, if the number of orphaned APNs, becomes excessive.
The fix is sort of nasty but does work; if oyu create a new config profile, and manually edit the generated URL; to match the ID of the deleted (orphaned profile, and go to the edited URL; your deleted profile will reappear. Save the profile and scope it to nothing;
During the next checkin process, JAMF Pro will clear out the profile and the orphaned commands.
If you can't recall the id= var of the deleted profiles; jamf support can assist after you delete the config profiles.
To avoid this in the future, I usually rename config profiles, i no longer want with del-xxxx and just set the scope to nothing.
Hope that helps,
M
Agreed. It's usually a best practice to unscope and "archive" configuration profiles for a few weeks/months before deleting them. Stops issues like this and saves them for future reference if needed.
+17Agreed. It's usually a best practice to unscope and "archive" configuration profiles for a few weeks/months before deleting them. Stops issues like this and saves them for future reference if needed.
As @AJPinto says, create a Category: ZZZ Archive Config Profiles, while you're at it ZZZ Archive Policies.
Remove the scope and move to the ZZZ when you need to decommission.
That way you can refer back to them if needed, re-instate / clone as required.
Then when you do your 3 / 6 / 12 month JAMF clean up (we all do that yes 😉) You can the delete as required.
Recently, i had to clean up this issue; i've seen it occur; under the following conditions;
a configuration profile is scoped; and active on devices; an employee; deletes the config profile; while it is still scoped to devices; this can lead to this sort of looping error that can even slow down jamf pro, if the number of orphaned APNs, becomes excessive.
The fix is sort of nasty but does work; if oyu create a new config profile, and manually edit the generated URL; to match the ID of the deleted (orphaned profile, and go to the edited URL; your deleted profile will reappear. Save the profile and scope it to nothing;
During the next checkin process, JAMF Pro will clear out the profile and the orphaned commands.
If you can't recall the id= var of the deleted profiles; jamf support can assist after you delete the config profiles.
To avoid this in the future, I usually rename config profiles, i no longer want with del-xxxx and just set the scope to nothing.
Hope that helps,
M
I thought I un scoped before deleting the configuration profiles. Must not have.
Looks like all those PENDING COMMANDS hold up legitimate management commands such as REMOVE MDM PROFILE . Just a handful of computers that are on the chopping block.so they'll just be deleted.from inventory, and wiped.
+3Had a similar issue and reached out to support who have provided the below guidance:
if the concerned profile does not exist in GUI and is deleted, we can proceed with the workaround for this is as follows:-
Requirements:
Have a signing certificate in order to sign .mobileconfig file (ref: https://docs.jamf.com/technical-articles/Creating_a_Signing_Certificate_Using_Jamf_Pros_Built-in_CA_to_Use_for_Signing_Configuration_Profiles_and_Packages.html)
Context:
There's multiple reasons that can lead to this behaviour, but one of the most common ones is that deleting a profile will generate a remove profile command based on the profile identifier at the moment the delete command is generated, for all the computers currently having this profile installed.
If the pending command gets deleted, Jamf will detect at next inventory collection or ProfileList command that a non scoped profile is installed on the managed machine and should not. Therefore Jamf will try to send a command to remove this profile and will fail cause there's no longer a matching profile identifier among the os_x_configuration_profiles currently non deleted.
Process:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array/>
<key>PayloadDisplayName</key>
<string>IDENTIFIER</string>
<key>PayloadIdentifier</key>
<string>IDENTIFIER</string>
<key>PayloadOrganization</key>
<string>INSTITUTIONNAME</string>
<key>PayloadRemovalDisallowed</key>
<false/>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>IDENTIFIER</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>
/usr/bin/security cms -S -N "JamfSign" -i ~/Desktop/IDENTIFIER.mobileconfig -o ~/Desktop/Signed-IDENTIFIER.mobileconfig
select * from os_x_configuration_profiles where payload_uuid=IDENTIFIER\\G
+10I feel like this post should have more views. I've been fighting a FileVault payload for months with the dreaded "payload is already installed on the system" error. After following @jamf_pro_admin advice, I was finally able to start fixing my fleet that were building up failed mdm commands. Thank you!! I also will NOT delete config profiles anymore, unscoping is your friend. =)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.