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?