Vidéos d'aide de Screencast

How to reduce repair time of the application

Created: 29 Nov. 2012 | 14 comments


I am currently repackaging an internal application. Its size is 8.47 GB and its putting resources at user location. NO Advertise shortcut.

So for that I am using Active Setup and it working fine...As this application is very huge, for repair it’s taking huge time.

Is there any way can I reduce its repair time (is there any methods in Active setup or any other way I can repair only that particular feature having user location resource instead of entire application for repair)

Thank you in Advance!!!!

Raj Sam

Commentaires CommentairesAccéder au dernier commentaire

l'image des EdT

If your active setup is running a repair on the entire MSI, then you are going to run into problems sooner or later. What I would recommend is that you create an entirely separate "installer" to be run by your active setup, which is delivered locally as part of your main install.

You provide very little information on what exactly you need active setup to install. As always, the more information you can provide on what you need to achieve, the easier it becomes to suggest alternative solutions.

I would discourage the calling of MSI files through active setup, as it is not uncommon for other MSI processes to be running at bootup, for example, JRE updates, A/V updates, and any other install that is waiting for a reboot to complete. If your MSI repair encounters another MSI process already running, you will get a failure error code, but nevertheless, the active setup registry keys in HKCU will have been updated, and the active setup will not run again.  I would always recommend your active setup is written in a way that can run successfully regardless of what other processes may be running on the machine.

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

l'image des Raj Sam

Hi EdT,

Thanks for the quick response..

Let me elaborate the problem.

1.This application is very huge application(8.47 GB) with around 21 thousands plus resources it is having.

2.there are 7 features(3 msi) which having resources going to user location. i e around 800 files and reg going user location.

3.This application calling 3 msi and i have prepared mst for that.

4.All 3 msi is putting user location data. and dont have advertise shortcut so I have added active setup  .

Now It is working perfectly .after installation.

The problem is that , while first log on  to the user system it is taking huge time for repair , just like for installation time of the application. But after that application is working perfectly.

I just want to reduce that repair time of first log on  of the user.

Note: This application dont require any update and MSI dont repairing another MSI process, already running

You have suggested:

1.To prepare separate installer ,but as I am repackaging this application ,i think it wouldnt  be right  for me to preparing separate installer. It will create problem for upgrade in future.

I am thinking of moving all user location resources to one feature, not sure about this.

Is there any other way I can reduce the repair time.

Plz help me.


Raj Sam

l'image des EdT

I presume your active setup is calling the original installation MSI, and if this is the case, then the entire MSI has to be loaded, and any internal CAB files need to be unpacked before the repair can start.

Since you have still not given specific information on what your active setup is doing (ie the exact calls it is making), it is again difficult to make progress. As a separate question, are your MSI files compiled with internal or External CAB files, or just external files. If you stick with external files, there is no need for the repair to unpack the existing source, so will be quicker.

What exactly needs to be repaired into the user profile?

As I keep repeating, the more information you can provide on DETAILS, the easier it is to suggest a solution. At the moment it is unclear whether you just need to repair user registry keys, or user files, or both.

I can think of various solutions to different scenarios but I am not going to waste time documenting all these solutions as it is easier to wait until I understand what EXACTLY you are trying to do in your repair.

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

l'image des piyushnasa

If your active setup is just for user related keys then I would suggest you to use msiexec /fu {ProductCode} /qb in your active setup stubpath key.

This will just repair the user keys and will not repair the whole msi.

If you have to copy files as well to user profile, then I will suggest you to add those files in PrograsmFiles or AllUsersProfile to some location and write a VBScript to copy file to User Profile and then run this script in active setup.

Let me know if you face any issue in this.

Piyush Nasa Altiris Certified Professional (ACP)

l'image des wancsho

@piyushnasa: What if, if the installation is triggered in system context, as in this case the files are repaired at NetworkService\Application Data folder instead of Username\Application Data folder when msiexec /fu {ProductCode} is used in stubpath.

Have you ever experienced this scenario?


l'image des AngelD

Wancsho, If you trigger a repair manually or by Active Setup and the files goes into the system account's AppDataFolder then you have a File or Directory set as keypath for the component(s). User-based resources (components) should always have a HKCU registry entry as keypath.

l'image des piyushnasa

How will it trigger in system context when the user logs in with his id?

This is the whole point of Active setup that it always run in user's context but with elevated rights so the MSI can repair.

Piyush Nasa Altiris Certified Professional (ACP)

l'image des AngelD

During installation of a component it will get "registered" through the ProcessComponents standard action where one of the arguments is the keypath for the component. When a repair is triggered the location of the componentpath is fetch (to find out if it's broken; missing keypath) and as the path is set to the system account's AppDataFolder during initial installation that will be the installation path for the component.

Hope that make sense?

l'image des EdT

Active Setup runs entirely in the user context with no elevation. That is why it is necessary to ensure that the MSI repair is managed correctly so that repair is not attempted for system components.

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

l'image des EdT

Based on experience, I would never recommend using msiexec /fu in an active setup. The problem with using any msiexec call for active setup, is that active setup only gives you one chance - if there is another msiexec process already running, the one called by active setup will fail with the error "another installation is in progress". However, since the user keys for active setup are set regardless of what exit code is generated by the program called in "stubpath", this msiexec process will never get run again for that user.

Therefore, active setup should only be used to call programs which can run regardless of any other programs which may also be running.

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

l'image des piyushnasa

I have been using this for quite a while now and specially repair of MSI/Active Setup is very nicely handled in Windows 7. My users have never faced an issue with this. Scripts are good but just try to come out of it and utilize the power of MSI.

Piyush Nasa Altiris Certified Professional (ACP)

l'image des EdT

How do you know your users have never faced an issue with this? Have you personally checked every active setup to verify that it ran correctly? Checked every event log?

I too assumed that this was a valid way of handling active setup until I conclusively demonstrated that there were MANY instances where a conflict of msi installations was stopping Active Setup running correctly.

You can test this for yourself. Install an app with an active setup component, then start another MSI installation that will run for a few minutes.  Force active setup to run by stopping and restarting the Explorer process using task manager. Then tell me whether the active setup ran successfully or not.

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

l'image des piyushnasa

Hi EdT,

You are really making the things too complicated. It is not that big an issue and not for every machine it will fail. Even if it fails on 10 machines out of 5000, and the users face an issue then they can repair the application by themselves or call the Service Desk.

I know this because we are always in touch with Service Desk you keep on updating us if there are any issues with any of our applications with the users.

One can never guarantee a 100% success rates for your deployments nor have I seen anyone achieve this ever. Let me know if you have.. wink



Piyush Nasa Altiris Certified Professional (ACP)

l'image des VBScab

>One can never guarantee a 100% success rates for your deployments
No, but you can - and should - mitigate against them failing as much as you can.

Maybe Ed and I are just old-fashioned in wanting to do the job as professionally and thoroughly as possible...

Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using before posting.