Software Deployment

We have developed an EXE file that does this for us.

in the msi package we have added a file called repair.ini

***repair.ini file***
[REPAIR]
AcrobatReader5.0.5.msi=/fpus {FDF64A04-28F0-495B-BF50-8A1508E101D8} /qn
***end***

And when a user is logging in the exe file is looking if a file is stored in the %USERPROFILE%\Local Settings\AcrobatReader5.0.5.msi exists if for a repair prosess will start.

COntact med if this sounds interesting, but be aware ot that all msi packages have to be redone - and reinstalled first, but of caurse this can be used tharting NOW.

We are doing this because wa have the files outside the msi package, so the user will not have problems then starting up an applikation fpr the first time locally.

//Göran Fetter
goran.fetter@se.aga.com

Well there are serveral ways of doing this depends why and when you want to do this!! You could create a shortcut in the startup folder that deletes after running the repair or you could put it in the RunOnce Key to run a repair - be careful do if you are doing this with multipe msis you cannot run more then one instance of MSIEXEC at a time so if 2 packages are repairing one will fail.

thanks for your replies.

we have a VB app that utilises local .xla files. These files are amended by some of the VB app actions. There is a suspicion that the .xla files become corrupted sometimes or even amended by users. Because of the nature of the VB they have to be R/W on the desktop.

Our apps support team sometime recommend re-installing this app but since moving our packaging to MSI rather that WinInstall NAI the re-install is not as easy.

I will write a separate small repair EXE to force repair, but what I really wanted to do was to make the MSI re-install without checking for it's own existence.

PS. This app is deployed by SMS.

Why not just make sure that the .XLA file is its own key component?

That way, when the user starts the app through the shortcut, that file will get checked to see if it's been changed/corrupted... and the MSI will self repair/revert back to the original install...

That way, you don't have to invoke self-repair externally, rather it'll be done automatically everytime someone runs the app.

I hope I'm not too much out of context here ; I thought of an
auto-repair solution alternative ...

The situation:
We have a network application on drive J:.
Configuration settings for this application
are stored in HK current user.
We install a shortcut pointing to the exe on the j:
drive so it's not advertized.
This app is installed with admin right but
needs to run with user rights.

The problem:
Nothing triggers the auto-repair to re-write
the configs in HK current user, so the application
starts but there's no configs.

A solution:
I thought, if I can't repair this application, I should
let the user do it; whenever he wants.
So I created a shortcut in the start menu next to the exe shortcut
called "Install your configurations". This points to
C:\WINDOWS\System32\msiexec.exe /FMOSU "\\server\path\application.msi"
Auto-repair starts and writes the configs to the current user section
(repairs the whole package for that matters).

I realize that this is not entirely automated but it works.

In your environment this works, but in a setup simillar to mine, it would not. We have our users and machines locked down to the point where they cannot use the windows installer service. All autorepairs are called by Active Directory as that is how the apps are deployed.