We are doing some MSOffice development and our dlls are adding the entry HKCU\Software\Microsoft\Office\Word\Addins during self-registration. We also have a file installed to C:\Documents and Settings\[username]\Application Data\Microsoft\Word\STARTUP.
We set our dlls to install "extract at build", install on Terminal Services server as admin, then log in to a session as restricted user. We were hoping that the user- specific part of the install (mentioned above) would be "repaired" by MSI for the restricted user's session. What we are seeing is an MSI dialog that quickly pops up and goes away. If the user attempts to use the application, it happens again and again - endlessly.
No matter how many times the restricted user accesses the the application during a login session, MSI gives us a dialog that it is installing. We assumed that this is to repair the account specific registry entries and file, but what we are seeing is not what we expect. If we change the dll registration to "self-register" this problem goes away completely.
Why would this keep happening over and over? When we look at the restricted user's registry hive, entries are still missing. Is MSI's repair temporary? What is it doing?
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.
Basic MSI and Terminal Services
Started by
dGabay
, Jan 12 2004 23:11
8 replies to this topic
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 13 January 2004 - 00:06
Some info here: http://forum.install...?showtopic=9137
Regards
-Stein Åsmul
-Stein Åsmul
Zweitze
-
- Full Members
- 522 posts
Posted 13 January 2004 - 10:14
The InstallShield function "Extract at build" only attempts to detect CLSIDs, ProgIDs, file extensions etc. registered by the DLL. Basically it crawls itself through HKCR, looking for everything that can be matched to the DLL.
It cannot find any other registry keys (or system changes) that this particular DLL did. So if you wrote a DLL with a special DllRegisterServer, that copies a file, starts a service, and writes three registry entries, then none of these actions will be detected by "Extract at build".
Therefore, you should at your HKCU registry key yourself. But... you cannot rely on repair in this case. Windows Installer starts repairing when a program accesses/reads a key path (eg. a registry key in HKCU).
But in this case, the program is Word. Word does not attempt to access your HKCU registry key, it just enumerates HKCU\Software\Microsoft\Office\Word\Addins.
In this particular case, I recommend to write the key HKLM\Software\Microsoft\Office\Word\Addins. By registering in HKLM, all users will get the addin. As a side effect, these users cannot see this addin in their Com-Addins dialog, and therefore they cannot remove it, or change its loadbehavior.
If you want to support single-user installations (ALLUSERS empty) and machine installations (ALLUSERS=1 or 2), you should register the key in HKEY_SELECTABLE.
As an alternative, you can use self-register for this particular problem. This method has quite a few problems itself, esp. with advertizing. But advertizing does not work in your case anyway, just because Word enumerates all subkeys, instead of reading your registry key. (Remember to turn off "install on first use").
It cannot find any other registry keys (or system changes) that this particular DLL did. So if you wrote a DLL with a special DllRegisterServer, that copies a file, starts a service, and writes three registry entries, then none of these actions will be detected by "Extract at build".
Therefore, you should at your HKCU registry key yourself. But... you cannot rely on repair in this case. Windows Installer starts repairing when a program accesses/reads a key path (eg. a registry key in HKCU).
But in this case, the program is Word. Word does not attempt to access your HKCU registry key, it just enumerates HKCU\Software\Microsoft\Office\Word\Addins.
In this particular case, I recommend to write the key HKLM\Software\Microsoft\Office\Word\Addins. By registering in HKLM, all users will get the addin. As a side effect, these users cannot see this addin in their Com-Addins dialog, and therefore they cannot remove it, or change its loadbehavior.
If you want to support single-user installations (ALLUSERS empty) and machine installations (ALLUSERS=1 or 2), you should register the key in HKEY_SELECTABLE.
As an alternative, you can use self-register for this particular problem. This method has quite a few problems itself, esp. with advertizing. But advertizing does not work in your case anyway, just because Word enumerates all subkeys, instead of reading your registry key. (Remember to turn off "install on first use").
dGabay
-
- Members
- 22 posts
Posted 14 January 2004 - 06:11
Thanks for all your help. This gives us a lot to think about.
So your recommendation is either to A: make the HKCU entries for each user without relying on self-repair, or B: to write HKLM instead.
Our dlls are written in Visual Basic 6.0 and we aren't sure we can change the way they register to use HKLM instead of HKCU. I did try putting in the HKLM entries with my install. This does get the dlls loaded in Word, but I still have an issue with MSI
So your recommendation is either to A: make the HKCU entries for each user without relying on self-repair, or B: to write HKLM instead.
Our dlls are written in Visual Basic 6.0 and we aren't sure we can change the way they register to use HKLM instead of HKCU. I did try putting in the HKLM entries with my install. This does get the dlls loaded in Word, but I still have an issue with MSI
dGabay
-
- Members
- 22 posts
Posted 14 January 2004 - 06:15
oops sorry. I still have an issue with MSI repairing all the time. How could we put the HKCU entries in for each user when our dlls aren't getting loaded for that user?
Zweitze
-
- Full Members
- 522 posts
Posted 14 January 2004 - 09:45
Well, I use the following rules:
1. Setup NEVER tries to install HKCU keys, only HKLM.
2. The installed software must be able to deal with missing HKCU keys: it must use proper defaults in that case. If the software needs info from the installer (eg. initial installation paths), it should read that info from HKLM and copy that to HKCU.
3. The installed software should access the HKLM keys with R/O access (write access is not guaranteed).
One exception to rule 1. is support of single user installs (ALLUSERS empty). In that case, usage of key HKEY_SELECTABLE is preferred.
The registration method of your VB DLL is not relevant, you have to add registry keys in your setup project anyway. Regarding the Word addin registry key: Use HKEY_SELECTABLE.
1. Setup NEVER tries to install HKCU keys, only HKLM.
2. The installed software must be able to deal with missing HKCU keys: it must use proper defaults in that case. If the software needs info from the installer (eg. initial installation paths), it should read that info from HKLM and copy that to HKCU.
3. The installed software should access the HKLM keys with R/O access (write access is not guaranteed).
One exception to rule 1. is support of single user installs (ALLUSERS empty). In that case, usage of key HKEY_SELECTABLE is preferred.
The registration method of your VB DLL is not relevant, you have to add registry keys in your setup project anyway. Regarding the Word addin registry key: Use HKEY_SELECTABLE.
sjimmerson
-
- Members
- 36 posts
Posted 14 January 2004 - 17:43
DevStudio 9 is pulling the HKCU registry entries from the Office COM Add-in DLLs when using "Extract at Build".
It is also my understanding that Terminal Services will copy HKCU registry entries to each user profile when that user logs in as long as those registry entries were created while Terminal Services was running in install mode. In this case I would expect the Office Add-in registry entries under HKCU would be copied to each user profile.
It is also my understanding that Terminal Services will copy HKCU registry entries to each user profile when that user logs in as long as those registry entries were created while Terminal Services was running in install mode. In this case I would expect the Office Add-in registry entries under HKCU would be copied to each user profile.
dGabay
-
- Members
- 22 posts
Posted 14 January 2004 - 18:19
Thanks again for your responses. I've not violated rule 1. My install does not have any HKCU registry entries. I'm using only HKLM and have allusers set to 1, with no way for the user to install per-user. We don't need to support per-user installs.
The reason why the registration of our dlls may be relevant, is the dlls themselves are writing to HKCU. They each put an entry in HKCU\Software\Microsoft\Office\Word\Addins during self-registration. In other words, if I register the dlls by hand with regsvr32 to a clean machine, the HKCU entries are made. If I unregister using regsvr32 /u, these entries are deleted. This violates rule 2. Don't know how to deal with this. Rule 3 - I'm not sure, need to check on this.
We do have a file in the user profile as I mentioned in the first post, but we may be able to move it.
I'm learning a lot, but no solution yet. Neither Terminal Services nor MSI is properly compensating for these issues for a restricted user logging in to the Terminal Services session. Any further suggests welcome.
The reason why the registration of our dlls may be relevant, is the dlls themselves are writing to HKCU. They each put an entry in HKCU\Software\Microsoft\Office\Word\Addins during self-registration. In other words, if I register the dlls by hand with regsvr32 to a clean machine, the HKCU entries are made. If I unregister using regsvr32 /u, these entries are deleted. This violates rule 2. Don't know how to deal with this. Rule 3 - I'm not sure, need to check on this.
We do have a file in the user profile as I mentioned in the first post, but we may be able to move it.
I'm learning a lot, but no solution yet. Neither Terminal Services nor MSI is properly compensating for these issues for a restricted user logging in to the Terminal Services session. Any further suggests welcome.
Zweitze
-
- Full Members
- 522 posts
Posted 15 January 2004 - 10:15
Well, Extract at build obviously misses a key. There's only one thing to do about this: add that key yourself.
Further, do NOT add a HKCU key, but HKLM or HKEY_SELECTABLE. It works. Consider the VB behviour to add a key to HKCU a bug in VB.
When you do so, you should notice that unregistering your DLL will force a repair of your software the next time you start Word. The repair will extract the registration of your DLL again.
Further, do NOT add a HKCU key, but HKLM or HKEY_SELECTABLE. It works. Consider the VB behviour to add a key to HKCU a bug in VB.
When you do so, you should notice that unregistering your DLL will force a repair of your software the next time you start Word. The repair will extract the registration of your DLL again.