Hi all,
I have created a basic msi package. I publish it through the active directory of windows 2003 server (Maximum UI). I was able to see it on the Add New programs in the Add/Remove program applet on an XP client. I can run the installation; however, when I change the default location of the installation. The files will be copied in the default location. Looking in the log file I noticed that the client properties don't get copied to the server properties. It seems like The server installation get its props from the original package. Is this the default behaviour of deploying over the active directory. I am using alot of properties that I change during the interface session that I want them to be available during the server session. What can I do ?
Thank you all
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.
Msi in Active Directory
Started by
InstallDev
, Jul 14 2004 05:35
16 replies to this topic
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 14 July 2004 - 15:32
I'm not sure if that's the problem but you may need to add these properties to the SecureCustomProperties property (and of course make sure the property names are in upper case).
Stefan Krüger
InstallSite.org twitter facebook
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 15 July 2004 - 05:01
Yes, when installing as a restricted user the SecureCustomProperties property defines what public properties are passed from the user interface sequence to the execute sequence. I am almost positive this will fix your problem.
Regards
-Stein Åsmul
-Stein Åsmul
InstallDev
-
- Full Members
- 43 posts
Posted 15 July 2004 - 17:16
Hi,
Thank you very much ..... This is what I missed ..... Also, your advice led me to discover that by setting the EnableUserControl Property to 1. All the public properties will be passed from the interface sequence to the execution sequence.
The only exception I found is the ALLUSERS property. which don't get updated if you publish the package to certain users. So, if we set the ALLUSERS to 1, The ALLUSERS property will always be missing. This maybe because of the active directory forcing the installation to be for certain user not for all of them.
Do you think there is a way to force the installation to be for all users even if we publish it to certain users ?
Thank you very much
Thank you very much ..... This is what I missed ..... Also, your advice led me to discover that by setting the EnableUserControl Property to 1. All the public properties will be passed from the interface sequence to the execution sequence.
The only exception I found is the ALLUSERS property. which don't get updated if you publish the package to certain users. So, if we set the ALLUSERS to 1, The ALLUSERS property will always be missing. This maybe because of the active directory forcing the installation to be for certain user not for all of them.
Do you think there is a way to force the installation to be for all users even if we publish it to certain users ?
Thank you very much
Stefan Krueger
-
- Administrators
- 13,269 posts
InstallSite.org
Posted 15 July 2004 - 21:11
I'm not too familar with AD but I think you will have to assign the software to the machine in this case.
Stefan Krüger
InstallSite.org twitter facebook
InstallDev
-
- Full Members
- 43 posts
Posted 16 July 2004 - 14:57
Hi,
Yes assigning the software to a specific machine will do it. However, we want to allow certain users to choose the machines they want to install the product in. I am not sure if it is possible with the current msi technology.....
Thank you
Yes assigning the software to a specific machine will do it. However, we want to allow certain users to choose the machines they want to install the product in. I am not sure if it is possible with the current msi technology.....
Thank you
Zweitze
-
- Full Members
- 522 posts
Posted 20 July 2004 - 09:02
Well that's what per user installations are intended to do: when you create a policy to install software for a user (not a computer), then that software can be installed on any computer that this user logs on to. However, other users still cannot access that software.
If you have to be complient with AD installations, I suggest you rewrite your setup (and possibly software) to be compatible with per user installations.
If you have to be complient with AD installations, I suggest you rewrite your setup (and possibly software) to be compatible with per user installations.
InstallDev
-
- Full Members
- 43 posts
Posted 20 July 2004 - 13:32
HI,
Thank you for replying,,,,,,
Can you please tell me what changes should I make to enable my setup, application to support per user instalation? Is there any special guide that help us to build per user setup? Currently when I install my application to two different users. It works but when I uninstall the application, it is removed from both (the files and HKLM).
Thank you very much
Thank you for replying,,,,,,
Can you please tell me what changes should I make to enable my setup, application to support per user instalation? Is there any special guide that help us to build per user setup? Currently when I install my application to two different users. It works but when I uninstall the application, it is removed from both (the files and HKLM).
Thank you very much
Zweitze
-
- Full Members
- 522 posts
Posted 21 July 2004 - 09:57
Well, that implies a problem: components are installed twice (you installed for two users) but after the first uninstall, the components are removed.
Check the MSI with Orca. Look out for ICEs that report problems like "the key field of the component is per-user, but the component contains per-machine items" (something like that, it's a long time ago). Split up these compenents. Carefully select the key field of each component.
Another consideration is changing regkeys, install them to HKEY_SELECTABLE (root=-1) instead of HKLM. You need to change the software as well, it should attempt HKLM and HKCU as well. This is not really necessary, but recommended when the keys contains certain setup information: after all the software is installed twice, and may have had different properties.
Other considerations:
- Check the behavior for feature differences between the installs - I think it's possible that different users install different features. I don't allow this on my setups, though.
- Check the behavior for installs to different paths. Again, I don't allow this.
- Check upgrading.
Most of all: run ICEs and take care of all errors and warnings.
Check the MSI with Orca. Look out for ICEs that report problems like "the key field of the component is per-user, but the component contains per-machine items" (something like that, it's a long time ago). Split up these compenents. Carefully select the key field of each component.
Another consideration is changing regkeys, install them to HKEY_SELECTABLE (root=-1) instead of HKLM. You need to change the software as well, it should attempt HKLM and HKCU as well. This is not really necessary, but recommended when the keys contains certain setup information: after all the software is installed twice, and may have had different properties.
Other considerations:
- Check the behavior for feature differences between the installs - I think it's possible that different users install different features. I don't allow this on my setups, though.
- Check the behavior for installs to different paths. Again, I don't allow this.
- Check upgrading.
Most of all: run ICEs and take care of all errors and warnings.
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 21 July 2004 - 12:21
Zweitze, I know what you mean with that error message. It frequently happens if you have a file installed to a user profile and you set the file as a key file (you need to use a registry key in HKCU).
Per user installs should essentially affect COM registration, shortcuts, and ARP (Add/Remove) registration plus any data installed to the userprofile (installing files here is a big NO NO! - it causes problems on terminal server and for people repackaging your setup). http://msdn.microsof...stallations.asp
Per user installs should essentially affect COM registration, shortcuts, and ARP (Add/Remove) registration plus any data installed to the userprofile (installing files here is a big NO NO! - it causes problems on terminal server and for people repackaging your setup). http://msdn.microsof...stallations.asp
Regards
-Stein Åsmul
-Stein Åsmul
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 21 July 2004 - 12:22
I suppose what I tried to say in that last post is to try to install everything per machine and then keep only the registration per user.
Regards
-Stein Åsmul
-Stein Åsmul
Zweitze
-
- Full Members
- 522 posts
Posted 22 July 2004 - 08:28
That won't work if you want to support AD deployment through GPOs in the user profile - this requires installations that support per-user installs.
BTW The validation code is ICE57, see
http://msdn.microsof...setup/ice57.asp
BTW The validation code is ICE57, see
http://msdn.microsof...setup/ice57.asp
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 22 July 2004 - 08:44
Shouldn't the application copy down the files to the user profile from a per machine location? That is what we did, and I think it works ok.
Regards
-Stein Åsmul
-Stein Åsmul
InstallDev
-
- Full Members
- 43 posts
Posted 03 August 2004 - 22:55
Hi all,
Sorry for being late. I was busy with other development.
Zweitze you said that "Well, that implies a problem: components are installed twice (you installed for two users) but after the first uninstall, the components are removed."
I am not sure about that because I tried to publish MS project 2000 in the active directory. I did the installation for two different users (user A and B)on the same machine. They copied the files to the same default folder. I uninstalled the project from one user(User A). All the files were removed from the folder. When User B tried to launch the MS project application, it was reinstalled......
The same behaviour was seen with the visio viewer 2003.
So I guess this is the expected behaviour in that scenario...
Regarding my application.....
I am not sure about the ICE57 ERROR. I have one of them with one component where I have both HKLM and HKCU entries in the same component. Now If I isolate them into two isolated compoonents and then I do a per machine installation? will the component with the current user registry entries be installed.And what about the per machine component would it be installed with a per user installation.......
Thank you very much.....
Sorry for being late. I was busy with other development.
Zweitze you said that "Well, that implies a problem: components are installed twice (you installed for two users) but after the first uninstall, the components are removed."
I am not sure about that because I tried to publish MS project 2000 in the active directory. I did the installation for two different users (user A and B)on the same machine. They copied the files to the same default folder. I uninstalled the project from one user(User A). All the files were removed from the folder. When User B tried to launch the MS project application, it was reinstalled......
The same behaviour was seen with the visio viewer 2003.
So I guess this is the expected behaviour in that scenario...
Regarding my application.....
I am not sure about the ICE57 ERROR. I have one of them with one component where I have both HKLM and HKCU entries in the same component. Now If I isolate them into two isolated compoonents and then I do a per machine installation? will the component with the current user registry entries be installed.And what about the per machine component would it be installed with a per user installation.......
Thank you very much.....
Zweitze
-
- Full Members
- 522 posts
Posted 04 August 2004 - 16:05
About components installed twice: The method I described, also known as reference counting, is the correct one. I can't tell why Project showed the behavior you experienced. In short, reference counting installed components is the successor of the old 'SharedDlls' registry key, which was nothing more than a convention for setup authors.
About your app:
I recommend to split up that particular component into two components, one with HKCU entries, and one with HKLM entries.
In case of a per machine installation, the HKCU component will be installed for the user performing the installation. Other users won't have that key. However, if you mark one of the HKCU values as keypath, and the software calls RegOpenKey, RegQueryValue (don't know which one), the installer will 'repair' the missing entries for that other user.
Note this scheme only works when you set the keypath accordingly.
The other way around (per machine components in per user installation) always works as expected: The component is installed.
I know that ICE57 is not that trivial, but I fixed mine, everything seemed to work much smoother.
Disclaimer: Dus to other reasons, we no longer attempt to install keys in HKCU. It's mostly HKEY_SELECTABLE now, and sometimes in HKLM. The software that needs HKCU comes up with default values.
About your app:
I recommend to split up that particular component into two components, one with HKCU entries, and one with HKLM entries.
In case of a per machine installation, the HKCU component will be installed for the user performing the installation. Other users won't have that key. However, if you mark one of the HKCU values as keypath, and the software calls RegOpenKey, RegQueryValue (don't know which one), the installer will 'repair' the missing entries for that other user.
Note this scheme only works when you set the keypath accordingly.
The other way around (per machine components in per user installation) always works as expected: The component is installed.
I know that ICE57 is not that trivial, but I fixed mine, everything seemed to work much smoother.
Disclaimer: Dus to other reasons, we no longer attempt to install keys in HKCU. It's mostly HKEY_SELECTABLE now, and sometimes in HKLM. The software that needs HKCU comes up with default values.
InstallDev
-
- Full Members
- 43 posts
Posted 04 August 2004 - 17:02
Thank you Zweitze, Your explanations are helping me alot to better unsderstand per user installation.......
Do you know where can I check for the component refrence counting. Is it possible to enable/disable it?... I know that we can check the 'SharedDlls' key in the registry in (HKLM\software\microsoft\windows\currentversion\sharedDLL) but where do we have to check for components counting...
Also if you can have a look at the thread "Change button for non-admins " I will be very thankful
Thank you very very very much
Do you know where can I check for the component refrence counting. Is it possible to enable/disable it?... I know that we can check the 'SharedDlls' key in the registry in (HKLM\software\microsoft\windows\currentversion\sharedDLL) but where do we have to check for components counting...
Also if you can have a look at the thread "Change button for non-admins " I will be very thankful
Thank you very very very much
Zweitze
-
- Full Members
- 522 posts
Posted 05 August 2004 - 13:37
All components are reference counted, unless they are marked as permanent (in which case reference counting doesn't make much sense). You cannot disable the reference counting.
The property 'Shared' in InstallShield is only intended for DLLs that are not only distributed by MSIs (esp. MSMs), but by other install programs as well. The Windows Installer will update the SharedDLLs refcount as well.
You can enumerate all packages that installed the same component using the MsiEnumClients function. (I don't know how this function behaves with multiple users installing the same product... Requires some testing I guess).
The property 'Shared' in InstallShield is only intended for DLLs that are not only distributed by MSIs (esp. MSMs), but by other install programs as well. The Windows Installer will update the SharedDLLs refcount as well.
You can enumerate all packages that installed the same component using the MsiEnumClients function. (I don't know how this function behaves with multiple users installing the same product... Requires some testing I guess).