How to tell DEPNotify-Starter script where to find installing/executing apps, read them automatically and display them

ali_fadavinia
New Contributor III

Hey Folks,

I read all the depNotify posts here and followed along. My depNotify is working fine, same as my starter script.

Here is what I did:

Based on this guide ( https://github.com/jamf/DEPNotify-Starter#configuration-within-jamf-pro) I did following steps in our jamfPro:
  1. I uploaded the installer package called DepNotify-1.1.5 according to the link above
  2. I created the script called as the depNotify Starter
  3. I created a policy and associated my package and script to that
  4. I scoped that policy to our test computers.

Everything works fine and the app starts right away once test user logs intp the mac in question.

The problem/question for me is, how should I specify in the script which apps/policies are running at the moment?

I found POLICY_ARRAY in the script and whichever I put there in the format of

policy_name, id

it gets displayed in the prompt for the test user. Should I add all policies(that mac is supposed to download/install) manually in order ? if so, it does not make sense to me. I think I am missing something.

Unfortunately, the comments in the script only explain about the commands but not about how to connect/associate policies, we defined on JamfPro, and display on the screen for the user. I m missing something.

My question is how I can automate this? how the script, itself, can go and read from my JamfPro policies what is being executed and display it for the test user accordingly. How should I add such thing in the script(if it is possible) and where?

Any help is greatly appreciated.
Ali

2 ACCEPTED SOLUTIONS

mm2270
Legendary Contributor III

If you're talking about the policy array in the script that looks something like this:

POLICY_ARRAY=(
    "Installing Adobe Creative Cloud,adobeCC"
    "Installing Adobe Reader,adobeReader"
    "Installing Chrome,chrome"
    "Installing CrashPlan,crashplan"
    "Installing Firefox,firefox"
    "Installing Java,java"
    "Installing NoMAD,nomad"
    "Installing Office,msOffice"
    "Installing Webex,webex"
    "Installing Critical Updates,updateSoftware"
  )

Then yes, what you have to do is set up a custom trigger for each policy that you want to run as part of your DEP onboarding policy, make sure the scope is set correctly and then update the above array with the name of the software and then the actual trigger that you've added to those policies in that array.
What happens is when the script runs, it runs a loop that goes over each of those items in the array, in the order you've added them into that array, and extracts the custom trigger from each one and calls that policy. At the same time, the progress bar text is pulled from the array items and passed back to DEPNotify and the progress bar gets updated correspondingly.

Edit: Just to make it more clear, the custom triggers are added in the policy at the bottom of the regular triggers section, directly under the Recurring Check-In trigger. It looks like this:

7bed9212eb184ec08031b9776acccac4

View solution in original post

Tribruin
Valued Contributor II

@ali.fadavinia , the "Uh oh, Something needs fixing" error occurs when the script finds the DEPNotify logs files already existing, when run as TESTING_MODE=false

Check and delete the following files from your computer before running the script with testing mode turned off

/var/tmp/depnotify.log
/var/tmp/depnotifyDebug.log
/var/tmp/com.depnotify.provisioning.done

View solution in original post

8 REPLIES 8

mm2270
Legendary Contributor III

If you're talking about the policy array in the script that looks something like this:

POLICY_ARRAY=(
    "Installing Adobe Creative Cloud,adobeCC"
    "Installing Adobe Reader,adobeReader"
    "Installing Chrome,chrome"
    "Installing CrashPlan,crashplan"
    "Installing Firefox,firefox"
    "Installing Java,java"
    "Installing NoMAD,nomad"
    "Installing Office,msOffice"
    "Installing Webex,webex"
    "Installing Critical Updates,updateSoftware"
  )

Then yes, what you have to do is set up a custom trigger for each policy that you want to run as part of your DEP onboarding policy, make sure the scope is set correctly and then update the above array with the name of the software and then the actual trigger that you've added to those policies in that array.
What happens is when the script runs, it runs a loop that goes over each of those items in the array, in the order you've added them into that array, and extracts the custom trigger from each one and calls that policy. At the same time, the progress bar text is pulled from the array items and passed back to DEPNotify and the progress bar gets updated correspondingly.

Edit: Just to make it more clear, the custom triggers are added in the policy at the bottom of the regular triggers section, directly under the Recurring Check-In trigger. It looks like this:

7bed9212eb184ec08031b9776acccac4

ali_fadavinia
New Contributor III

Thanks, gotcha!

I did that, I used the id as my trigger; I checked one of the policies that install Acrobat Reader as the test, id for that is: 36. Then I placed it in the POLICY_ARRAY :

Trigger to be used to call the policy

#############################################################################

TRIGGER="id"

Policy Variable to Modify

#############################################################################

The policy array must be formatted "Progress Bar text,customTrigger". These will be run in order as they appear below.

POLICY_ARRAY=( "Installing Acrobat Reader,36" )

###########################

Now, if I run the depNotify and leave TESTING_MODE=true progress are displayed as attached img:one.png, and it says it successfully completed( although it is not installing it really).

But if I change the TESTING_MODE= false, I get this error and stuck there (attached img:fail.png).

Any idea where I am missing?
0aac6e8c891d4c9d98bc967007952c35

b8ed8c263c554034a1e4241d519815bf

mm2270
Legendary Contributor III

@ali.fadavinia I would double check the scope on the policy or policies that you are calling in the script. If the scope isn't set properly, when the script attempts to call the policy it will fail since the jamf binary will report no policies found for that ID. That's the main thing that comes to mind.

ali_fadavinia
New Contributor III

The scope is very narrowed down to only two test macs - as it is working with TESTING_MODE=true.

For simplicity also, instead of having Trigger set to Enrollment Complete, I just made it available in the Self-Service so we can try and test it easily.

Interesting thing is I did not touch the original code at all, the only place I touched is:
TRIGGER="id"
POLICY_ARRAY=( "Installing Acrobat Reader,36" )
but when I turned the TESTING_MODE to false, I get that error message.

Also...I thought to mention this and update you:

Interestingly, I went to lanes between 782-790, and I copied this line of code : - "$JAMF_BINARY" policy "-$TRIGGER" "$(echo "$POLICY" | cut -d ',' -f2)" and pasted it underneath the if condition for TESTING_MODE" = true { Originally, this line of code should be running when TESTING_MODE" = false}.

