Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

[Wise packaging]-How to make a multi-users installation ?

Created: 28 Mar 2013 | 6 comments

--- Software : Wise Package Studio 8

--- OS : Windows XP SP3, Windows 7

 

Hi all,

I work in a packaging team.

The society install the packages in silent mode, in two step :

1. Local machine part

By a system account command line

2. User part (if necessary)

By a user account command line, at the logon, with a custom action registry key (installed during step 1 if necessary).

For this part, we use a special feature with a condition on the LogonUser.

The custom action command is : msiexec.exe /i [ProductCode] ADDLOCAL=IT_UserSettings /qn

 

The problem is that the components of the feature are installed just one time, for the first user. For the other users, the component are already installed and for example the files we want to be copied in %appdata% folder are not.

 

I have done many tests with the properties ApplicationUsers and ALLUSERS but without success.

I probably don't do it in the right way.

Please, somebody can help ?

 

Regards,

Norbert R.

 

Operating Systems:

Comments 6 CommentsJump to latest comment

EdT's picture

There are various options available to you to solve this issue.  One point I would also make from my experience is that you need to be careful running MSI installs in the user context especially at logon time, as there may be other MSIEXEC processes running, such as A/V updates, which may cause your user install to fail.

Anyway, your options are:

1. Create the user install in Wisescript rather than as an MSI. This can then be run many times and not cause any "repair" scenarios.

2. Inside the table InstallExecuteSequence eliminate the standard actions PublishProduct, PublishFeatures, RegisterProduct. This will stop the MSI registering and allow repeated installs. There will be no entry in add/remove programs but you can still uninstall the MSI using msiexec /x <product code>.

3. I assume you are NOT setting ALLUSERS to 1, so the MSI is registered to the current user, and that any actions you run are in the user context and not the system context.

Overall, I believe the methodology your employer is using is flawed as there are too many points of maintenance, and a proper implementation of Active Setup would solve all these issues for you. There are also solutions available depending on whether your users have roaming profiles or local profiles.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

Norbert_FRA's picture

Thanks for the comment.

In fact, the ALLUSERS property is set to 1. If i try to set it to 0, during the installation with a system account, the value automatically become 1.

During the second part of the installation when the user is logged, if i try to set ALLUSERS to 0 (by adding the property in the command line), it doesn't works.

Maybe the problem come from the first part when I do the installation with a system account ? But i have no choice about this part.

A coworker found a way to solve this issue by deleting the GUID of the components. We didn't explore the Wisescript solution yet. We will try it, but i would like to understand why our method is not good.

P.S. we have both roaming profiles and local profiles.

EdT's picture

If you are using the same MSI for both the system and the user install, then you cannot change the ALLUSERS property once it has been installed once. You cannot install user components in system context. You could separate the system and user parts into two separate MSI files and install one as system and the other as user, but this is realistically a bad solution.

By deleting the component GUIDs you are breaking the MSI - again this is a demonstration of how little actual packaging skill exists in your team. Handling user installs from a system deployed MSI is really quite trivial either through self healing or through active setup - both well established and documented techniques that any packaging team should be using routinely.

Is there some unexplained technical edict from above that is making you work in this technically flawed manner? Please do not be offended but it sounds like your entire team desperately needs some decent training in MSI packaging.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

AngelD's picture

I would suggest 2 ways to handle this:

option 1 is usually done when installing user "stuff" on citrix (terminal server) environment (as the resiliency usually are prevented for users)

1)

install the user-related files somewhere "static" in INSTALLDIR directory (ex. [INSTALLDIR]UserData)

then use a script (ex. vbscript) to:

a) resolve the path for the INSTALLDIR or UserData if you've setup that as a directory table entry.

b) then copy the files or (sub) directories to the user's profile.

c) for HKCU registry entries; just write them through the script.

 

2)

make sure user-related components has a HKCU registry entry as keypath

trigger a repair through active setup

 

EdT's picture

Active Setup is also supported in Citrix/Terminal Server environments.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

AngelD's picture

Except when running seamless applications :)