Software Deployment

Hi Frank,

Take a look at John's (jmcfadyen) detailed description of "Current User Healing" at http://itninja.com/question/how-do-you-roll-out-new-machines?4146&mpage=1

Depending on where the entrypoint is located that triggers self-healing check and the broken component a repair will occur on either feature or component level.

Thanks this was very informative!

Still missing a bit of information regarding what I've seen during tests. What I saw yesterday during an MS Office 2003 repair was the following:

- Two features (lets call them 1 and 2) on the same level. (Other features above this level!)
- Both features contain a component with a HKCU key.
- Both feature contain a component which contains machine data (keypath to exe) + a quick launch shortcut (per user)

- User 1 installs the package with ALLUSERS=1.
- User 2 starts the application. A repair is triggered by feature 1-> HKCU component.
- The repair reinstalls the components contained in feature 1, so it also places the shortcut (although that components keypath was there!)
- The repair also checks feature 2, which is on the same level?! It repairs the missing HKCU component keypath, but doesn't place that other quick launch shortcut.

Please let me know if I'm missing something here.

[hr]Edit:
Have just seen the following happening, which does not correspond with jmcfadyen's explanation.

I have created a MSI which looks like the following:

[hr][Feature] User_Data
|
| - - - - <Component> UserComp {KeyPath} HKCU\Software\Test\Default
|
| - - - - [Feature] Machine_Data
|
| - - - - <Component> MachineComp {KeyPath} %ProgramFiles%\Test\Test.txt
| {Adv Shortcut} Test
| - - - - <Component> BigDummyFile {KeyPath} %ProgramFiles%\Test\BigDummyFile.dat[hr]jmcfadyen describes that when (entrypoint) <Component> MachineComp is started threw its shortcut, the Windows Installer will check if the keypaths are there, first of [Feature] Machine_Data, then of [Feature] User_Data, because that is its parent.

Now at this stage, let's say {KeyPath} HKCU\Software\Test\Default, of <Component> UserComp is not there.
What I understand from jmcfadyen is that only [Feature] User_Data should be repaired. But when I check the logs I see that it does a reinstall of the feature in which the entrypoint is located, [Feature] Machine_Data. Note that it still repairs the components of [Feature] User_Data, but it will also reinstall [Feature] Machine_Data.

When I move the entrypoint, <Component> MachineComp, to [Feature] User_Data, I see in the log that only that feature will be repaired in the same circumstances.

Have I misinterpreted something, or am I missing something, please let me know.

Thanks once again AngelID.

Hi Frank,
you used a textfile in your test. Did you make sure, it was added to the MsiFileHash table?
If this is not the case, it will be repaired each time, because it has no version info.
See: http://blogs.msdn.com/astebner/archive/2005/08/30/458295.aspx
Hope this clarifies this.
Regards, Nick

Good call Nick!

Have in mind if the timestamp of the files are same then and only then will the MsiFileHash table be used for unversioned files.

Lets see what feedback we get from Frank.
If a broken component is found outside of the feature the entrypoint is located that shouldn't occur.

I wrote that document years ago, it is a little shall we say untidy. But it gets the main point across well. I have some diagrams of the flow which may help to understand this, they seem to of been dropped from the original doco over the years.

I have an MSI I have constructed which demonstrates the self healing items described in the document. Also another point to add is that even if a feature is flagged for reinstall you should check each component also for state.

If you use the WILOGUTL.EXE it shows all the feature component state detail well which aids in the understanding of this. I haven't read that doco in years I should perhaps read it again and clean it up as it seems to get used alot.

Where I mentioned the entry point it starts checking at that feature. If nothing is broken it will step up the tree to check other features. One of the items which is often overlooked is if any component is in a broken state the entire MSI is checked. Therefore child features and same level features will also be checked.

If you want the MSI let me know and I will send it to you.

Cheers,

John

