Remove Configuration Profile - Profile no longer exists

[tcandela]

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?

 

[mschlosser]

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

[AJPinto · Accepted solution]

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.

[jamf-42]

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.

[tcandela]

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.

[jamf_pro_admin]

Had 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_...) 



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:

• Copy-paste the profile identifier (format XXXXXXXX-XXXX-XXXX-XXXXXXXXXXXX) from the error command or from the inventory display > profiles report on the inventory of the affected machine. This will be referred as IDENTIFIER in the next steps
• Open terminal and type sudo nano ~/Desktop/IDENTIFIER.mobileconfig
• Paste the below:

<?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>​

• Replace IDENTIFIER with the identifier gathered earlier

• Replace if wanted INSTITUTIONNAME with the name of the institution (e.g CompanyName)
• Press ctrl +X to quit and "y" to save the file
- sign the ~/Desktop/IDENTIFIER.mobileconfig file with the below command: 

/usr/bin/security cms -S -N "JamfSign" -i ~/Desktop/IDENTIFIER.mobileconfig -o ~/Desktop/Signed-IDENTIFIER.mobileconfig

• Replace "JamfSign with the CN of the certificate of the article referenced in the requirements section
• Upload the .mobile config in the affected Jamf Pro instance and DO NOT remove the signature when offered after upload
• Leave the scope empty and save the configuration profile
• Leave the machines to submit inventory or execute a ProfileList command 
The failed command to remove profile should stop. Once all affected machines are no longer looping the failed commands, the profile can be deleted.
• Note: If running into an error stating “Unable to create object from file”, the UUID already exists in Jamf Pro database. 
See PI-005893 for more informations on how to handle this specific situation. 
Commands like the below can help identify what profile already has this identifier in the Jamf Pro database:

select * from os_x_configuration_profiles where payload_uuid=IDENTIFIER\G

[mgshepherd]

I 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. =)