PPPC Profiles - How do YOU scope them?

@Cayde-6 I'm just scoping all PPPC profiles to Macs with Mojave (don't scope to pre-Mojave machines as they won't apply after the upgrade unless you remove and re-install the profile). While you could use a Smart Group for systems that don't have the software as an exclusion for the profile, there'd be some lag between an inventory being collected after the software is installed and your PPPC profile deploying.

@sdagley

Yep my thoughts exactly

@sdagley is right on.

@Cayde-6 I scope to the presence of the Jamf-supplied PPPC profile that gets pushed upon the user's first login post-Mojave upgrade.

I like that method @sshort. I hadn't thought of that, but that actually makes sense from a global scoping perspective since only Mojave systems and higher would have that Jamf PPPC profile installed.

I have been using an exclusion Smart Group for PPPC profiles. Essentially anything with an OS lower than 10.14.0 gets excluded. Like mentioned above by @sdagley, don't scope these to systems that can't use the profile or you may run into some issues later when they are upgraded.

I'm interested in how people push out PPPC profiles as we have around 16 profiles scoped to every machine (we only have Mojave) and they seem to interfere with profiles pushed out when enrolling a mac using DEP.

For example the machines should get the JAMF connect profiles to allow the log in screen to change and run correctly but when i have all the PPPC profiles turned on the JAMF connect profiles don't seem to run or take effect.

I'm wondering if anyone has tried installing the profiles along with the App. So for example when a user installs something from self service the PPPC profile is in that package and installs before the app installs?

Just want to take the scope off all machines and save having loads of profiles on machines that aren't actually using them.

@perryd AFAIK you can’t install PPPC Profiles in a package and have them actually work. They need to be installed from an MDM. Apple designed it that way because of the nature of what they enable, like access to personal data on the Mac. That way if a piece of software happened to have a PPPC profile embedded in a .pkg and installed it surreptitiously like what you mentioned, it can’t “grant” itself access to your personal information. In short, if you manually install them I’m pretty sure they won’t take effect, so I doubt anyone is doing what you describe.

I know that doesn’t really answer your question about how people are installing or scoping them, but I wanted to point that out to you to save you the trouble of experimenting.

@perryd As @mm2270 says, for PPPC Profiles to work you must install them via an MDM, and the MDM Profile must be user approved if one is not using DEP/ADE. Can you elaborate on "they seem to interfere with profiles pushed out when enrolling a mac using DEP"? The only problem I'd expect there is if you have a Profile as part of your PreStage Enrollment that doesn't end up being scoped to the machine after enrollment completes which will result in that Profile being removed.

@mm2270 @sdagley Thanks for the replies it kinda clears up what I thought.

When I say it "interferes" it seems to me that if there are a lot of profiles being installed at enrolment it seems to slow down or delay when they take effect. So for instance the JAMF connect profiles to licence, add settings and apply to login screen don't take effect in time when I have all the PPPC profiles turned on and a few others. I just wanted to see if theres a way to lighten this load of profiles being installed at the same time.

@perryd Do you have all of your PPPC profiles enabled as part of your PreStage Enrollment? You might want to change that if so. We don't use Jamf Connect in our environment, but the only PPPC profiles I have in my PreStage Enrollment are for things that I know need to be enabled during the enrollment process like approvals for the kernel extensions installed and scripts run during initial configuration. PPPC profiles for things like Office, Adobe, and the other tools users commonly interact with that need approvals are left for later automatic deployment.

As others have said, I just scope to anything running Mojave or greater at the moment, seems to work ok.

Getting around to testing Catalina now, and I was wondering how people are dealing with PPPC profiles for 1 product that might include settings for both Mojave and Catalina. For example, if you have a PPPC profile for an Office app in Mojave allowing it to pass information to another app, do you then add the new PPPC Catalina settings (ie SystemPolicyAllFiles) to that same profile or create a new profile? Can a profile with Catalina PPPC settings be installed on a Mojave machine, and when it is upgraded to Catalina, the settings take affect? I am currently just beginning testing, so this may be more of an academic question than an actual practical question. Thank you for any insight you may have regarding this.

@JoshRouthier

I ended up scoping Mojave & Catalina separately after my initial testing some months ago. I have a Catalina Only Smart Computer Group & a Mojave Only Smart Computer Group. 2 Sets of Categories & Configuration Profiles (Most are identical) but nonetheless scoped separately.

When the computers upgrade from mojave to catalina the configuration profiles are automatically removed & re-applied.