1

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.

4
  • 1
    It sounds like the script itself isn't designed to remove the 64-bit installations of office. Why don't you just use the full path to the 64-bit executable when calling the script?
    – Ramhound
    Jan 9, 2015 at 15:31
  • I would say your answer is use something other than KACE to deploy he script. Jan 9, 2015 at 15:31
  • Looking at a previous version of the script it appears that 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 of cscript.exe that will guarantee the script will run with access to 64-bit registry keys.
    – Ramhound
    Jan 9, 2015 at 15:39
  • 32-bit processes are put under File System Redirector and doesn't see the real System32 folder but SysWOW64 instead. Use SysNative or upgrade all to the same 64-bit architecture
    – phuclv
    Oct 27, 2019 at 5:39

1 Answer 1

1

I think the problem you're running into is due to 64-bit Windows having a feature for 32-bit processes called folder redirection. This causes the path to go from %windir%\system32 to %windir%\sysWOW64

There is a workaround but it's been awhile since I've used it. In the full path to call cscript, use this:

%WinDir%\Sysnative

This should allow the 32-bit KACE process to access the files within the system32 directory (cscript in this case).

A bit more info here:

http://support.microsoft.com/kb/942589

Hope that works for you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .