Enhancement: configuration profiles

[ecanault]

Well... I'm surely doing it bad, but I didn't manage to find a satisfying way to handle them.

• Why some PayloadXxx keys are required in .mobileconfig or plist?

For example PayloadScope must be defined AND its value must be the same than the level key !?

Is it possible to simplify this and for example

1. to allow the use of basic .mobileconfig files and
2. not to have to handle the things twice between PayloadsXxx entries in the file and keys in the plugin?

• I figured out that redeploy_on_update should only apply if a configuration profile is modified?

In my test, it seems that the configuration will be redeployed even if there's no change in the plan.

• Self Service options missing?

The button name is not customizable.

And Is it possible also to add the icon support (and for policies too 😉)

[ShocOne]

not in the short to medium term. the way we need to handle the stating of config profiles, the jamf pro key insertions and suppress the differences requires that the plist needs to be configured to a minimum level beforehand. there's discussions on having a none plist approach to config profiles within the provider @w0de was considering which would mean you write the key value pairs directly into the .hcl file. But that work hasn't been undertaken as of yet.

I'd like to understand a bit more about this point.

In my test, it seems that the configuration will be redeployed even if there's no change in the plan.

Is this a terraform plan thing, or are you observing that the mdm profile is redeployed by jamf pro ?

Self Service options missing?

• no it works. what specifically are you referring to ? the macos examples demonstrate how to use this block.

And Is it possible also to add the icon support (and for policies too 😉)

• it's unlikely. the api is rubbish for icons and barely works with scripts let alone tf. so until such time jamf fix things on their end this won't be possible.

[ecanault]

Hi,

For this point:

In my test, it seems that the configuration will be redeployed even if there's no change in the plan.

Is this a terraform plan thing, or are you observing that the mdm profile is redeployed by jamf pro ?

The profile is redeployed by Jamf Pro.

Here is the .tf file:

resource "jamfpro_macos_configuration_profile_plist" "jamfpro_macos_configuration_profile_001" {
  name                = "tf-localtest-contentcaching-plist-source:jamfpro-1"
  description         = "An example mobile device configuration profile."
  level               = "System"
  distribution_method = "Install Automatically" // "Make Available in Self Service", "Install Automatically"
  payloads            = file("./cp_disable_softwareupdate.mobileconfig")
  user_removable      = false
  redeploy_on_update  = "All"

  site {
    id = -1
  }

  scope {
    all_computers = true
    all_jss_users = false

  }
}

Each apply look like this without any changes:

  # jamfpro_macos_configuration_profile_plist.jamfpro_macos_configuration_profile_001 will be updated in-place
  ~ resource "jamfpro_macos_configuration_profile_plist" "jamfpro_macos_configuration_profile_001" {
        id                  = "272"
        name                = "tf-localtest-contentcaching-plist-source:jamfpro-1"
      ~ redeploy_on_update  = "Newly Assigned" -> "All"
        # (6 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

And I can see in Jamf Pro that:

• The profile has been edited:

• And it has been redeployed; and I can confirm that it's the case on Mac itself:

[ecanault]

For this point:

Self Service options missing?

no it works. what specifically are you referring to ? the macos examples demonstrate how to use this block.

Sorry, I wanted to talk about the Self Service Display Name; I think it is missing:

[ecanault]

And finally for this point:

And Is it possible also to add the icon support (and for policies too 😉)

it's unlikely. the api is rubbish for icons and barely works with scripts let alone tf. so until such time jamf fix things on their end this won't be possible.

I agree that it's not a "must have" feature if Jamf API are buggy!

But I had good result using this endpoint https://developer.jamf.com/jamf-pro/reference/post_v1-icon and this one https://developer.jamf.com/jamf-pro/reference/get_v1-icon-id.

After using the first one for uploading an icon, you can normally retrieve the ID of the icon, and then use this ID in the <self_service_icon> key for creating/updating policies ans profiles.

[ShocOne]

Hi,

For this point:

In my test, it seems that the configuration will be redeployed even if there's no change in the plan.

Is this a terraform plan thing, or are you observing that the mdm profile is redeployed by jamf pro ?

The profile is redeployed by Jamf Pro.

Here is the .tf file:

resource "jamfpro_macos_configuration_profile_plist" "jamfpro_macos_configuration_profile_001" {
  name                = "tf-localtest-contentcaching-plist-source:jamfpro-1"
  description         = "An example mobile device configuration profile."
  level               = "System"
  distribution_method = "Install Automatically" // "Make Available in Self Service", "Install Automatically"
  payloads            = file("./cp_disable_softwareupdate.mobileconfig")
  user_removable      = false
  redeploy_on_update  = "All"

  site {
    id = -1
  }

  scope {
    all_computers = true
    all_jss_users = false

  }
}

Each apply look like this without any changes:

  # jamfpro_macos_configuration_profile_plist.jamfpro_macos_configuration_profile_001 will be updated in-place
  ~ resource "jamfpro_macos_configuration_profile_plist" "jamfpro_macos_configuration_profile_001" {
        id                  = "272"
        name                = "tf-localtest-contentcaching-plist-source:jamfpro-1"
      ~ redeploy_on_update  = "Newly Assigned" -> "All"
        # (6 unchanged attributes hidden)

        # (2 unchanged blocks hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

And I can see in Jamf Pro that:

• The profile has been edited:

• And it has been redeployed; and I can confirm that it's the case on Mac itself:

This suggests that the reploy_on field is the root of the issue. Any change in the tf plan triggers a uuid change on the jamf side and this in turn triggers a redeployment of the config profile. I'll take a look at this once i have worked through the backlog for 11.5 package updates in the sdk

[ShocOne]

As of my testing with jamf pro 11.7, the behaviour for field "redeploy_on_update" , is now always to set to Newly Assigned . We have therefore taken the decision to make this field computed going forward and it will no longer be configurable within the HCL.