1

I am in the process of upgrading some dated VBScript automation for Powershell on one of our servers running Windows Server 2012 R2. Currently, I'm working on replacing a script that requires the creation of a COM object from a third-party 32-bit DLL. First, I installed the third-party program that contains the DLL; it installed fine and runs correctly. I then attempted to create the COM object in Powershell, which failed and gave me back the error "80040154 Class Not Registered" with a CLSID that was NOT all zeros.

I attempted to troubleshoot and found that it created the COM object if I used the Powershell (x86). I figured then that maybe that the DLL was not registered for 64 bit Powershell, and used sysWoW64/regsvr32 to register the DLL. This did not solve the issue, so I also registered it with system32/regsvr32 which also did not solve it.

I then turned to Google and found this solution from 2009: Solution Link. This actually did solve the problem, allowing the COM object to be created and used in 64-bit Powershell. However, this is very much a hack and having to edit the registry by hand isn't the most maintainable solution.

So, my question is this: how should I properly set up a 32-bit DLL to run with 64-bit Powershell? What is the "proper" way of performing the above solution?

RBeaulieu
  • 11
  • 1
  • 2
  • GPP and push that registry setting ? Its easy to do – yagmoth555 Apr 11 '17 at 17:07
  • Unfortunately, I don't think I can do that for a number of reasons. Firstly, I don't believe that I have AD access (I assume you need AD access to work with Group Policies). Secondly, I'm sure the people that I work under will be wondering why a VBScript to Powershell change requires a group policy solution for only 2 servers (increased complexity). Third, it still means I'm using a hack solution, which they will also question... it's one of those solutions that no one understands why it works or is necessary, and could be lost on next refresh even if I document it. – RBeaulieu Apr 11 '17 at 17:36
  • Well, it's a hack because your third party didnt provided you 64 bit DLL. Use another product ? – yagmoth555 Apr 11 '17 at 17:47
  • You're not wrong, but I don't think I get much say in what product we get to use. I know there's a newer version of the third-party product (at least according to the vendors site), which I also know they would support, but I don't get to decide whether we overhaul something. To give you an idea, the alternative to swapping out this specific VBScript would be to modify and recompile, not replace, a VB6 coded application. I wouldn't mind attempting to recode it from scratch, but I don't think anyone in our group, including myself, has the time to deal with that. – RBeaulieu Apr 11 '17 at 18:01

1 Answers1

1

If you're stuck with that kind of DLL, you'll probably have the best luck if you run the script with the 32 bit version of Powershell or VBscript from the SysWow64 path. It may seem backwards, but the 64 bit EXE's are located in System32.

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
C:\Windows\SysWOW64\cscript.exe
Clayton
  • 4,483
  • 16
  • 24
  • I did not want to complicate the question so I omitted this information, but the Powershell script would be run from a SQL Server 2012 job. Unfortunately, it doesn't seem to give you a choice of whether to use 32-bit or 64-bit Powershell instance. Of course, I could call a new 32-bit Powershell instance from within a 64-bit Powershell instance, but I'd personally like to avoid that if possible. To be honest, I might be chasing after a unicorn here, trying to get everything to run within all these constraints. Failing that, this might be the best option if nothing else presents itself. – RBeaulieu Apr 11 '17 at 18:25