Software Deployment

Hi!
As far as I know, self-healing runs from the detection of a missed key-file or key-reg of any component of any installed feature, if deleted files are not key of any component self-healing doesn't start.
Self-healing also doesn't run if there's no advertised shortcut or Active Setup set.
If it start it takes the missed files from the original msi path in first instance, but there's a list of possible paths where to find that msi in the msi itself. I mean there's a table in the msi that can contain alternative paths of the msi.

Hope it helps!
KrisBcn

Hi Marek,
to (1):
No not necessarily. It depends on, if the file which is removed, is a key file. Open a MSI in ORCA and go to the components table and look at the KeyPath column. There, you see the file which triggers the self healing of a component.

to (2):
the MSI is copied to the %windir%\installer directory, but without embedded cabfiles. This means, as soon as a repair process needs a source file, the original source has to be available. Otherwise you get the well known error message about the missing source.
Therefore, if you want use self healing for intentionally, eg. for fixing missing user profile settings, you need to make sure, that the MSI can find it source location. A better approach would be to use the 'DuplicateFile' or 'MoveFile' tables as described here:
http://itninja.com/question/distribution-message21

Regards, Nick

Thanks to everyone for your replies. I did have a couple comments regarding the above post nheim made.

1) The file I deleted was a DLL. Wouldn't that be considered a key file?

2) The Adobe MSI is in the C:\Windows\Installer folder but I guess it is not self-healing because it is not being referenced as the source?

1) The file I deleted was a DLL. Wouldn't that be considered a key file?

Well it certainly may be a file that is critical to the operation of the application, but in the sense of Windows Installer (as nheim as already pointed out) a file needs to be marked as critical to the component it belongs to (i.e. set as the keypath) for Windows Installer to detect that it is missing and thereby start the process of repair.

You might for example have a component containing two (or more) DLL's (generally not best practice, BTW) but the Windows Installer architecture dictates there can be only one keypath per component.

In that case, if the keypath of such a component happens to be another of the DLL's in the component that is not actually missing, Windows Installer will not detect that the other DLL has gone missing and won't trigger a repair.

This incidentally explains why many of the application packaging suites commercially available offer the ability to set up one component per file and to set that single file as the keypath. Only by doing this can you realistically expect a repair to occur should any file go missing. This can, however, lead to a very large number of components in the package and in some circumstances this can become unwieldy and incur a performance impact (especially during repair). This is why a compromise is often taken and only a subset of files are marked as keypaths.

The Adobe MSI is in the C:\Windows\Installer folder but I guess it is not self-healing because it is not being referenced as the source?

It is actually one of the first "ports of call" when the application needs to repair but because (again as nheim explained) this cached MSI has no associated CABs (external or internal) to accompany it, it is only really of use when registry repairs are needed. Should an actual file be needed, then Windows Installer will look to access the original source from the location the installation was originally performed from. Sometimes this original location may not be available - e.g. if the source was on a network share and the workstation is now disconnected from the network - which explains why you see the prompt for source media.

So to answer your question, the cached MSI in C:\Windows\Installer is being referenced as one source - it's just that it cannot supply source files for repair.

Some organisations copy the original source MSI plus any external CABS if used to a hidden area on the local disk and then run the installation from that area. In this way, source files can always be obtained whether the workstation is connected to the network or not. Another approach is to use the SOURCELIST property which allows a number of alternative source locations to be used in addition to the original source location from which the installation was performed. A really neat trick is to specify a DFS share location in the source list for even better resilience [:)]


Regards,

Spartacus

Thank you so much for such an informative post Spartacus! That definiately answered all my questions! :)