I've been trying(fruitlessly) to use a KACE 'scripted installation' in my k1000 appliance to copy certain DLL and OCX files to the System32 and SysWOW64 folders simultaneously and register these files.
I've uploaded a single zipped folder containing the script(that should do the copying) and the DLL and OCX files, as a dependency in KACE.
The "On success" portion in KACE says it should "Launch a program" which i've chosen to be the .bat file from the dependency directory "$(KACE_DEPENDECY_DIR)".
When I hit "Run now", it completes with no errors, but the files haven't been copied into either directory(and hence not registered either).
The files(DLL, OCX and .bat) do appear in the local dependency directory in "C:\Program Data..\..\..\.." after the script is run, though. But it isn't doing what it's supposed to do(which is, appearing in the System32 and SysWOW64 folders and proceeding to get registered).
I read somewhere that adding "start /wait" before the xcopy command could help with the copy process. But including that in the script didn't change anything for me and provided the same results as above. I have also tried the "Unzip a file" option from the "On success" portion and chosen to unzip it into the System32 and SysWOW64 directories and again the script runs and downloads the dependencies into the "C:\Program Data..\..\..\.." folder but not into the folders that I've chosen them to be unzipped into, and that's as far as it has always gone.
What am I doing wrong? If I don't prefer to use the "file sync" option in KACE, how do I go about getting this to actually work for me?
The script that I'm using in the batch file is:



cd /d %~dp0

for %%i in ("C:\Windows\System32","C:\Windows\SysWOW64") do copy /Y /V "dmimage_alt.dll" "%%i\"

for %%i in ("C:\Windows\System32","C:\Windows\SysWOW64") do copy /Y /V "OBXAltViewer.ocx" "%%i\"

for %%i in ("C:\Windows\System32","C:\Windows\SysWOW64") do copy /Y /V "OBXAltViewer.inf" "%%i\"

for /f %%i in ("C:\Windows\System32\dmimage_alt.dll","C:\Windows\SysWOW64\dmimage_alt.dll") do regsvr32 /s %%i

for /f %%i in ("C:\Windows\System32\OBXAltViewer.ocx","C:\Windows\SysWOW64\OBXAltViewer.ocx") do regsvr32 /s %%i

This is a great community, with a lot of immensely smart and helpful people. 

Thanks in advance for any insight into my issue here, and for any pointers in the right direction!

0 Comments   [ - ] Hide Comments


Please log in to comment

Answer this question or Comment on this question for clarity


AFAIK there are two version of regsvr32, a 32bit version and a 64bit version. If you start the command prompt / batch file in a 32bit process, it should use the correct one (32bit).
I must also ask, why are you copying them to both the 64bit AND 32bit file system. If they are 32bit then just copying them to the 32bit file system should suffice (SysWOW64), and using the 32bit regsvr32 to register them...

Answered 10/06/2016 by: Pressanykey
Red Belt

Please log in to comment
This content is currently hidden from public view.
Reason: Removed by member request
For more information, visit our FAQ's.


Thanks for the response, Phil. But this is for many PCs which include both 32 and 64 bit machines. I'm more concerned about getting these files to show up in the appropriate system directories(depending on whether it is a 32 or 64 bit machine), than registering them. Since the first part itself isn't working as it should, I didn't expect the registration part to function anyway. Attached is a screenshot of the second iteration of this script where it is told to unzip the zipped DLL folder into the System32/SysWOW64 folders, and then "Run a batch file..." that I created within KACE itself and appears as another dependency[with a KACE-assigned name].

Thanks again for your question.

Answered 10/06/2016 by: stancherry
White Belt

  • Hi,
    then just write your batch file as if it was running on a 32bit system (%windir%\system32) and ensure that the batch file is called ina 32bit context. Then you don't need to worry about the bitness of the system as the OS will sort that out for you (re-direction)
Please log in to comment
There's little point in registering OCXs for 64-bit as there are resolutely 32-bit...
Answered 10/07/2016 by: VBScab
Red Belt

  • Hi Ian, fair one regarding OCX's, but metaphorically I meant ActiveX / COM in general. As is, the alternative "registry free" is still too complex for none .Net resources so I expect that we will still be dealing with this for many years to come... (I've heard some people stating that COM is dead... I just ask myself if they have ever had a look at the DirectX / WinRT API's....)

Please log in to comment
Admin Script Editor
Admin Script Editor is an integrated scripting environment available free here at ITNinja