/build/static/layout/Breadcrumb_cap_w.png

Script running from 64-bit System32 folder

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   [ + ] Show comments

Answers (5)

Posted by: snissen 12 years ago
Fourth Degree Green Belt
2
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
Posted by: cmccracken 12 years ago
Orange Senior Belt
0
So if you specify c:\Windows\System32 on the x64 PC it tries to find the exe in SysWOW64?

Casey
Posted by: dchristian 12 years ago
Red Belt
0
ncsutmf what exactly are you trying to do?

A little more detail might help us figure out an answer.
Posted by: ncsutmf 12 years ago
Green Belt
0
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.
Posted by: dchristian 12 years ago
Red Belt
0
ncsutmf,

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
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