Good morning guys, happy to see a couple of posts after the weekend ( + I have friday's off :)

Nheim, you are correct. I did use dummy files (text), so there is no version info. I've modified this and the result is that hashing does help somewhat, since the files won't be overwritten, still the component registration is executed fully for the components in the feature which holds the entrypoint component as well.

There is one thing I forgot to mention. When I check the logs, it actually states the command line of the repair, in which REINSTALL and REINSTALLMODE are included. The REINSTALL property is pointing to the feature in which the entry point is located (not the feature of the missing keypath, as reported in the eventviewer). Anybody any ideas on this?

John,

Yes I would like your sample MSI, so I can check this against my own test MSI. Maybe I just made one silly mistake somewhere.

Thanks guys,

Frank

Frank,

I would also check the installation states for the components in each feature. I haven't done any testing on this for at least 2-3 years now I have been under the assumption is hasnt changed with recent installer versions. (perhaps not a good assumption, I do however recall this was raised by someone else at the time as well)

I would repeat the same tests you are doing however extend the test to check the component states as well. I would assume that even though the features are flagged for install it will also check the keypath for each component which would be present effectively not installing the child feature you mentioned.

I will forward you the msi as well.

John

John,

Since I use two features these should be both marked as installed. I've checked this with the following code:

[font="courier new"]Dim objInstaller : Set objInstaller = CreateObject("WindowsInstaller.Installer")
msgbox objInstaller.FeatureState("{<ProductCode>}","<FeatureName>")

Unfortunatly Microsoft once again fails to correctly document the return values (http://msdn2.microsoft.com/en-us/library/aa369409.aspx)
But I presume a return code of 3 should mean [font="courier new"]msiInstallStateLocal
Which I received for both features.

I dont think you can really ask for the component state (although you could try to check every component keypath or somehing like that). I don't see a reason to do this either. please explain.

I think we are also miscommunicating here, so therefore I will try to explain my vision on what is happening once again.

[hr][Feature] User_Data
|
| - - - - <Component> UserComp {KeyPath} HKCU\Software\Test\Default
|
| - - - - [Feature] Machine_Data
|
| - - - - <Component> MachineComp {KeyPath} %ProgramFiles%\Test\Test.txt
| {Adv Shortcut} Test
| - - - - <Component> BigDummyFile {KeyPath} %ProgramFiles%\Test\BigDummyFile.dat
[hr]

1. The above product is fully installed.
2. I manually delete the keypath of component UserComp.
3. I start the advertised "Test" shortcut
4. A repair kicks in. The log specifying the following command line (not fully displayed here): [font="courier new"]REINSTALL=Machine_Data REINSTALLMODE=pocmus
5. The log also shows:

[font="courier new"]Feature: Machine_Data; Installed: Local; Request: Reinstall; Action: Reinstall
Feature: User[font="courier new"]_Data; Installed: Local; Request: Null; Action: Null

Components within Machine_Data feature are logged as follows:
[font="courier new"]Component: MachineComp; Install: Local; Request: Local; Action: Local

Components within User_Data feature are logged as follows:
[font="courier new"]Component: UserComp; Install: Local; Request: Null; Action: Local

So the thing I think is very odd here, is that the feature User_Data is missing a keypath. But the feature in which the entry point is located (Machine_Data) is fully reinstalled (as shown by the logged command line), while it has no missing keypaths.

Hi Frank,
if you go trough the log, you will see that the 'Machine_Data' feature is reinstalled, but no actual file copy is taking place because of the version checking.
This behavior makes it so important, that all files have versioning info or an entry in the hast table.
Regards, Nick

Nick,

That is correct. But all components within Machine_Data feature will still be re-registered. This process takes time. My motivation for only wanting to reinstall User_Data is that I want to create a very short repair cycle for packages that are going to be installed per-machine (ALLUSERS=1). I only want to place the items that need to be placed + I only want to reregister the components that need to be placed.

Also, I still don't fully understand how the repair mechanism works. As stated in an earlier post, I think the reinstall decision by Windows Installer is odd.

Thanks for your comment,