Scripting the Installation of Profiles on MDM Capable Computers

Hi @mottertektura So, there's no reason you can't install Profiles manually on devices that are also MDM managed. We have several manually installed profiles on our MDM managed Macs without issue.

However, it sounds like you're trying to mix installing the same Config Profiles over both MDM and from a script, which is something I wouldn't recommend. The problem you mentioned of the JSS attempting to remove the manually installed profiles is one of the potential issues. The reason this happens, I believe, is because the profile's UUID is its unique identifier, and the UUID is going to be identical when using the method from my post you linked to, and when done over APNs. You can't install the same profile twice from two different distribution sources, so likely what's happening is, when the JSS tries to deploy that profile over MDM to scoped devices, it sees the manually installed one and needs to remove it in order to install it over the push process. If I'm not mistaken, MDM pushed profiles take precedence over manually installed ones.

Coming back around to what you're looking to solve here though, I wanted to mention that it is possible to scope profiles to Self Service policies, meaning Self Service becomes the profile distribution method, so I would explore that option first and foremost if you are looking to make them something user's can install on their own. It shouldn't need to be done with a script in a Self Service policy, at least depending on what kind of profile it is we're talking about.

Thanks for the response, @mm2270 !

I'm not installing this particular profile over MDM but I did create it and download it in the JSS to grab the xml for use in the script. However, it is still in the JSS but with No scope defined. I'm wondering since the scripted profile and the MDM profile have the same UUID, and even though the MDM Profile is technically not scoped to any devices, if this would still cause the JSS to recognize it and attempt to remove the scripted Profile?

Perhaps I could just change the last character in the string in the script to something different so it wouldn't conflict?

      <dict>
        <key>PayloadUUID</key>
        <string>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXB</string>
        <key>PayloadType</key>
        <string>com.apple.SystemConfiguration</string>
        <key>PayloadOrganization</key>
        <string>Company</string>
        <key>PayloadIdentifier</key>
        <string>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXB</string>
        <key>PayloadDisplayName</key>
        <string>Proxies</string>
        <key>PayloadDescription</key>
        <string/>
        <key>PayloadVersion</key>
        <integer>1</integer>
        <key>PayloadEnabled</key>
        <true/>
        <key>Proxies</key>

Thanks for your suggestion to deploy the Profile via Self Service. The only potential problem I see with that would be trying to get users to install it manually. I'm looking to install it silently with the option for folks to remove it temporarily to test if they are having issues with the proxy, and then install it silently again at the next recurring check-in.

Thanks again, appreciate your help!

Ah, I see now. So it's not the deployment that you're looking to do via Self Service, but the temporary removal. I understand now. I must have missed that in your post before, sorry.
So in that case, I guess scripting a removal using the profiles command would be the way to do it? If it's being installed manually from a script, then MDM should not come into play here at all. I don't see a reason why the JSS would try to remove it if it's indeed not scoped to any Macs. It should leave it alone. In fact, I have a couple of profiles I created in my JSS for experimentation purposes which are not scoped to anything, that I downloaded and installed manually and they have never been removed from my system or others by our JSS to my knowledge. So that is curious. I guess I would have to check on that closer to be sure, but I don't recall seeing that happening.
So my only question on this would be, are you certain the profile is not scoped out in any way?

@mottertektura
One other thing, in case it's of interest to you, I went a step further and had created a script that can download and install any config profile from your JSS using the API. Meaning you don't have to go through the process of pulling it down, converting it and placing the data for the profile in a script, if you planned on installing some of them via script. All you need is API credentials that can read OS X Configuration Profiles and the Profile's JSS ID and the script will take care of deploying it. It has a few extra features, one of which is, it can (optionally) rename the Profile's UUID to something human readable based on the Display Name for the profile, instead of the long random UUID string the JSS adds to them. That way, a sudo profiles -P command will show you the profile name. You otherwise need to do sudo profiles -Pv and parse the output for the readable names.
It will also attempt to install the profile in the correct space, meaning User Level or Computer Level, depending on how the profile was set up in your JSS.

I don't have the script posted anywhere yet, but if it's something you'd like to try, let me know and I can post it here or publish it on my github page perhaps.

@mm2270

So I deleted the Configuration Profile from the JSS, ran recon on the computer, and checked the Management History and found that the command now says "Remove Configuration Profile - Profile no longer exists". So I'm thinking that it must be trying to remove the scripted Profile thinking that it was the MDM Profile even though the MDM Profile was set to No scope defined and is now deleted. The Profile was scoped to the computer previously for testing, but I can confirm in the history that it was removed, so I'm not quite sure what's going on here.

I'll enter a support case to see if there might be a larger issue at play here. Also still wondering if changing the PayloadUUID and PayloadIdentifier slightly would fix this behavior as well.

Definitely would like to try the script to download and install config profiles using the API if you wouldn't mind sharing!

Thanks again!

Also still wondering if change the PayloadUUID and PayloadIdentifier slightly would fix this behavior as well.

It can't hurt to try that actually. Maybe because the script installed profile has the same UUID strings the JSS is seeing it as one of it's own, and trying to remove it, but that doesn't seem like a valid explanation of it to me. If anything, I would say the more likely cause is that because it was once scoped to the profile and now removed (is it being excluded in the Exclusion tab?), it's still trying to ensure that that Mac doesn't have that profile on it anymore.
But yeah, give changing the UUID of the profile in the script a shot and see if it resolves it for you.

I will work on getting my script posted up, probably on my github page and then link back to it here.

So the weird thing is I ran the script to install the profile on a different test computer (that had not been scoped to the test MDM profile previously) and after which the MDM profile had already been deleted and still received the same error under Failed Commands in Management history. ¯_(ツ)_/¯

But happy to report that changing the UUID strings in the install and uninstall scripts worked. I just bumped up the last number one more on the PayloadUUID and PayloadIdentifier and I'm no longer seeing the error now. = )

Thanks for sticking with me on this one. Definitely strange. In the future I'll be sure to slightly change those so I don't run into this conflict again.

Awesome, looking forward to checking out that script when you have a chance to post it. Thanks!

Ok, well, then I stand corrected! I guess maybe the JSS is seeing the same profile ID as one it manages and is thinking it needs to be removed? That's pretty strange though! I would think it should be smart enough to know if something was installed manually to leave it be, even if it's something that originated in the JSS. Seems intrusive that it would just try to remove those like that. : /

@mottertektura
Ok, got my script posted up on github. You can find the script itself here and the link to the description on the ReadMe page is here. Be sure to read the description on how it works and how to use it properly if you'd like to use it.

Let me know how it works for you or what you think.

@mm2270

Awesome, thanks! Will do!