Figured this one out....
Building a distribution package with a Windows Action to launch an executable builds the following script :
Start-Process -wait "exe_path"
if ($? -ne $true)
The wait param coupled with logic to exit (aka continue the provisioning task) if the process fails will functionally hold up ldprovisioning at that step if the program will not close w/o user interaction. I removed the -wait param from Start-Process and was able to get ldprovisioning to exit gracefully.
Was going to suggest just something like that (another way is to throw something a the RUNONCE registry key, for instance, etc - millions of ways around it).
You MAY want to log this as an enhancement request as a "start & don't care" type action here -- https://community.ivanti.com/community/enhancementrequests .
Provisioning by and large (due to its nature) has to be very micro-manager'y -- like a doting parent, it needs to know if something fails, etc. It's not commonly used as such, but I can see occasional uses for a "fire & forget" type option.
I would recommend that you have SOME sort of tracing / logging in your "fire & forget" wrapper / handler though, as you will want to have some sort of indication what did/didn't work / where things are likely to have gone awry if things decide to go weird / break because DNS doesn't work / "act of little brother" or whatnot applies. I've pretty much always regretted it at some point when I decided that "surely that won't need any logging" so far...
Thankfully this program will log *all* of its problems if it fails and restart itself minutes later. Its pretty persistent.
OS Provisioning is so flexible that we use it for every little thing we have to distribute sans patching, which is how I get into hacky situations like this!
Thanks for the enhancement link, Ive got several submissions to make...