3 replies to this topic

[etippelt]

We are packaging for Windows 2000. The HKCU entries are contained in a separate component. No problem when installing to the Administrator account from a network copy of the msi. The ALLUSERS property is set to 1.  However, when a new user logs on, the msi repair process is launched to install the missing HKCU entries, but instead of running from the locally cached .msi in c:\winnt\installer, it tries to access the network copy of the msi. Since only registry updates are involved, how can we stop the msi installer trying to access the original source location of the msi. ??

[DarrenHale]

Sorry for not actually being any help for your question but you might be able to help with mine.  You seem to be doing exactly what I'm trying to do.  I have an app which creates HKCU entries and whenever a new user logs on I want the installer to create these entries for the new user.  What do I need to do within the installation to get this to happen?  Thanks in advance for any help.

[etippelt]

Depends on which packaging tool you are using. We use Wise for Windows Installer here, and the capture places all the HKCU entries into a separate component called current user. General advice is to keep all HKCU entries in a separate component, and a separate feature that installs for all users. In our situation, where the original MSI is network based, a new user logging on causes the system to try to access the network copy, even though there is a local copy of the msi in the c:\winnt\installer folder, and no new files need to be installed. However, just yesterday, after a lot of testing, I found that the new windows installer engine - v2.0 - fixes this problem which also affected the patch process - Technet Q268800 refers

[Glytzhkof]

I assume the HKCU component is also in its own feature? I believe repair takes place at the feature level, and hence if the feature installs other components that require file installation you could depend on the source installation folder again.