I have a script that runs an executable from System32. On Windows 7 64-bit systems it appears to be attempting to run from C:\Windows\SysWOW64, where all of the 32-bit versions of the binaries are kept. The particular command I am attempting to run is only in the 64-bit folder (C:\Windows\System32).

I was asking around the genius bar at the Konference last week and someone mentioned using the variables for the directory, so I tried this but I did not see any for the system32 directory that were specific to a particular OS architecture. The only one I saw were $(KACE_SYS_DIR) and $(KBOX_SYS_DIR) and from my testing, both of those appear to be looking at the 32-bit folder.

Current Agent version is 5.3.47657
Current K1000 version is 5.3.45497

Any ideas on how to get this to work under both 32 and 64 bit machines?
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


So if you specify c:\Windows\System32 on the x64 PC it tries to find the exe in SysWOW64?

Answered 11/22/2011 by: cmccracken
Orange Senior Belt

Please log in to comment
In a 32-bit environment like the KBOX agent, you generally can't "see" the 64-bit parts of the operating system, except...

the 64-bit System32 directory can be referred to as c:\windows\sysnative

In a 64-bit environment, that placeholder "sysnative" is meaningless. Sande
Answered 11/22/2011 by: snissen
Fourth Degree Green Belt

Please log in to comment
ncsutmf what exactly are you trying to do?

A little more detail might help us figure out an answer.
Answered 11/23/2011 by: dchristian
Red Belt

Please log in to comment
snissen: C:\Windows\sysnative works in 64-bit, but does not on 32-bit machines, but I think with the appropriate verify and remediation steps I think I can build something that works for both.

dchristian: We have times where we need to update the computer's group effective group membership without rebooting, and because the effective group membership is stored in the kerberos credentials that the machine gets when it logs in to the computer object account in the domain, in order to do so we have to destroy the credentials and then get them again. Destroying them is done with "klist.exe purge" running as system, and klist.exe is not in the SYSWOW64 folder. We then run "gpupdate.exe /target:computer /force" as system, which causes the machine to re-authenticate with the computer object account.
Answered 11/29/2011 by: ncsutmf
Second Degree Green Belt

Please log in to comment

Have you tried running the commands as a shell script.

It should emulate running the commands from a command window.
klist.exe purge
gpupdate.exe /target:computer /force

Just make sure you change the script name to script.bat instead of script.sh
Answered 12/01/2011 by: dchristian
Red Belt

Please log in to comment