Failed Action Command - Executing a Batch File (.BAT)

(imported topic written by Matt.Johnson)

New Day - New Challange:

I am trying to write a simple action to:

  1. Distribute a small batch file to a workstation

  2. Execute that batch file as SYSTEM

So my relevance code works, Now I am working on the action. I have used the following actions to try and complete the task:

download http://SERVER.FQD.DOM:PORT/Uploads/0eede14c0b20352b1c726d415d9ebc898281de3c/TurnOnBIT.bat.tmp

continue if {(size of it = 91 AND sha1 of it = “0eede14c0b20352b1c726d415d9ebc898281de3c”) of file “TurnOnBIT.bat.tmp” of folder “__Download”}

extract TurnOnBIT.bat.tmp

wait “{pathname of system folder & “\cmd.exe”}” /Q /C "{(pathname of client folder of current site) & “__Download\TurnOnBIT.bat”}

(NOTE I changed the server name for security)

It errors out on the WAIT line (5) - Stating that validation failed (Relevance clauses must be surrounded by { and } guards. Now this code was generated by the Software Distrbution Wizzard, and the line does seem to be surrounded by guards. So why is this failing to execute?

(imported comment written by SystemAdmin)

I wonder if it is the missing quotes

Yours:

wait “{pathname of system folder & “\cmd.exe”}” /Q /C "{(pathname of client folder of current site) & “__Download\TurnOnBIT.bat”}

With extra quote at the end:

wait “{pathname of system folder & “\cmd.exe”}” /Q /C “{(pathname of client folder of current site) & “__Download\TurnOnBIT.bat”}”

Quick glance :slight_smile:

Martin Carnegie

Gulf Breeze Software Partners

http://www.gulfsoft.com

(imported comment written by Matt.Johnson)

Thanks Martin. I’m sorry to say it still shows Syntax Error on that line.

(imported comment written by SystemAdmin)

Hi Matt,

I assume you are trying to test the action script command in the fixlet debugger. The (pathname of client folder of current site) embedded relevance in your action script cannot be evaluated by the debugger which results in the Syntax error you see. It should work fine when taking actions from the console.

(imported comment written by Matt.Johnson)

Thank you Mayank.

I tried the action and it shows failed. I will try to find the logs of what happend. However any other thoughts are appreciated.

(imported comment written by Matt.Johnson)

I attached part of the log for the BES client on the device.(modified the server for security. Any insight on the failure, and how to resolution is greatly appreciated.

1 Like

(imported comment written by Matt.Johnson)

More information:

It seems most of the process runs as intended. However, when trying to execute MANAGE-BDE.EXE as system it errors out stating that manage-bde.exe is not a recognized interal or external command…

It is present in C:\windows\System32\ and I can do it from an admin prompt. Where is the failure.

(imported comment written by Matt.Johnson)

I found a solution in the end.

If you’re using BigFix to execute the batch file, and you are calling on a function in System32 you need to specify the call via the following:

%windir%\sysnative\APPLICATION

For example, in my case the solution was to use:

%windir%\sysnative\Manage-BDE.exe

(imported comment written by ortalbeny12345654321)

Hello,

I’m facing the same problem that you had, and it still didn’t work even when i add the via:

%windir%\system32\net.exe

With this error:

cmd file is not recognized as an internal or external command,

operable program or batch file.

Return code: 9009

what you suggest?

(imported comment written by Matt.Johnson)

I am not sure which version of Windows you’re running, but ensure that the file is in the System32 directory. Error 9009 (according to Microsoft) likely means the executable “net.exe” was not found in the specified location.

If you’re sure it’s there, and accessible from NT AUTHROITY\SYSTEM (or service account you specified for BigFix), I would write the action as a batch file… I am not sure that pointers such as %windir% will work being executed by the DOS action command In the context of a .BAT file. You may want to try it providing the full path, if your environment is uniform enough to allow it. Here are a few examples

Here’s an example I’ve used in the past:

Using the WAIT command to execute a BAT

wait C:\APPS\TPM\bigfixstart.bat

If this doesn’t answer your question, please post with the version of windows you’re applying this to, and maybe an overview of what your batch is doing.

Hope this helps,

Matt

(imported comment written by Matt.Johnson)

2 simple fixes I’ve also missed when I started authoring BigFix actions were:

  1. Make sure anything using that may have a space in the name, or is literal in nature, is encapsulated in quotes (If in doubt, quote it out).

  2. The Fixlet Debugger will run in local mode by default. This means it’s executing actions using local credentials (or supplied during the RunAs). If a failure is occurring, try testing with the local BigFix Client by selecting Debug > Evaluate Using > Local Client Evaluator. While this takes a little longer to evaluate, it’s running it through the true client on the local device, not just the Debugger application.

Matt

(imported comment written by ortalbeny12345654321)

Hi Matt,

Thanks for your answer.

What the command wait will do?

We have version win7, winxp, win8

The station i’m checking is win7 ( there some stations that works an some don’t)

On the action i select that the action will run with the current user.

I have also added to the task the exe file (net.exe)

And then i run the command (in a batch file)

I checked that the command is ok, i also run it and it runs ok.

i tried to run the batch on the remote computer by runas - and with other user name, and it also works fine.

Any suggestions?

Thanks,

Ortal

(imported comment written by Matt.Johnson)

Hi Ortal,

The command wait C:\APPS\TPM\bigfixstart.bat will launch “bigfixstart.bat” from C:\APPS\TPM, and wait for it to close before continuing. It’s important to note the WAIT command can be problematic. If a step fails to end WAIT could leave an action hanging.

I’ve used TEM (BigFix) with both Windows 7 and 8. I am curious why you’re running as the local user. Do your users have local admin rights on this Windows box? From what I understand, out of the box TEM will run actions as NT AUTHORITY\SYSTEM which should have local admin rights.

I’d suggest trying to run it without selecting Run As Current User, and if using RunAsCurrentUser.exe - exclude it. Remember that when you’re issuing remote commands you’re logged in as a user that has specific rights. When TEM executes an action it will act as the SYSTEM account which has different rights on the local box.

If you like, you can post your action in a reply and I can give more feedback. If you have batch file, paste post that code as well (redacting any confidential information)

Trust me, this gets easier as you go. The community in this forum is amazing at helping out.

Matt C. Johnson

Sr. Technical User Support Analyst | Medtronic, Inc.

(imported comment written by ortalbeny12345654321)

Hi,

I want to add the users to remote desktop users, everytime they are logged in to the station.

that’s why the action is runing with current user.

thats what i’m runing in the batch:

%windir%\System32\net.exe localgroup “Remote Desktop Users” “%userdomain%%username%” /add

it’s very strange that in some stations it works fine (the same version)

i also checked that the user thats runing the batch have privilage. (works fine in cmd)

thanks again :slight_smile:

ortal

(imported comment written by ortalbeny12345654321)

Hi,

I tried to uninstall and install the client , and when i deploy the task on that station it finally worked!!

But u
nfortunately
there are more 500 stations that i need to deploy that task.

I tried to use the tool of bigfix “BESClientDeploy” on some station, but it still didn’t work.

did you find something? do you have any ideas?

thanks,

Ortal

(imported comment written by MattPeterson)

If I’m understanding what your looking to accomplish then there is no reason to run as the current user. Running as the current user adds another layer of unnessisary complexity. I would suggest the following:

Fixlet Relevance:

exist current user and exists member whose (it as string as lowercase contains (name of current user)) of local group “Remote Desktop Users”

Action Script:

waithidden cmd.exe /c net.exe localgroup “Remote Desktop users” {(value “LastLoggedOnUser” of (key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI” of native registry) as string)} /add

Another consideration is that net.exe is limited to 20 characters (I believe this includes the domain name), so if you have any long domain\username combos this will fail. So instead I would suggest the following which will create a .vbs file to handle this and get around the 20 character limitation.

parameter “User” = “{(value “LastLoggedOnUser” of (key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI” of native registry) as string)}”

createfile until ENDOFSCRIPT

Dim localGroupName, ADUserName, strComputer, objLocalGroup, objADUser

strComputer = “.”

‘’'Parse the command line arguments (if it exists)

If Wscript.Arguments.Count < 2 then

Err.Raise 1, "Invalid argument", "Missing parameters"

Else

ADUserName = Wscript.Arguments.Item(0)


localGroupName = Wscript.Arguments.Item(1)

End If

ADUserName = REPLACE(ADUserName, “”, “/”)

Set objLocalGroup = GetObject(“WinNT://” & strComputer & “/” & localGroupName & “,group”)

Set objUser = GetObject(“WinNT://” & ADUserName & “,user”)

objLocalGroup.Add(objUser.ADsPath)

wscript.echo "Successfully added " & ADUserName & " to " & localGroupName

ENDOFSCRIPT

delete AddUserToLocalGroup.vbs

copy __createfile AddUserToLocalGroup.vbs

waithidden cscript.exe AddUserToLocalGroup.vbs “{parameter “User”}” “Remote Desktop Users”

(imported comment written by ortalbeny12345654321)

Hi,

Thank you for your response.

I’m not sure i understand what you wrote.

On the Fixlet Relevance: it check if the current user is a member of the local group?

On the action Script:is it suppose to be on a batch file? or is it a relevance too? beacause on the cmd it dosen’t recognize the commands, and when i try to debug it on the relevance debgger it didn’t recongnize the commands too.

Is it mean that the net.exe is limited for the all expression
domain-name\username?

Thanks,

Ortal

(imported comment written by ortalbeny12345654321)

Hi,

It now works!!!

But now i have another problem, there are users that aren’t member of power users or administrators, and they get access denied when i deploy the action.

Is there a way to run action in bigfix that will run with another user permissions?

Thanks,

Ortal

(imported comment written by MattPeterson)

Ortal,

Yes the fixlet relevance I wrote will check for the existance of “current user”, and for that user not to already be in the remote desktop users group. meaning someone will need to be logged into the computer, and that user ID is not already in the remote desktop users group for the task to be applicable. This will allow you to target only computers that need action, this also can help you determine how many computers are out of compliance by looking at how many computers are applicable to this task.

The action script I included was bigfix action script. It should work using the action tab in the fixlet debugger. I’ve uploaded the fixlet (using the vbs method) to bigfix.me. You should be able to download this fixlet and use it as is.

net.exe is limited to 20 characters
http://support.microsoft.com/kb/324639
. As I understand if your domain\username string is over 20 characters net.exe will not work.

(imported comment written by JasonWalker)

Sorry if I’m a bit late to the party, but I didn’t see this covered earlier. There was some confusion over using binaries in \windows\system32. That’s because BigFix is a 32-bit client, so by default its actions use the 32-bit redirection, and it actually sees \windows\syswow64 as its system32 folder. Similar, Registry calls for HKLM\Software get redirected to HKLM\Software\Wow6432Node.

You can avoid this in both cases by putting “action uses wow64 redirection false” in your Action Script, anywhere before you make your calls to system32 or HKLM\Software.