Ignoring Parameters in Jamf Pro

[bfriedman-od]

I'm trying to use erase-install to update some computers to 12.6.1 but it seems to be ignoring the parameters I include regardless of where I put them.

I created a policy that installs the DEPNotify version of the package. Erase-install always runs, but skips the parameters and just downloads Ventura. I've tried adding parameters to the "Execute Command" field: it ignores them. I've tried using the launcher script with parameters added to fields in Jamf's script interface: it ignores them. I've tried making the launcher script run first: it fails because erase-install doesn't exist yet. I've tried adjusting the parameters I use: it ignores them.

I'm really not sure what I could be doing wrong. I tested running erase-install directly in Terminal with parameters included in the command and it works as intended. Does anyone have suggestions where I might be getting this wrong?

[grahampugh]

The methods for supplying parameters are shown in the wiki. But feel free to post screenshots or full commands so we can see what you're doing wrong.

[grahampugh]

I see that you have also put two parameters into a couple of fields. You can't do that.

[cvgs]

Here are the parameters as entered into the "Options" for the launcher script in Jamf Pro:

It seems that you added the your parameters in the wrong section of Jamf Pro; the user interface is really confusing here. Jamf should probably rename the headers from "Parameter X" to "Label X" in that screen.

Just follow the hints in my previous comment to get the launcher script working.

The order of the parameters do not matter. But when using the launcher script, you can add multiple parameters into one field if needed.

[grahampugh]

Oh yes, oops, I had not noticed this was the launcher script rather than erase-install itself.... and once again, had not noticed that @madefromsteel was mistakenly putting values into the Script Labels! Pay attention Graham...

[grahampugh]

I've added some emphasis to the wiki, maybe this will reduce the confusion for people?

Alternatively, you can add a launcher script to the policy that runs the above command. The advantage of a launcher script is that if erase-install fails for some reason, this will get reported as a failure to the Policy Logs, whereas the Execute Command always returns a success. With erase-install version 27.0 and above, we supply an example launcher script, erase-install-launcher.sh, that you can upload to Jamf, add to your policy, and add your erase-install.sh arguments into the policy's script parameter fields (not the Parameter Labels of the script itself!!).

[bfriedman-od]

Oh yes, oops, I had not noticed this was the launcher script rather than erase-install itself.... and once again, had not noticed that @madefromsteel was mistakenly putting values into the Script Labels! Pay attention Graham...

It's ok, it's your first day. Right? 😛

I've added some emphasis to the wiki, maybe this will reduce the confusion for people?

Yep, that should help.

[grahampugh]

Not sure really what to suggest. I just tried running the wrapper script with joined up parameters, and it behaved as expected:

sudo ./erase-install-launcher.sh _ _ _ "--version=13.1 --move" "--no-fs --reinstall" "--test-run" "--current-user" --seed CustomerSeed "--beta --pkg"

This did select specifically 13.1, it did ask for current user, and it did honour the beta parameter. So it really looks like it's working as it should.

I would suggest you post the entire log output here. You should see it in your Jamf logs or in /Library/Management/erase-install/erase-install.log.

[bfriedman-od]

I don't have any of the old logs on Jamf. I didn't think to change the policy's settings for testing purposes and it was set to run once per computer, so I had to flush the log every time to get it to be available again. D'oh!

I just ran it again using the same parameters on the launcher script as shown in the screenshot from my previous response. Here's the log from that: erase-install.log.

[bfriedman-od]

I just tried to do this again by adding the parameters directly to the launcher script on line 22:

• I replaced: IFS=" " read -r -a eraseinstall_args <<< "${4} ${5} ${6} ${7} ${8} ${9} ${10}"
• With: IFS=" " read -r -a eraseinstall_args <<< "--version=12.6.1 --reinstall --depnotify --no-fs --current-user --pkg --check-power --power-wait-limit 180 --test-run"

It worked perfectly. So for some reason the parameters placeholders aren't getting replaced with the actual parameters.

[grahampugh]

Paging @cvgs - this script is their baby ;-)

[bfriedman-od]

Sounds good. Thanks, Graham.

