Software Deployment

The simplest route is to disable any advertised entry-points. These are probably limited to the shortcut(s) which launch the app. Convert these to "simple" shortcuts.

How does that help though? The repair starts before any shortcuts are run, it starts as soon as the updater program copies over the new versions of the EXEs

Then you probably have entry-points in the registry, almost certainly in the COM area (DLL registration).

Ah ok thanks, is that something I can 'fix' or is it going to be more trouble than its worth?

That depends on your level of knowledge and the tools you have at your disposal.

I suspect that the MSI was created by Visual Studio?

Well I'm not actually sure what the MSI was created with as I didn't create it - the application is an old VB6 app that had its own installer but that installer wouldn't play nicely with SCCM so we got one of the guys who helped set our SCCM system up to create a package for it. I assume he just looked at the files and registry keys etc that the original install was editing and mirrored that in the MSI, but I can always ask him exactly what he did and what he used if that will help.

I have fairly limited knowledge when it comes to MSI editing I'm afraid, I used Insted earlier today to fix some font installation issues in an MSI but that's the first time I've really used it. Its quite annoying that there isn't just a property you can set in an MSI to tell it not to self repair :(

To disable shortcuts entry points play with DISABLEADVTSHORTCUTS property.

In a pinch I suppose you could take the key files out of the components that contain these files. This way Windows Installer won't trigger a repair on em.

but like I said, the repair starts before I launch any shortcuts. It starts as soon as the EXEs and DLLs get replaced by the updater

ORIGINAL: pjgeutjens

In a pinch I suppose you could take the key files out of the components that contain these files. This way Windows Installer won't trigger a repair on em.


Will that have any side effects? I believe it will mean those files don't get removed when we uninstall but that's not a massive issue for us because this app is on pretty much every machine and very rarely gets uninstalled

Will that have any side effects? I believe it will mean those files don't get removed when we uninstall

It does not mean they will not get removed. It just means Windows Installer will have no 'hook' for the component to determine its sanity. Basically the key-file is the one that, if it's missing, triggers the repair for the entire component.

Suppose you have a component with 5 files in it. Only one of these is the keypath, and only if this one is missing will you get a repair. The other files are not 'monitored' so to speak.

EDIT: on a side note, another option might be to take out version info for the affected files in the File table, but that's something you'll have to experiment with, it's been awhile since I've had to do it myself.

PJ

OK thanks, well it sounds like removing the key files would be the best way to do it then. Can you tell me how I can do this or point me to any good guides etc? I had a look in the Components section and under each one there is FeatureComponents, File, and Registry. Do I just delete the File part of that? Kind of guessing here..

Easiest way to do this really is to do a direct table edit. You'd best start by making a backup of your original MSI first (you never know..)

First find out which components the files you want to work on are in (File Table, Component column)
Then go to the Component Table and delete the entries in the keypath column

PJ

So can I just do that for all of the components then? because I don't want any of them to be auto-repaired. There's only about 40 components listed so it won't take that long to do them all..

yes you could i guess, just make sure you test alot [:D]

OK I've edited the MSI to remove all of the KeyPath entries but now when I try to install it I find it installs to the E drive instead of C drive [&:] I can't find any reference anywhere within the MSI to E: so can anyone explain how I can make the default the C drive?

check the ROOTDRIVE property for the MSI.

Ah yeah thanks, I've been doing some research and found that same ROOTDRIVE property you mentioned so that's sorted that out.

However, my newly edited MSI doesn't seem to register any of the COM components that it is supposed to now :( The installation completes successfully but when I try to launch the application it just says "Component 'comctl32.ocx' or one of its dependencies not correctly registered: a file is missing or invalid"
I tried manually registering that OCX file with regsvr32 and then the program got further (just gave me a generic ActiveX error) so obviously the MSI is not trying to register the OCX and DLL files.

Is this likely to be because I removed the KeyPath? If so, how can I fix it?

Thanks
Chris

'comctl32.ocx

This looks like a missing merge module in your package. Did it contain any of those (more specifically Microsoft Common Controls Library)
You really wanna leave those components alone :)

You might have been better off sticking with the original VB6 package rather than repackaging it as an MSI, since you clearly have no need for Windows Installer technology in your situation. There's no self-healing technology in a VB6 package. I think you can run setup.exe silently with the /s switch.

In any case, back to your ugly MSI project, you're probably being tripped up by the advertising information. You probably need to convert everything to straight registry entries and clear out the advertising information so that your COM controls don't trigger self-healing. This is easier said than done, however. You essentially need to convert any advertising information to registry entries. You may have to recapture. You've also broken something to cause your controls to stop registering or to not register completely, so you should probably revert to your backup copy.

There may be a flaw in your autoupdate mechanism, too. If it's unregistering and re-registering your controls, it may be clearing the advertising information from the registry. If possible, the autoupdate installation mechanism should be revised to not unregister the controls in order to preserve the existing registry entries.

You shouldn't need to worry about clearing the file keypaths because you're probably not deleting any of the application's files during the autoupdates or application runtime. As long as the files exist, a self-repair won't be triggered in that way.

In short, it sounds like the MSI isn't built the way you want it to be able to support autoupdates without triggering a repair. You should probably not be using Windows Installer and should see if you can go back to using the VB6 project.

Thanks, I wish we could use the VB6 installer but unfortunately it just doesn't seem to work with an SCCM OS deployment. You are correct saying that normally you can use the /s switch to execute the install silently (well, its not silent but it doesn't require any user input) and this works perfectly when I deploy it as a package to an existing live machine but it only works if we tick the "allow user to interact with program" option in the SCCM advertisement (even though the user doesn't need to interact with it, they just see the installation happening). The problem with that is that we want this to be included in our OS deployment task sequence and for that you cannot tick the "allow user to interact with program" option :( If anyone knows of a solution to this then I would gladly go back to the VB6 install

Chris
If you are using SCCM R2, there is an option to run the application as another user. This link explains how http://adventuresinosd.blogspot.com/2008/12/runas-in-sccm-2007-r2.html
Otherwise though i´m not sure it will work in OSD you can try making a wrapper msi. There is a video of it in appdeploy using wise.

We are using SCCM R3 so we should have that option but I don't really see how that is going to help? I will give it a go anyway just in case though, thanks

That link was the only one I could find then, but the settings are a bit different, in Run command line task, "Command line" you can use setup.exe /s, do not tick the "start in", browse and set the Package, I usually set the timeout to something like 5 minutes, and set the user with the password(admin user), the task will then run the setup.exe /s as that user.
I usually enable Continue on error on Option tab too.

Good news! The VB6 installer does seem to work if we run it as a command line program as you suggested :) Thanks a lot, I'm glad we don't have to mess about with this MSI anymore (though it seems daft that using an ancient installer actually works better than the latest windows installer technology).

Thanks to everyone else that replied as well :)

Don't knock what you don't understand. Windows Installer is perfectly capable of doing what you're doing, but it's a more advanced technology based on certain standards and has to be implemented differently than the way your package is currently built. Rather than stripping away the self-healing aspects (advertising, keypaths) which is a relatively easy thing for an experienced packager to do, you are simply avoiding the whole issue by using an old installation technology that lacks the robust capabilities of Windows Installer (self-repair, advertising, managed components, etc.)

I wouldn't say your "ancient" installer works better than Windows Installer. Simpler maybe, but not better.
Not to say Windows Installer doesn't have its share of aggravations, but it's still way more powerful than something like PDW.

Chris I´m glad it worked. And I totally agree with mazessj, a well made msi, beats any other installer for windows.