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?
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)
Please log in to answer
Posted by:
snissen
13 years ago
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
the 64-bit System32 directory can be referred to as c:\windows\sysnative
In a 64-bit environment, that placeholder "sysnative" is meaningless. Sande
Comments:
-
the "sysnative" placeholder worked for me, had to delete a single file with a kace script in Win11 from a subfolder in system32, using
"del c:\windows\sysnative\subfolder\xyz.exe" instead of "del c:\windows\system32\subfolder\xyz.exe"
worked fine. - ChristianMRZ 7 months ago
Posted by:
cmccracken
13 years ago
So if you specify c:\Windows\System32 on the x64 PC it tries to find the exe in SysWOW64?
Casey
Casey
Posted by:
dchristian
13 years ago
ncsutmf what exactly are you trying to do?
A little more detail might help us figure out an answer.
A little more detail might help us figure out an answer.
Posted by:
ncsutmf
13 years ago
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.
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
13 years ago
ncsutmf,
Have you tried running the commands as a shell script.
It should emulate running the commands from a command window.
Just make sure you change the script name to script.bat instead of script.sh
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 /forceJust 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.