Then everything worked fine and even that Adobe Reader got installed successfully.

So I don't know if there is any bug in the original code or if I make a logical error mistake? Any thoughts?

# Loop to run policies
 for POLICY in "${POLICY_ARRAY[@]}"; do
    echo "Status: $(echo "$POLICY" | cut -d ',' -f1)" >> "$DEP_NOTIFY_LOG"

    if [ "$TESTING_MODE" = true ]; then
       #The below line is NOT from Original Script, I pasted here#
     "$JAMF_BINARY" policy "-$TRIGGER" "$(echo "$POLICY" | cut -d ',' -f2)" #ALI  ADDED this#
      sleep 10

    elif [ "$TESTING_MODE" = false ]; then
      "$JAMF_BINARY" policy "-$TRIGGER" "$(echo "$POLICY" | cut -d ',' -f2)"
    fi
  done

f898b926e7104450a58c280dd9748117

tlarkin
Honored Contributor

This is one of the reasons I use Python dictionaries for this.

MAIN_POLICY_DICT = {
    "install_Finder_Prefs": "macOS Finder Preferences",
    "autoupdate-Firefox": "Firefox",
    "install_Chrome": "Google Chrome",
    "install_slack": "Slack",
    "install_office": "Microsoft Office",
    "autoupdate-zoom.us": "Zoom Client",
    "install_dependencies": "Initial Dependencies",
}

Then my main function that calls policies in DEP Notify

def run_policies():
    """run the policies from the MAIN_POLICY_DICT"""
    write_to_dnlog("Status: Installing software...")
    num_of_policies = len(MAIN_POLICY_DICT)
    write_to_dnlog("Command: DeterminateManual: %s" % num_of_policies)
    for index, (key, value) in enumerate(MAIN_POLICY_DICT.items(), 1):
        # get the vanity name from the MAIN_POLICY_DICT
        name = value
        write_to_dnlog("Status: Deploying %s" % name)
        write_to_dnlog("Command: DeterminateManualStep:")
        logging.info("starting %s policy..." % key)
        cmd = ["/usr/local/bin/jamf", "policy", "-event", str(key)]
        proc = subprocess.Popen(cmd, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
        out, errors = proc.communicate()
        if proc.returncode != 0:
            error_msg = "%s code %s" % (errors.strip(), proc.returncode)
            logging.error("jamf binary failed to install %s, %s", key, error_msg)
            write_to_dnlog("Status: %s policy failed, please see logs..." % key)
        elif proc.returncode == 0:
            logging.info("jamf policy %s returned successful.." % key)
            write_to_dnlog("Status: %s was successfully installed..." % name)
    write_to_dnlog("Command: DeterminateOff:")
    write_to_dnlog("Command: DeterminateOffReset:")

So, I can get the len() of the dict and use that as a manual determinate step to tell DEP Notify to progress the bar. The above example is my self contained package version so, the policies are hard coded in the script since everything runs via package and launch daemon. I have another version that uses positional parameters in jamf and is called as a policy.

I find this much easier to mange vanity names and policies with how DEP Notify and jamf works

ali_fadavinia
New Contributor III

Thanks for your response, as I explained above it is working fine either with policy id, or customEvent.

The issue is that when I change the TESTING_MODE to false, I get that error ( no where in the original code has been changed ).

For Testing Purposes
I copied and brought the exact line of code { "$JAMF_BINARY" policy "-$TRIGGER" "$(echo "$POLICY" | cut -d ',' -f2)" } from the condition snippet of TESTING_MODE=false, pasted it under condition of TESTING_MODE" = true; as a result of this, I did not get any errors: policies get launched, executed and App-installation gets completed successfully.

How is this possible?

Tribruin
Valued Contributor II

@ali.fadavinia , the "Uh oh, Something needs fixing" error occurs when the script finds the DEPNotify logs files already existing, when run as TESTING_MODE=false

Check and delete the following files from your computer before running the script with testing mode turned off

/var/tmp/depnotify.log
/var/tmp/depnotifyDebug.log
/var/tmp/com.depnotify.provisioning.done

ali_fadavinia
New Contributor III

Sweet! yes, it is working now!

In the code - line 453, it checks for those old config files if present -Testing Mode Only. That is why I was not getting any error.

Thank you!