I'm trying to deploy and execute a vbscript published by Microsoft (offscrub10.vbs) for the purpose of removing all traces of Office 2010 from a system. When I push the script to a 64-bit system, the 32-bit cscript is being called to run it. This is causing the script to fail when trying to validate registry permissions.
I can replicate the error myself when trying to manually run the script from either the system or local admin account and explicitly calling the 32-bit cscript; conversely if I just run "cscript" by itself then the 64-bit version picks up and the script works fine. I also have ProcMon logs that show the 64-bit cscript being called in the command line but have the 32-bit version listed in the path to the process executable.
How do I get around this? There's obviously some logic in the script that doesn't like being run in 32-bit on a 64-bit PC, but this is a Microsoft script and I don't want to tinker with it and break something else.
I'm using KACE for deployment, which seems to be the issue because the local agent is a 32-bit process. I've configured the deploy script to call 64-bit cscript explicitly, wrapped it in a batch file, a PowerShell script, and tried calling 64-bit cmd.exe to run cscript, but then cmd.exe defaults to 32-bit and we're back to the drawing board.
Obviously the ideal place to fix this would be in the vbscript itself or kbox, and I'm working this from the KACE angle as well, but I'm trying to cover all my bases here.
cscript
is called by doing\cscript.exe
which is going to be dependent upon the process that starts references it, so replace\cscript.exe
with the full path to the 64-bit version ofcscript.exe
that will guarantee the script will run with access to 64-bit registry keys.SysNative
or upgrade all to the same 64-bit architecture