Need help - Understanding PPPC Script and Application Approvals

New Contributor III

I need a little bit help understanding what I'm missing in what I believe are 2 different scenarios in relation to Mojave and PPPC. I provide 4 examples below...2 are what I believe are script approvals...that I need to figure out how to create and 2 are application approvals that I am somehow missing a step somewhere.

First up...setting the desktop image...

I use a DMG and upload images to replace existing ones...then I run this script:

currentUser=$(/bin/ls -l /dev/console | /usr/bin/awk '{print $3}')
macOSVersion=$("/usr/bin/sw_vers" -productVersion | "/usr/bin/awk" -F. '{print $2}')

if [[ $macOSVersion -eq 13 ]]; then
sudo -u "$currentUser" -H osascript -e 'tell application "Finder" to set desktop picture to POSIX file "/Library/Desktop Pictures/High Sierra.jpg"'

if [[ $macOSVersion -eq 14 ]]; then
sudo -u "$currentUser" -H osascript -e 'tell application "Finder" to set desktop picture to POSIX file "/Library/Desktop Pictures/Mojave Day.jpg"'

I get this popup that I'm trying to figure out how to get rid of...

Second...installing Cisco AnyConnect...

I made a package that installs properly, and have this Approved KEXT Extension as a configuration policy:

I still get this System Extension Blocked popup:

I did verify looking at the kext_policy entries in /var/db/System/Policy/Configuration/KextPolicy database that the Team ID was correct.

Third...installing HP drivers...

Here's the KEXT approval configuration policy I have:

Here's the same message I get for Cisco:

As I did for Cisco, I verified both the Team and Bundle ID's and they are really not sure what I did wrong or am missing.

Fourth...I run a script to log the user out to


currentUser=$(stat -f "%Su" /dev/console)
su $currentUser -c "osascript -e 'tell application "System Events" to log out'"


If someone has done a previous step by step on what needs to be done for getting scripts approved in PPPC and I missed it, by all means, I'll take a link. I think the HP/Cisco issues are probably super trivial...just can't see what I did wrong. TIA.


Valued Contributor

Don't have an answer for you on the PPPC profile for you - I'm still trying to sort that stuff out myself.

As for those approved kernel extensions:

  1. Is the system(s) receiving the config profile getting managed via DEP or User Approved MDM? The MDM profile has to be fully operational for KEPC to work.
  2. Did the systems get the updated config profiles before you pushed down those packages?

Just two basic places to start. One time I was scratching my head troubleshooting and these two issues popped up on different systems...

New Contributor III

@taugust04 You may have hit the nail on the head. I was using a non-DEP machine (this company didn't go to DEP until extremely recently, so we have a lot of non-DEP machines that come back for reimaging, etc.) and used a pkg to enroll the machine, but I had a hunch this could have been an issue and went to quickly approve the MDM profile, but I tried this again and noticed the two profiles currently in use that allow for Mojave PPPC additions and KEXT whitelisting did not reload after I clicked approve on the MDM profile.

Any idea on if there is a trigger that can be used in conjunction with clicking approve on the Jamf MDM Profile to fix this issue at least for non-DEP machines that come through our IT?

An alternative way... our policies happen in a numbered there a setting in policy that forces jamf to repush config profiles? Maybe I can write a script to call jamf recon or something similar to do this. There would still be a race condition between having an admin click approve on the MDM profile vs. this policy with a script. To eliminate that, is there a script that can run via policy that would essentially block the next policy from being ran until someone acknowledged...say a popup from a script in that policy?

Contributor III

I think what you are looking for is this; 6153ed686e004034845b1190054c8da2
set a smart group for the jamf default PPPC profile installed and use that to scope any other required profiles and policies

New Contributor III

Interesting idea.

Currently the bulk of the policies and config profiles are set to happen on enrollment. I believe going this route would change my workflow for both DEP and non-DEP devices. Essentially I'd need this smart group to kick off a policy that runs a script that then calls out each of the current enrollment policies one by one. By the time this policy is ran, I have to hope that the race condition in place for the KEXT/PPPC config profiles to hit first. Maybe put a nice sleep timer in there at the beginning of the script along with a sudo jamf mdm to try to force the profiles to download first.

Have too many other deadlines for tomorrow, so maybe I'll play with this idea next week.

New Contributor III

So I haven't had a lot of time to revisit this, but interestingly enough...all workflows created work fine with a DEP machine. No popups/warnings at all. The flow is perfect.

As for the non-DEP machines, I was able to very quickly approve the MDM profile, and watched the KEXT and PPPC profiles load. While the KEXT's loaded without issue it wasn't enough to stop the messages on my osascripts. Maybe its something to do with loading the profile from a package file and "installer" not being an approved person because of how the machine was created with the package instead of via the DEP process. I guess things will remain manual for non-DEP machines for now until I somehow get enough time to dig deeper. Le sigh.