I know this has been talked about all over, but for whatever reason, it isn’t clicking in my brain.
I want to run a command line as current user. I’m using BF 9.5.10 so I’m sure I can use the new “runas=currentuser”. I also think the method is to create a CMD file within the fixlet instead of using relevance as I usually would.
First, the relevance that I currently use that works 80% of the time as System is: waithidden msiexec.exe /X { name of keys whose( (exists values "DisplayName" whose(it as string as lowercase starts with "Kaspersky Endpoint Security 10 for Windows" as lowercase) of it) AND (exists values whose(it as string as lowercase starts with "msiexec") of it) ) of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" of ( x64 registries; x32 registries ) } KLLOGIN=KLAdmin KLPASSWD=password /qn
But do to permission issue on some systems, the command has to be run as the local logged on user.
I gather I cannot run relevance as current user by simply placing “runas=currentuser” ahead of the action script?
Maybe something like this? I have not tried this yet in my environment.
delete __appendfile
delete Install_KES10.bat
appendfile msiexec.exe /X { name of keys whose( (exists values “DisplayName” whose(it as string as lowercase starts with “Kaspersky Endpoint Security 10 for Windows” as lowercase) of it) AND (exists values whose(it as string as lowercase starts with “msiexec”) of it) ) of keys “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall” of ( x64 registries; x32 registries ) } KLLOGIN=KLAdmin KLPASSWD=password /qn
move __appendfile Install_KES10.bat
I have looked at that and it looks pretty straightforward, but it isn’t addressing my question.
Can I simply add the following four lines to an existing, working, action scrip and expect it to run as current user or do I have to use it with a bat file. I ask because I’m getting “Unable to parse action script”.
waithidden msiexec.exe /X { name of keys whose( (exists values "DisplayName" whose(it as string as lowercase starts with "Kaspersky Endpoint Security 10 for Windows" as lowercase) of it) AND (exists values whose(it as string as lowercase starts with "msiexec") of it) ) of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" of ( x64 registries; x32 registries ) } KLLOGIN=KLAdmin KLPASSWD=password /qn
Thanks. I’m still having failures but I’m unsure whether that is the script of it just failing on the endpoint. I gather that if I create the bat file manually and run it from the __Downloads directory, I can verify if it works or not.
Could the issue be that the user account does not have permission to the __Download folder? Maybe copying the __appendfile to a folder that isn’t restricted by UAC and/or permissions restrictions and trying might yield some different results?
Possible. We also have a mix of endpoints with UAC enabled/disabled which I know will affect anything running as the user. I’ll add that to my list to try. Thanks!
This is a great suggestion – in my environment whenever I override and run as current user, I move the script to a specific folder that I have made sure users have access to, and is also whitelisted in AppLocker.
Here’s another example. This time I am using Powershell in the Action Script itself. The PS uses Microsoft.VisualBasic.Interaction MsgBox; so I want a Message Box to appear on the user screen. This PS works perfectly in the QnA Debugger, but as expected, running via BigFix itself, as System, does not show the message box to the user. I added “runas=currentuser” in the Action Script, but that didn’t work, returning the error in the client logs:
Command failed (Process creation failed) run As=currentuser (action:201186)
What options are best to deploy a PS script that pops-up a message to the user? To give you some context, users with less than X GB of space on their drive pops up a message box.
// Disable wow64 redirection on x64 OSs
action uses wow64 redirection {not x64 of operating system}
//PS
waithidden cmd /C powershell.exe -ExecutionPolicy Bypass -command Add-Type -AssemblyName Microsoft.VisualBasic; $disk = get-wmiobject Win32_LogicalDisk -Filter "DriveType = 3";$bitsfree = ($disk.size - $disk.freespace);$bytesfree = ($disk.size - $disk.freespace)/4;$kilobytesfree = ($disk.size - $disk.freespace)/4/1024;$megabytesfree = ($disk.size - $disk.freespace)/4/1024/1024;$gigabytesfree = ($disk.size - $disk.freespace)/4/1024/1024/1024;if ($gigabytesfree -le 121) {{$result = [Microsoft.VisualBasic.Interaction]::MsgBox('C: Drive is LOW! As per IT Standard maintain min. 5GB free space to keep system STABLE with Updates. System will be disconnected from network considering UNSTABLE. Contact IT HelpDesk.','OKOnly,SystemModal,Critical', 'Compliance ALERT!!!');$result;}
//Run as Current User
runas=currentuser
I haven’t done much with this, but the override wait along with runas=currentuser need to come before the waithidden command, so it’d be more like the following; I also replaced ‘waithidden’ with ‘wait’, as I think you want the window to be visible.
override wait
runas=currentuser
wait cmd /C powershell.exe -ExecutionPolicy Bypass -command Add-Type -AssemblyName Microsoft.VisualBasic; $disk = get-wmiobject Win32_LogicalDisk -Filter "DriveType = 3";$bitsfree = ($disk.size - $disk.freespace);$bytesfree = ($disk.size - $disk.freespace)/4;$kilobytesfree = ($disk.size - $disk.freespace)/4/1024;$megabytesfree = ($disk.size - $disk.freespace)/4/1024/1024;$gigabytesfree = ($disk.size - $disk.freespace)/4/1024/1024/1024;if ($gigabytesfree -le 121) {{$result = [Microsoft.VisualBasic.Interaction]::MsgBox('C: Drive is LOW! As per IT Standard maintain min. 5GB free space to keep system STABLE with Updates. System will be disconnected from network considering UNSTABLE. Contact IT HelpDesk.','OKOnly,SystemModal,Critical', 'Compliance ALERT!!!');$result;}
Just to throw something into the mix, how about a fixlet detecting the low disk space then use the Messages tab in the action settings to display a message to the logged in user? I believe you can still use this with an empty action.
We used to do it that way… and I remember why. It not only give the impression of an action to take, but also, if left up, can prevent real actions from processing.
Good point. With that, said would using “run” be more appropriate than “wait” so the action isn’t waiting for the end user to click the OK button for the action to finish?
I used your code from the post and it ran ok for me.
