The message seem to indicate the value “localuser” for keyword RunAs is not recognized. Are you sure you are using 9.5.5?
Also, I believe keyword Password is required for Windows. (When I ran the same override with 9.5.5.193 FixletDebbuger, I got the message “RunAsLocalUser in Windows requires the keyword 'password' to be speicifed.”)
The domain account should be supported but the statement should reflect that the user needs to have logged onto the machine at some point. So if the domain user has never logged onto the endpoint it wouldn’t have a registry hive local to the machine.
Hmmm… Then that’s not very handy, is it? So even if I’m creating a service account for software deployment, that would mean that I need to log in on 18k devices first so that I can use that account? Are there any plans to change this so that it just looks in the Local Groups (like Administrator) and see if it’s there?
You have software that fails to install when run under the System account, but succeeds when installed as a service account?
Does the software require admin rights to install?
You might be able to get an account to show up as having logged in by using something like PSExec or similar on the machines through bigfix if the account is not in the list. I’m not sure what is required to appear on that list. RDP should work, but still not a good solution.
Another option might be to have BigFix create a local admin user with a randomized password and then use it and delete it. Definitely not an elegant option.
We are working to remove the requirement for the user to have previously logged in for a future release along with some privilege escalation capabilities that should help.
Steve, is there an ETA when this will be available? So many of us Administrators out there need this fixed and we’ve been waiting for this for so long. I’m faced with having to manually do an install for 800 machines, but if you and your team perfected this you would be lifesavers!
Hi James - Some use cases that we have are programs that are Profile specific. For example, WebEx Productivity Tools. If installed as System, they appear in Control Panel > Programs, but no where else. The user would have to located the EXE in the file system and open it for it to work.
Running as user works great if UAC is disabled, but UAC isn’t disabled on all of our endpoints, so it would be hit or miss.
OneDrive would be another example of a Profile specific installer.