Package post-install action to start exe under user account

[TurboPhil]

Similar to the discussion on this thread, I'm trying to come up with a workaround for the problems associated with the SystemlinkClient running under the SYSTEM account. We would like to be able to deploy packages containing built executables via Systemlink, and have the executables run immediately once installed.

We have configured packages to have a "Post-Install All" scheduled action to start the executable, but since this action is called by the SystemlinkClient *service*, the executable also ends up running under the SYSTEM account, and thus has no UI. This knowledgebase article suggests putting a shortcut in the startup folder and then rebooting the machine after install, so the executable can start under a named account after reboot & login. However, that is not feasible if we ever wanted to install or upgrade a package without rebooting (for example, if we have other critical processes running on that machine, and we only want to update one of them).

The other thread suggested we could try running the Salt-Minion service under a named account to work around this sort of problem, but I tried doing so on a test system, and it doesn't appear to be working for me. After upgrading/downgrading a package configured with a post-install action to run an executable, the executable still ends up running under the SYSTEM account. (I also don't particularly want to use the PsExec solution from that other thread, since I'd prefer not to store credentials in a script file).

Could we get some detailed instructions on what steps we would need to take to run the SystemlinkClient under a named account? I suspect there are *multiple* services that need to be reconfigured (so far, I have done the "NI Salt-Minion" and "NI Minion Agent Service for Systems Management" services, but so far that has not been sufficient).

And it would also be great if this could be scripted, as we will need to do it on every client system....

[TurboPhil]

Upon further investigation, it seems that the problem has more to do with the Session than the User.

I updated the NI Salt-Minion service to log in as named user, and now I can see that an executable launched as a post-install action by the salt minion does indeed run under than same username, but it is still in session 0, so it is still headless.

We would like to be able to install and run executables remotely, but be able to RDP in and interact with the executable as necessary. But so far, I'm not seeing any way to do this with the native Systemlink Client behavior.

We *might* be able run leverage something like this CreateProcessAsUser, but I'm not sure how to go about modifying the minion to call an executable using that function.

[TurboPhil]

Looks like this might be an inherent shortcoming with SaltStack:

https://github.com/saltstack/salt/issues/4834