Development & Testing of DEPNotify Script?

[damionbroadaway]

Hello there.

Full Disclosure:

I am a dev tasked with helping write the script but have very limited knowledge on Jamf. However, I do have access to Jamf Pro. If this is the wrong place or wrong location I am sorry. I have looked for documentation for doing this and haven't found any.

What is the most efficient way to develop and test a DEPNotify script?

Current Process:

• Have a VMWare instance of the latest macOS with serial number already added to Pre-Stage.
• Take a shapshot before DEPNotify runs.
• Reload VMWare snapshot to test changes.

Current Pain Point:

I have to take the snapshot pretty early in the setup process before the Profiles get installed. This means it can take several minutes to get through just to test any change.

What are my options?

Is there a way to test locally via some type of emulation tool?

Is there way to call the DEPNotify.pkg directly in the VM?

I have done this but it just shows the last screen saying it's complete. Can it be reset?

Can I push an update out via Jamf that triggers it to run again?

I'm looking for any options that will help make this process more streamlined. Surely this isn't how people create complex provisioning scripts. Right?

[steve_summers]

When I was testing Nomad, I first built a clean Mac with AutoDMG (https://github.com/MagerValp/AutoDMG), then converted it, adding a model and serial number with VFuse (https://github.com/chilcote/vfuse) and then, before I even powered it on with VMware Fusion, took a snapshot.  That worked every time for a clean snapshot for DEP/ABM testing.  One note though: On AutoDMG, if you're creating a Big Sur 11.6 VM, your Mac has to be on that release level.  

As far as your options, I mean, you just need to test it in your current build process (to me) and each time you revert to your snapshot, delete the computer record from Jamf and walkthrough the setup assistant again.  

Now you COULD take a snapshot right as it's coming out of setup assistant, but then if you wanted to test again, delete the policies out of the computer record (so it has to run them all again).  That might help..but to me, I prefer the clean way of doing things.  

[damionbroadaway]

Thank you for responding.

I think I understand what you're saying. But I also think it's what I'm trying to avoid.

---

As far as your options, I mean, you just need to test it in your current build process (to me) and each time you revert to your snapshot, delete the computer record from Jamf and walkthrough the setup assistant again.  

---

So, my only option to test any change is to completely go through the setup process?

For example - I updated the title. I run through the whole setup and notice I have a typo. My only option is to fix the typo and run through the whole setup again?

There's no way to "reset" DEPNotify so I could just re-run it again with changes? Doesn't that make developing and testing these scripts incredible tedious and time consuming?

[steve_summers]

I think there is a way.  

When you walk your VM through setup assistant and you've noticed a message you aren't happy with or something, you could edit your code, re-upload it into your Jamf Policy, then you'd have to go and (I think) do three things:

-Locate the computer record in Jamf and delete the policy history which runs the Nomad script

-Delete the entries in the log file being used by Nomad

-On the test VM open terminal and then, use "sudo jamf policy -id <policy ID here>"

I think ...that'll work.  I used Nomad in another role and now my new gig, we're using Jamf Connect.  

[damionbroadaway]

Thank you. I'm not familiar with Nomad but still appreciate it.

I did find out you can just run the depNotify.sh script directly in the vm and it will launch. Which is great news.

Thanks again.

[mm2270]

You could put the DEPNotify script or scripts into a policy that can be called manually from Terminal using a custom event trigger, rather than it being called on enrollment complete. So for example, scope that policy to a device (physical or virtual), add a custom trigger event to the policy. Then on that device run sudo jamf policy -event <trigger-name> to call the policy. It should do all the same stuff as when it kicks off after enrollment, but without needing to do the enrollment.

Also make sure to put the frequency of the policy to Ongoing so you can run it over and over if needed. All you would have to do is tweak the script each time. You may also want to temporarily set up some dummy items in the script so it's not doing something like installing software over and over each time perhaps.

[damionbroadaway]

This is fantastic. I'll get with our actual Jamf admin and see if this is something we can do in our setup without disrupting anything.

[mm2270]

One thing I forgot to mention. You stated

I have done this but it just shows the last screen saying it's complete. Can it be reset?

---

Yes, this is normal behavior for DEPNotify, because it picks up on the previous log file that it created on first run, so in order to have it go properly through all the steps, you want to make sure to either manually delete that depnotify.log file completely so it creates a new one on next run, or you can add something to the script perhaps that kicks off DEPNotify to delete that log if located, before it sets any of the initial values for DEPNotify to pick up on launch. Otherwise, yes, you will have the issue that it launches and comes up each time showing the last item you told it to do in the script.

[damionbroadaway]

Good to know. Thank you.