David, can you provide more detail on this, such as OS and browser version you are trying to authenticate to or maybe a screenshot.

Class not registered is a catch-all error that usually indicates that the ALM client-side libraries have not been registered on the local machine. Since you're using a much older version of ALM, you'll have to use either Internet Explorer or MS-Edge in IE mode.  When clicking on the Desktop Client link, it should automatically start downloading and registering the client-side components.

Alternately if you go to the ALM main URL and click the Tools -> Client Registration link you'll be able to register the client-side libraries on your PC.  You will need sufficient permissions on the local machine to perform that operation.

Thank you for the quick response....

I'm launching the client:

I put in the server details, hit Go, and get this:

I'm told a coworker of mine might have a solution involving a more updated version.  His was 12.55 and appeared to start loading the client-side components and then he runs into an access issue (we're not allowed to be admins on our machines).  I think one more session with our techs and they'll get this solved.  

I'll be pursuing that option myself in the next couple days.

Thanks David, keep us posted.

I am now having the exact same issue with the exact same circumstances.

We are upgrading all of our laptops. Since re-registering our ALM Connectivity Tool and ALM Site Administration on the new laptops we get the same error "2147221164 - Class not registered". Whenever we attempt to remotely log into ALM.

This is occurring on the call to log into ALM using CreateObject("SAClient.SaApi.9").

I see that almost everything looks the same on the new machines as the old machines with one exception, on the old machines the "OTA COM Type Library" is located on C:\ProgramData\HP\ALM-Client\12.60.7.0_952\OTAClient.dll, and now on the the new machines it is located in C:\Program Files (x86)\Common Files\Mercury Interactive\TDAPIClient\OTAClient.dll. I have no idea if this is culprit or not.

The "SAClient Type Library - Apoplication Lifecycle Management Site Administration API" remained in the same location on both old and new laptops at C:\ProgramData\HP\ALM-Client\12.60.7.0_952\SAClient.dll.

I have no idea why we can no longer connect remotely to ALM, why we get this error, or why the locations have changed. Did David Kellogg get this resolved? I need a solution ASAP!

Both Laptops::

OS Name: Microsoft Windows 10 Enterprise

System Type: x64-based PC

We have been doing this solution for many years. We know how to update the ALM Connectivity Tool and ALM Site Administration from ALM onto our machines. But this time we are running into this issue 100% of the time on all new laptops.

Michael,

Are you connecting to ALM with ALM Explorer or Client Launcher.  There may be additional information in the Windows Event Log that could help isolate the problem.  There's a technical note on the Micro Focus marketplace page for ALM Explorer that mentions a potential conflict with Microsoft Visual C++ 2015 redistributable. I know that on some Windows operating systems, Client Launcher wouldn't initialize property because it was missing this prerequisite too.  So maybe the answer lies somewhere in there.

Here's the note from the MicroFocus marketplace page for ALM Explorer:

Note:

ALM Explorer does not support Performance Center windows, such as the Performance Test Designer, Performance Trending, or MyPC. These windows open in a standard Web browser.

If the machine has no internet access, then Microsoft Visual C++ 2015 Redistributable package x86 must be pre-installed manually.

Due to an installer bug, only v14.0.23026 is usable; Newer versions of Microsoft Visual C++ 2015, 2017, or 2019 x86 must be uninstalled first!

The required file is available from Microsoft at download.microsoft.com/.../vc_redist.x86.exe

Newer versions of VC++ can be re-applied after installation is complete.

We have only been using MS-Edge in IE mode since migrating to ALM 12.x. This issue has arisen with the use of our API calls to ALM using TDConnect OTA and SAClient in Visual Basic. This has worked for years through many ALM revisions. Not sure what the new laptop is doing to cause this to fail with the "Class not registered" error. I am not sure what other logs to look into to pinpoint this error.

Since sending my initial issue on this thread I have used the ALM Cleanup tool for 12.60 on my laptop, which has this issue, to no avail. The cleanup appeared to work correctly, downloaded ALM Connectivity and Site Administration Tools, and still received the same error. Everyone with a new laptop has this same issue.

Thank for your quick reply!

Any other things I could consider or try? This is seriously affecting our rollout of new laptops now as we need to get this issue resolved.

Are there any messages in the Windows Event Log, they may give an indication of the error.  I'll also send you a DM privately.

My fix was to add new 64 bit support registry entries for SAClient OTA and TDConnection. Now my visual basic API calls to ALM 12.60 work again from 64-bit MS Access and Excel to ALM 12.60.