jamf + Catalina + Dep Notify Deployment Failure

Contributor III

This work flow has been fine with High Sierra, and Mojava, but fails in Catalina.

PreStage -> Setup Wizard -> Rename & Join AD (Reboot) -> all works fine

On 1st Login -> Install DEPnotify (version 1.1.5) & run jamfs DEP-Notify Script (v2.0.1) - Completely Fails on Catalina

It looks like it won't install any packages from our on-prem distribution point.

I suspect it's a PPPC permission issue.


Valued Contributor II

im going to guess that your On Prem DP is a Samba Share. @jstillio

a few topics on this. my advice - make an HTTPS DP (or two) & use them for Catalina deployments.

You're going to need to whitelist a few things via a PPPC profile in order for depNotify to work on Catalina via a smb share.



Looking for a Jamf Managed Service Provider? Look no further than Rocketman

Virtual MacAdmins Monthly Meetup - First Friday, Every Month

Contributor III

I ran into a similar issue with ADEPT which is similar to Depnotify. I added a PPPC to the prestage and it fixed it for me.



@m.donovan Thanks for posting this. I had the same issue in Catalina using the "login" trigger and changed over to enrollment complete which is working for now but not as clean as I want it to be. I'll take a look at adding your PPPC settings.

Contributor III

@Hugonaut Yep, you guessed correctly, SMB no http(s) access
Getting http(s) on SMB will be a small project.. but will start pursuing it.

@m.donovan Thank you, Created a supplemental PPPC profile that only applied to Catalina machines.

I did have to add the following:
com.appleTerminal - SystemPolicySysAdminFiles (Allow)

For safe measure I also added (zsh) /bin/zsh to have SystemPolicyNetworkVolumes & SystemPolicyAllFiles - Allow
Since all my new scripts and converting old scripts to zsh proactively before Apple removes bash.

Contributor III

I'm using DEPnotify with a launch daemon that runs a Jamf policy with provisioning script. The script calls on other policies to deploy packages via custom triggers. Internally using SMB FSDP and just ran into the "CP operation not permitted" issue while working on Catalina and new 2020 MacBook Airs.

Creating a PPPC for /bin/bash and /bin/sh, with allow Network Volumes and All Files did the trick. I did not have to include Terminal, CP, or loginwindow for things to work.

Esteemed Contributor II

@MrRoboto I'm curious, any reason you don't use http(s) on your internal DP? In my experience it's a significant improvement over SMB because a download request doesn't incur the overhead of mounting the DP's file system as with SMB (and no need for a PPPC), and you'll get resumable downloads which can be a Good Thing for Wi-Fi connected Macs. Should you ever have the need for a public facing DP, and a Cloud DP isn't an option, you'll pretty much require https as most network folks will just laugh at you if you ask about opening the ports needed for external SMB access on a firewall.

Contributor III

@sdagley Unfortunately going with SMB was not my decision. We had HTTPS back in the JDS days but when that went EOL and our old Mac minis were aging out, we had to move to a different solution. Since we already have a Windows server at every site we opted to set up FSDP on those. They are running DFS so that took care of replication but due to conflicts with other services running on the server we could not use HTTP so SMB it is. Works okay but larger packages over wi-fi can be an issue. When deploying Adobe CC packages I include caffeinate scripts in the policy to keep the connection live. For now we only serve packages internally so SMB is okay. We will be moving to Jamf Cloud and will look at Cloud DP for external access.

Esteemed Contributor II

@MrRoboto Been there, done that with having to live on infrastructure deployed for Windows management. Not fun.