/build/static/layout/Breadcrumb_cap_w.png
10/31/2016 1749 views
The MSI/MST I'm working with installs per-user files to a "cache" folder under "Program Files" and uses DuplicateFile to copy to the user's %localappdata% folder. By doing it this way the MSI repair feature is not needed for the user that does the initial install.

If the files are deleted, they are restored via the MSI repair function from the "cache" location. But the files were being restored to different locations than where they were placed originally.

I noticed that the folder structure under the "cache" folder did not match the user profile folder structure. So I decided to try and fix this via Orca, modifying the MST, specifically the Directory and Component tables.

I modified Directory table entries and in a couple of cases created new entries if the Directory was shared with other components or was a parent folder for another directory. The component table directory_ column was modified to point to the new directory table key. This is the primary modification. Now the folder structure under the cache folder mirrors the structure under the users profile folder.However, the files moved into proper sub-folders under the "cache" folder are no longer being repaired.

There must be another aspect to the repair that I'm not aware of. Hoping someone can help with further hacks that I need to make to the MSI/MST.

Thanks

Answer Summary:
0 Comments   [ + ] Show comments

Comments


Answer Chosen by the Author

0
As this is someone else's install I can't change the basic way it operates. Since I don't have enough time to fully understand what makes this tick I've used a script to repair the problem when the user profile is reset or created. Thanks for the replies.
Answered 11/10/2016 by: GTVic
Senior Yellow Belt

All Answers

0
Man I haven't used the DuplicateFile Table in ages, its a really efficient method of populating files into the profile though.

Just google'd this, some names I recognise! :D
https://www.symantec.com/connect/forums/files-self-healing-wrong-location-user-profile

Do you know where the files are going? Anyway, as I mention in other posts, LOG LOG LOG.

You'll probably need to enable via the MSI service (in the registry) so you can catch the repair logs, from there you can see whats going on. Off the top of my head, did you set a keypath (not sure if you do this for a DupFile), check the system profile just in case its getting copied there (if so read that link I mentioned). Start with the logs first as that will give you a good starting position, ie you can see if they are getting Dup'ed or not, if they are the log should tell you were they are getting copied too.
Answered 10/31/2016 by: rileyz
Red Belt

0
Thanks for the link. I'm not sure if this is a repair, healing or active setup but I have found I can monitor the progress with Procmon and there is a log file.

I've determined the original MSI creates a key in the Installer area of the registry and creates a new MSI in C:\Windows\Installer\60d0836.msi.

When the product is "repaired" the 60d0836.msi file is the one that it runs. If you delete it an error occurs. It seems to copy all files from the cache location. It will even copy additional files that are manually added to the cache folder but not subfolders.

I tested this by renaming one of the files. It copied the renamed file and then complained the original wasn't there. As another test I tried modifying this MSI to change the name to the renamed file but that didn't get rid of the missing file message. None of the manual mods I made to this MSI worked so I still have no idea how the copying is done or what my next step would be to control this.


Answered 10/31/2016 by: GTVic
Senior Yellow Belt

0
Repairing/self-healing relies on key paths to identify what needs repairing. If the key path exists, no repair takes place. Simple.

Almost no-one I know uses this method to populate user profile data. Use a properly structured feature tree and advertised entry-points instead. If the MSI doesn't natively have any advertised entry-points then use Active Setup to trigger the self-healing.
Answered 11/09/2016 by: VBScab
Red Belt

0
Using the duplicatefiles table can be quite complex as you rely entirely on key path detection to trigger the copying of files.  
If you are working with Windows 7 or later, do bear in mind that the entire source of the package is now cached under c:\windows\installer although idiot Microsoft never bothered to have this location added as a source.  If you do this yourself (I documented it on Symantec Connect) then you don't need to bother copying the files locally unless there is no advertised entry point in your package. (I have frequently changed shortcuts to be advertised when I want to enable self healing, but then you find out how bad the vendor MSI really is !! )
Answered 11/12/2016 by: EdT
Red Belt