I have two DLLs that are installed which self-register. These DLLs are installed using a deployment manager called NovaDigm Radia which takes the MSI and controls the deployment via an overnight process.
In this scenario the DLLs are installed using the System Account on the PC. This installs fine.
Once the Users logon to the system, the DLLs have not been registered.
When I run the MSI as an administrator and then logon as a user the DLLs register fine, but this scenario will never be used in the real world.
Is there a way I can force the DLLs to register as the user logs on? Is there any VBScript I can run or RegKey I can set?
Your help would be greatly appreciated.
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Dlls not Registering with User logon
Started by
Dan Tamone
, May 25 2004 11:44
4 replies to this topic
Posted 25 May 2004 - 11:49
Very strange. The LocalSystem account should have access to HKLM as far as I know, there is just no user context (no mapped drives, no HKCU, no profile folders etc...) Do these dll's register in HKLM or do they need data in HKCU as well?
Regards
-Stein Åsmul
-Stein Åsmul
Posted 25 May 2004 - 12:39
Thanks for the reply...
They should register as LM as I have set the the ALLUSERS property in the MSI. (its a prerequisit of our company to do so)
I have created a new MSI for the deployment team to see if it was a buggy MSI.
In the past I'm sure I have set a DLL to self-register with no problems, its just this is the first scenario where the MSI is launched via the System account.
They should register as LM as I have set the the ALLUSERS property in the MSI. (its a prerequisit of our company to do so)
I have created a new MSI for the deployment team to see if it was a buggy MSI.
In the past I'm sure I have set a DLL to self-register with no problems, its just this is the first scenario where the MSI is launched via the System account.
Edited by Dan Tamone, 25 May 2004 - 12:39.
Posted 25 May 2004 - 12:51
Any particular reason why you don't use "COM Extract at build"? Provided the COM information is extracted correctly and there is no HKCU or HKLM data that you need to add as part of self-registration the COM Extract is a much better approach. Provided the extraction works correctly that is.
No idea why the LocalSystem account isn't able to register the DLL. Maybe your dll has a dependency that is not in the path for the LocalSystem account and hence self-register fails? Just guessing.
Definitely try COM Extract.
No idea why the LocalSystem account isn't able to register the DLL. Maybe your dll has a dependency that is not in the path for the LocalSystem account and hence self-register fails? Just guessing.
Definitely try COM Extract.
Regards
-Stein Åsmul
-Stein Åsmul
Posted 26 May 2004 - 09:47
I suggest you run NTRegMon (see www.sysinternals.com) while registering by hand, it shows all registry actions performed. Watch out for actions on HKLM and HKCU: you have to add these to the MSI when you use COM extraction.
If you insist on using the SelfReg method, make sure to check its depencies - maybe a DLL is missing.
BTW: Check the inner workings of your deployment tool. If it works by merely advertizing the software, the DLLs are not registered until the installation is completed - typically done by invoking it. In that case, you have to use COM extraction to get it working.
If you insist on using the SelfReg method, make sure to check its depencies - maybe a DLL is missing.
BTW: Check the inner workings of your deployment tool. If it works by merely advertizing the software, the DLLs are not registered until the installation is completed - typically done by invoking it. In that case, you have to use COM extraction to get it working.