/build/static/layout/Breadcrumb_cap_w.png

General question on MSI reinstallations

I'm still pretty new to the package world and I've seen this a bunch of times and was wondering if its something I am doing.

On a number of my packages if I install under an administrative account, when the user attempts to launch the application it run a brief installation the first time. In most cases this is only a few seconds, but in others it can be a few minutes of loading. Almost as if it is installing all over again. Once complete the application runs fine. Given that I have so many applications in my queue I've just been ignoring it and moving on.

Anyone have some suggestions for me that might prevent 1 out of every 4 of my packages from having this problem.

0 Comments   [ + ] Show comments

Answers (7)

Posted by: fuz_kitten 16 years ago
Second Degree Blue Belt
0
Your packages are repairing current user data, HKCU reg, files that go down to the user profile, user DSN stuff, etc. This behaviour is by design and is desirable. Think about it, if you install a package as Admin then all the current user stuff is going to go down to the Admin profile. A new user logs on and a repair is triggered because all the CU stuff is missing.

Packages that appear to reinstall themselves in their entirety may have features with both user and machine data on them. The CU data is missing so Windows Installer will attempt to reinstall the entire feature, this can take considerable time if it’s a big one.

Packages that repair every time they are launched need looking at… but let’s leave that for another day! 

Charlie
Posted by: vjmeh 16 years ago
Senior Yellow Belt
0
I find that if you remove the /Administrator folders from your MSI structure this usually solves the problem. Also keep an eye out for anything labeled Microsoft/crypto. Very rarely have I had to remove any Installshield folders and files (If I capture an older non-msi/sms compliant Installshield Installation).
Posted by: knight 16 years ago
Orange Senior Belt
0
The best thing to see if the application triggers a repair is the event viewer. All event regarding application can be seen on that.

Hope this helps

knight
Posted by: tvieson 16 years ago
Yellow Belt
0
I ran through a few of my older projects and most of them do have some HKCU entries. The latest one has a lot of user specific stuff which must be why the "reinstallation" takes so long the first time the application is launched.
Posted by: fuz_kitten 16 years ago
Second Degree Blue Belt
0
Indeed, case closed?
Charlie
Posted by: knight 16 years ago
Orange Senior Belt
0
If you want to have an automatic rapair of the application when a user logged-on, you can use active setup.
Posted by: jmcfadyen 16 years ago
5th Degree Black Belt
0
i just noticed something about the time your applications are taking to do this.

if you are using installsuck you will have one problem which contributes to the speed.


When applications heal they will heal in one of two forms.

FeatureLevel healing or

Component level healing.

the latter of which is considerably better for performance.

Self healing will always heal the first feature it attacks at feature level healing.

Installshield captured applications make the poor mistake of creating a single feature. This means that if you have a single registry entry missing the entire feature is marked for reinstallation.

a typical structure that many people use is to put HKCU entries in a top level feature and the remaining application in a lower child feature.

this is not required when using wise as they have already incorporated a similar setup as default.

I have written a number of very comprehensive documents on self healing which are posted at myitforum should you want to get more detail on this.

I think I labelled the articles Current User Healing

cheers,

John
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