Configuration Profile Updates Cause Duplicates on Devices

[smithjw]

It seems there's an issue again that causes duplicate profiles to be pushed to devices when an update is made to one of the keys within the profile. I'm not sure why but the provider is picking up a change with the UUID + Identifier of the profile, pushing the changed profile up to Jamf, then a second version is being deployed to a device.

With this duplicate profile on a device, there are now conflicting keys which interfere with desired behaviour.

[smithjw]

Performed a few more tests and found that on initial creation of the profile via Terraform, the apply is succeeding, but the uploaded profile in Jamf has a completely different PayloadUUID than what was in the local mobileconfig file.

When I ran a plan step following the upload, the provider returns No changes. Your infrastructure matches the configuration. (which I'm assuming is expected because of your validation rules). At this point, if I do an api call to the Jamf server to look at the profile, I can see that the UUID/Identifier is different to the local profile.

What seems to happen after this point is that after any changes are made to the resource via TF, the provider then picks up the new keys, but also that the PayloadIdentifier and PayloadUUID differ, and sets them to what is in the local mobileconfig file.

After this point, the PayloadIdentifier and PayloadUUID will not change on the Jamf side of things and remain what is set in the profile locally. I've also tested making changes to the profile via the Jamf UI and the Identifier/UUID also remain the same.

Unsure if this is something to do with the initial upload of the profile, or more likely, some weird Jamf behaviour where it will set its own identifier on initial creation of the profile when it's a brand new resource.

[smithjw]

https://grahamrpugh.com/2020/04/27/managing-profiles-between-multiple-jamf-instances.html

FFS. Seems this is expected behaviour of the Jamf API

[smithjw]

Knowing that Jamf will overwrite UUID/Identifier on the initial Post, could there be any way in the provider to do the following only on creation of a new profile:

• use post method to deploy profile but dropping any scopes
• wait for api to confirm the profile has been created
• immediately perform a put to update the profile (including scopes) which will overwrite the UUID/Identifier to what's in the profile resource.

[ecanault]

Knowing that Jamf will overwrite UUID/Identifier on the initial Post, could there be any way in the provider to do the following only on creation of a new profile:

• use post method to deploy profile but dropping any scopes
• wait for api to confirm the profile has been created
• immediately perform a put to update the profile (including scopes) which will overwrite the UUID/Identifier to what's in the profile resource.

Hi @smithjw

Perhaps I don't understand correctly your approach, but unscoping / rescoping the profile will uninstall and reinstall it on computers.

IMHO this is not good if you consider the following examples:

• For restrictions: the result will impact the user experience as the Dock and the desktop background will disapear / reappear.
• For WiFi configuration: the Mac will loose network access if it's connected to the WiFi configured in the profile, and (without Ethernet or another available WiFi) it won't be able to reinstall the profile.

Regards,
Emmanuel

[ShocOne]

Please see release v0.9.1, the fix in this release will now during config profile updates gets existing payloadUUID's for created plist resources from jamf pro. These are then injected into update requests. Diff suppression remains unchanged.

From my testing, updates now preserve the jamfpro generated payloadUUID's within the config profile server side.

Please test and let me know how you get on.