Make it a postflight script for a payload-free package. Add the package to Self-Service. Users can then "install" the package, which runs the script as root, and avoids the need for admin credentials.

...maybe even take advantage of Casper Suite 9.3's Network State Change and enable Make Available Offline policy criteria.

New Policy > Options > General > Trigger > [x] Network State Change

and

New Policy > Options > General >[x] Make Available Offline

My initial thought was also "why not just throw this into Self Service? That's what it was designed for." But if the script was designed to be run in the event that the Mac doesn't have a valid IP that possibly removes Self Service from the equation since SS requires a network connection to the JSS to be used (If only JAMF would figure out some way to show "offline" policies in Self Service when the app can't connect to the JSS, it would be an option, but alas, we can't do that as of yet)

My suggestions then would be to do possibly @donmontalvo mentions and make it available offline and use the NetworkStage Change trigger. But this could lead to the policy running quite frequently, and may not be exactly what you want.
If this really needs to be user initiated, although I don't completely understand why that would be, another option would be to create a small script/app that would make a change to a local writable file on the Mac, such as adding a timestamp to it, and use that file as the WatchPath for a LaunchDaemon that would trigger the LaunchDaemon to run the above script. Since that would run the script as "root" it won't prompt for any passwords.

The only thing is, you'd need to make sure the package you build would deploy the file and the LaunchDaemon and activate the Daemon all in one shot, with say a postinstall script. I would also make sure the file in question is buried well enough that casual browsing won't turn it up. Only because the launchd "WatchPath" construct requires the watched file or folder to be present or the launchd disables itself.

Only because the launchd "WatchPath" construct requires the watched file or folder to be present or the launchd disables itself.

You can avoid this by not using a WatchPath. Instead use "KeepAlive" with "PathState":

<key>KeepAlive</key>

  <dict>

     <key>PathState</key>

     <dict>

       <key>/private/tmp/.my_special_trigger_file</key>

       <true/>

     </dict>

  </dict>

Creating ('touching') this file causes the LaunchDaemon to start the job (script). Be sure your script removes this file, or it will be restarted again because the trigger file still exists.

Thanks for all the input so far. Looks like we are going the launchd route. We need it to be user initiated and offline since the users that will be running this will never have admin rights and they are fantastic at breaking internet connections. Thank you all again.

Thank you @gregneagle, we went the WatchPath route and after a bit of fumbling with the permissions it works like a charm. Our users now have the ability to fix a lot of their connection issues on their own (one of our most common HelpDesk Tickets). Again, a big thanks to everyone else for their input.

Hi @nick.cottle

I know I am a bit late to the replies here, but here are some additional thoughts that may be useful. Casper has a feature where you can run things in 'offline mode.' I think it could be an option to explore. In version 9 we have a policy trigger called Network State Change, which basically watches the path of a certain file, and if that file is changed (network change, hostname change) it can trigger the script. Having it set to ongoing and checking the box to make it available offline will cache the script locally, run it as root with the Casper framework, and run your script as you intend. This way you won't need to manage and deploy a launchd item, load it, and support it down the road.

This way the script is cached and ran locally, it is ran as root, and since you have already built it, there is no need to build anything further on top of what you have already coded to make it work. There is absolutely no issue going the launchd route at all, as this is just another way to do it with the built in tools Casper already offers.

I have used this method for login scripts that need to be ran regardless if the device is on network or not. Just note using a watchpath in a launchd will always trigger the script the second that file is modified in any way. Using the network state change trigger for a policy would operate in the same manner. So, I would be careful on how you implement the solution so you don't cause any headache for yourself. An example of a bad practice would be to set up a networkstate change policy that ran a recon, or did an API call. That means every time the user puts the laptop to sleep or changes networks you would be submitting a recon or invoking an API call. If devices do this in mass, it could cause problems.

Since your script is ran locally and does not do either of the two things I mentioned, I don't see much of a problem in that regard, but I figured I would toss out an example. Since Casper already does this, there would be no reason to deploy it as a .command file or an app. Just remember to test it properly before deploying.

So really I just basically explained what @donmontalvo suggested.

I hope this helps some of you.

-Tom

Thanks @tlarkin for the input, I have been out of the office for a couple weeks (new baby) so I couldn't reply. In the end we did go with a .command and WatchPath because we were able to have the end user run it on their own only when an issue arose. After some testing and other input it was the best fit for our needs. Thanks again, I hope that all made sense. Still a little low on sleep.