[xrdscole]

I’m believe I'm adding the parameters to the policies > scripts section. It works great as a Self-Service policy, using the curl command, etc, in the parameters. However, I would like to configure it to download the latest version of 12.6.1 as an upgrade, not a wipe. I'm not using it via files and process payload, only policy with the script attached.

…

________________________________ From: bfriedman-od ***@***.***> Sent: Thursday, November 17, 2022 7:26:58 AM To: grahampugh/erase-install ***@***.***> Cc: Robert Cole ***@***.***>; Mention ***@***.***> Subject: Re: [grahampugh/erase-install] Ignoring Parameters in Jamf Pro (Discussion #310) Oh yes, oops, I had not noticed this was the launcher script rather than erase-install itself.... and once again, had not noticed that @madefromsteel<https://github.com/madefromsteel> was mistakenly putting values into the Script Labels! Pay attention Graham... It's ok, it's your first day. Right? 😛 I've added some emphasis to the wiki, maybe this will reduce the confusion for people? Yep, that should help. — Reply to this email directly, view it on GitHub<#310 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AN7N4ZNIELDLVZJULTB3U4LWIZFEFANCNFSM6AAAAAARXSIHVI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[bfriedman-od]

Since you're using Jamf Pro, I'd recommend using the launcher script as the actual script attached to the policy. Add erase-install as a package the policy downloads. So download a package from the Releases page and add it directly, don't extract anything from it.

[xrdscole]

Appreciate your assistance with this @bfriedman-od and @grahampugh . So, you're suggesting to attach the erase-install-launcher.sh script to a policy instead of attaching the erase-install.sh script?

Just to be more clear, what I was doing was attaching the erase-install.sh script to a policy while using "--force-curl" in parameter 4 value and " --erase" or "--reinstall" as the parameter 5 value to do a complete wipe. This workflow worked fine. However, what would happen is it would download Ventura, and I like to specifiy 12.6.1 as a parameter, just unsure of which parameter number to place it in the policy.

What's the advantage of using the (erase-install-launcher.sh )launcher script instead?

[bfriedman-od]

What's the advantage of using the (erase-install-launcher.sh )launcher script instead?

"The advantage of a launcher script is that if erase-install fails for some reason, this will get reported as a failure to the Policy Logs, whereas the Execute Command always returns a success."

Plus, if you push the package with the policy it'll put the Python bits in place rather than having the script retrieve them.

Oh, and as @cvgs mentions above, you can have multiple parameters in a field, if necessary.

[xrdscole]

Hey @grahampugh quick question about erase-install-launcher.sh. I'm using a policy with a erase-install.sh payload. Works great. I have my parameters set in Parameter 4 --reinstall and Parameter 5 --update within the Policies > Scripts > Parameter Values section. No issues at all.

I'd like to start using the erase-install-launcher.sh script. I think these reporting features are helpful.

In this case, do I remove the erase-install.sh script from the Policy, add the erase-install-launcher.sh in place of it, while keeping the same parameters?

From my understanding, the erase-install-launcer.sh script will kickstart the latest version of erase-install.sh script and it will keep the parameters so long as I add them to it the same way. Just of the want to run this by you or anyone that's using this flow prior to testing.

[grahampugh]

See the documentation at the top of the script:

erase-install-launcher.sh
This script is designed to be used as a stub for launching erase-install.sh when
deploying the standard macOS package of erase-install from within Jamf Pro.

You can simply add this script to the "Scripts" section of a Jamf Pro policy,
which will in turn launch erase-install.sh with all supplied parameters and
return its output and return code back to Jamf Pro.

You can use Jamf Pro parameters 1-10 to supply arguments to erase-install,
and you can supply multiple arguments in one Jamf Pro parameter.

The last parameter can be used to specify the location of erase-install.sh, if
you have deployed a custom version of erase-install at a different location.

In case that wasn't clear, the launcher script is only to be used in conjunction with the installer package we supply in this repo.

Yes, when using that particular launcher script, you can use the same parameters, and you can have multiple parameters in the same Parameter field in Jamf. You can also omit the = signs.