Splitting Configuration Profiles

fossett
New Contributor

My org has one mobile device configuration profile that I'd like to split up so each payload has it's own configuration profile. I just wanted to know what the best way to go about this would be? Here's my initial thought process:

1) Create the individual configuration profiles - un-scoped.
2) Scope one of the new profiles
3) Immediately remove that same payload from the "master" config profile
4) Repeat until done.

Is this the right way to go about it? Would it be best to scope the individual profiles first and then remove the "master" config profile all at once?

Thank you, just got my 200 so ready to help organize everything at work! 💪

3 REPLIES 3

sshort
Valued Contributor

I would scope to a test device at first, but in general you can just push out all the new profiles first, then when you know the new profiles are successfully installed you can remove the old/original profile. Duplicate payloads can exist without issue, however the most restrictive setting will win out if you happened to change some of the payload settings between your single original and the new multiple batch of profiles you're making.

Example: If Profile A disallows Touch ID and Profile B disallows Touch ID, then nothing changes if both are installed. But if Profile A disallows Touch ID, and Profile B allows it, then the restriction to disallow Touch ID would remain as long as Profile A is still installed.

fossett
New Contributor

@sshort Just the info I needed. I'll get to testing. Thank you!

mschroder
Valued Contributor

What I did recently was

  • clone the original Configuration Profile
  • in the copy remove the unwanted parts
  • when saving select 'apply to newly scoped devices only' (or similar phrase, I don't recall the details), that way this has no impact on the devices that have the original payload already applied
  • remove the contents from the original Configuration Profile, again apply to newly scoped only
  • Repeat until done

For cases like this it is very helpful to have a test-mdm available. Porting from test-mdm to prod-mdm is a pain in the lower back, but some tests I prefer to do on a separate instance.