Copying DLL and OCX files to System32 and SysWOW64 folders and registering them

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

Answers (3)

Posted by: Pressanykey 4 years ago
Red Belt
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...

Posted by: stancherry 4 years ago
White Belt

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.

  • 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) - Pressanykey 4 years ago
Posted by: anonymous_9363 4 years ago
Red Belt
There's little point in registering OCXs for 64-bit as there are resolutely 32-bit...

  • 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....)

    Phil - Pressanykey 4 years ago
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