It is my understanding that when deploying software with BigFix it is run under the local system account.
I need to deploy a stub which when executed by BigFix it will connect to a network share after checking whether the logged on account is logged on to an AD Domain. As we know, neither of those cases is possible when the local account is being used, the latter due to authentication.
I do NOT want to use a “Run As” command for obvious security concerns. Is there another known way to force BigFix to install software (in this case run a stub) using the actual logged on user’s account credentials without using “Run As”
I appreciate any input that has been proven to work reliably.
You can try using a utility that is on all client machines as part of the BES Support site called ‘RunAsCurrentUser’. This utility will launch the executable in the currently logged on user’s context.
Thanks jessewk for the reply. Most definitely a great lead and good start. However, I cannot find this executable present on the system (I understand that I can download it though) Thus, I am assuming that I will need to copy it first, determine that the file exists and then launch my executable using the “RunAsCurrentUser.exe” syntax. I need a little help here. First, can I copy this file anywhere, e.g., Windows and reference its location when running my exe? Second can I use the SW deployment wizard when invoking “RunAsCurrentUser.exe” Third, what would be the syntax needed to launch my exe while invoking “RunAsCurrentUser.exe” ?
I cannot find this executable present on the system
You’ll find that all clients subscribe to the BES Support site and have a copy of RunAsCurrentUser.exe at the path __BESData\BES Support. A good way to launch RunAsCurrentUser in an action script is using a command like this:
waithidden
"{pathname of client folder of site "BES Support
"}\RunAsCurrentUser.exe"
Noel
Can I copy this file anywhere, e.g., Windows and reference its location when running my exe?
Yes, you can copy this file and use it from anywhere you would like.
Noel
Can I use the SW deployment wizard when invoking “RunAsCurrentUser.exe”.
Yes, on the last page of the software deployment wizard, you will want to check the box in the bottom left to ‘show custom task dialog’. This will allow you to edit the script that is generated by the wizard. You can modify it to call RunAsCurrentUser there. Alternately, if you have already created the task you can right-click --> Edit custom task and make your changes that way.
Noel
What would be the syntax needed to launch my exe while invoking “RunAsCurrentUser.exe” ?
Just pass RunAsCurrent user the command line you would normally use to launch the executable. For example:
waithidden
"{pathname of client folder of site "BES Support
"}\RunAsCurrentUser.exe" cmd.exe /C powercfg.exe /change
Also note that RunAsCurrentUser.exe immediately returns (without waiting for the sub-process to finish). If you want RunAsCurrentUser.exe to wait, give it a “–w” command as the first argument:
waithidden
"{pathname of client folder of site "BES Support
"}\RunAsCurrentUser.exe" RunAsCurrentUser.exe --w cmd.exe /C powercfg.exe /change
there is a typo in jessewk’s syntax above. Instead of typing {pathname of client folder of site “BES Support”} in all of the code examples above, it should say {pathname of client folder of site “BesPowerManagement”}. If you are not subscribed to our power management site you can download the utility from http://support.bigfix.com/download/bes/util/RunAsCurrentUser.exe
Also --w switch doesn’t seem to work. Note other threads on runascurrentuser.exe:
Actually, I believe the --w switch does work, but it may not do exactly what you expect. It causes RunAsCurrentUser.exe not to terminate until the spawned process terminates; however, since RunAsCurrentUser is not a console app it will always return immediately when called from the command line or a .bat file (think of what happens when you type calc.exe into a command window).
The reason RunAsCurrentUser.exe is not a console app is so that there is no risk of causing a console window to pop up on the user’s screen.
So the expected usefulness of the --w flag is in something like:
wait RunAsCurrentUser.exe --w calc.exe
This usage would cause the client to wait until the calc.exe application terminates before moving on to the next line of actionscript. (not a good idea!)