The more... "mature" installers don't normally use an ActiveX library's DLLSelfRegister entrypoint for registration (which is what regsvr32 calls). They update the registry according to rules in the installer database through "Associations" mappings (which can include Document Type, MIME Type, COM Object, and Type Library associations).
They also run in a privileged installer context normally.
Even so, I can't see why you couldn't still invoke self registration using regsvr32. I was pretty sure the only requirement was to run elevated if you wanted the component registered in HKLM instead of HKCU.
When you say you are "running the command prompt under administrator" what do you mean? Just running under an admin account isn't good enough. The usual recommendation for this is to elevate a command prompt and then run regsvr32 from there.
If you're already doing this I'm not sure what the problem might be.
It isn't considered good practice to manually register components. Even invoking DLLSelfRegister within an installer is considered "bad form" because it defeats rollback and doesn't permit advertising:
Registering installed COM objects in a manner compliant with Windows installer requirements makes it possible for your users to rollback COM object installation and registration if the product installation fails. Windows installer registration of COM objects also facilitates advertising COM objects on the target machine. For these reasons, registering COM objects with the Windows installer is recommended over self-registering COM objects at installation. (Self-registering installed COM objects was a common strategy in traditional scripted setup procedures, but the advent of the Windows installer overrides the advantages of self-registration.)
That advice dates back to 2000 if not 1999.
Sometimes though "you gotta do what you gotta do."
If you don't have to support OSs prior to Win XP there is the registration-free COM option as well.
