Software Deployment

try this on packaged apps, not vendor stuff .

Over the last months I have been faced with learning how the MSI technology works and have developed a few techniques which may be useful to many of the new comers.

First I will outline a few important items which are critical to building MSI packages.


Features: A feature is a container which may hold other features and components.

Component: A component is a container designed to hold application related information such as:
regsitry keys
files
ODBC configuration
to name a few. A component has a unique identifier called a {GUID} which is represent by a 16 bit HEX code.

Primary Key: The primary key is an item in a component which is checked during advertised actuation.

Entry Points: Items within the package can be advertised. It is common to use shortcuts and file extensions as advertised entry points. An advertised entry point will trigger the checking of primary keys for components within a feature.


I will outline a little more exactly how healing works which will assist in understanding why to use the following feature / component structure.

For the following assume there is only one Feature called ""COMPLETE""and a few components such as ""COMPONENT1""""COMPONENT2""and ""COMPONENT3""

COMPONENT1 contains 1 file ""FILE1.TXT""with a primary key of ""FILE1.TXT""

COMPONENT2 contains 1 file ""FILE2.TXT""with a primary key of ""FILE2.TXT""

COMPONENT3 contains 1 advertised shortcut ""SHORTCUT1""
contains 1 file ""FILE3.TXT with a primary key of ""FILE3.TXT""
contains 1 file ""FILE4.TXT

COMPONENT4 contains 1 HKCU reg key with a primary key of ""HKCU\test""

When an entry point such as a shortcut is triggered in an MSI the following will occur. The msi self healing operation will begin its checking process in the following manner. The MSI will enumerate what feature the entry point or in this case the shortcut belongs to. For the above example assume a user runs SHORTCUT1 which is the advertised entry point. This action will cause the MSI to find out what FEATURE SHORTCUT1 is in. The next step is to find out what other components are in this feature. In this case COMPONENT1 COMPONENT2 and COMPONENT3

Each of the COMPONENTS in the same feature as the entry point will be checked. The primary key of each component will then be checked against the workstation to ensure that these primary keys exist.

In this case COMPONENT1 has a primary key of FILE1.TXT therefore the msi will check if FILE1.TXT exists on the workstation and continue this process through all of the COMPONENTS within the same FEATURE the entry point is in. If any of the PRIMARY KEYS are missing the entire feature is healed. As depicted above if FILE4.TXT is missing nothing will happen. FILE4.TXT is not a primary key therefore the MSI will not care if it does not exist.

Now a very important thing to note here is if there are any parent FEATURES windows installer will then step into the parent FEATURE and being this process again and continue until all parent FEATURES are checked.

Now for the interesting part.

Anyone whom has been packaging for a while will know that HKCU registry keys are often the cause of trouble within a package. The current user keys normally are only delivered the user whom is logged in at the time of installation. The msi technology has attempted to overcome this shortcoming and uses self healing to configure current user settings for all users of a given workstation.

When using Wise Package Studio the default actions within Wise will create a COMPONENT called ""CurrentUser""this component will have all of the HKCU registry keys inside it. If your using other applications such as InstallShield I expect you could achieve the same results relatively easily.

Now assuming we followed default configuration of Wise all of our components would go into the ""COMPLETE""FEATURE including the aforementioned ""CurrentUser""COMPONENT.

If you were to use this default methodology any new users logging into a machine and running an advertised entry point would trigger the healing mechanism's checking routines. This would eventually get to the ""CurrentUser""COMPONENT and would find that the primary key for the ""CurrentUser""COMPONENT would not exist. This in turn would trigger a heal of the entire COMPLETE FEATURE. Now on a small application this may be acceptable however if you have a 600mb application reinstalling the entire application for a new user would probably be extremely excessive.

So to counter this effect with the help of some of the mentioned persons this idea was developed.

Create a new FEATURE STRUCTURE as follows:


FEATURE

""CurrentUser""

Move your ""Complete""FEATURE to a child of the ""CurrentUser""FEATURE. so you will have the following.

CurrentUser

------------Complete

Whenever you have an application which contains HKCU components put the HKCU components into a COMPONENT called ""CurrentUser""and put that COMPONENT into your ""CurrentUser""FEATURE.

The remainderof the application would go into your COMPLETE FEATURE as pictured below.


Feature:CurrentUser

Component: CurrentUser

--------Feature:Complete

-------- Component: Component1
-------- Component: Component2
-------- Component: Component3

Now in this scenario if you run the SHORTCUT1 as per the previous example the COMPLETE FEATURE is checked as per normal windows installer operation. In a good package this will not result in healing of the COMPLETE FEATURE as it should already be delivered during install time.

But what is good about this is that once the COMPLETE feature is finished its checking routine Windows Installer behaviour steps up to the parent FEATURE in this case ""CurrentUser""and checks that feature also.

If a new user is logged in the primary key for the ""CurrentUser""COMPONENT will not exist which will trigger healing on the ""CurrentUser""FEATURE therefore effectively you are now only healing a tiny portion of your package not the entire application.

I hope this is helpful to some of you. Its pretty hard to put into words so hopefully it will clear up some behaviour and assist with healing HKCU components.

Next time I will address the Current User files.

Please if you have any comments feel free to mail me on huckey@mindless.com



Current User Healing II

If you have not already read my first post this probably wont make alot of sense. Therefore I would recommend reading Current User healing before continuing with this. This assumes you know how healing works and understand fully keypaths and components etc.

For those of you whom have read my first post on HKCU registry healing. Here is the next step which will enable you to heal files as well as HKCU keys.

If you have followed the first step which creates a feature structure in the following manner.

HKCU - (Current User Feature)

- Complete (Remainder of application)


Your HKCU feature will only contain CurrentUser components or components which contain registry entries which are destined for the HKCU registry hive.

The complete feature will contain the main application including all ""program files\%appname%""and HKLM entries. The reason for this is explained in the first Current User healing guide.

Now to make full advantage of this method of healing often you are required to put files into the users profile directories such as ""c:\documents and settings\%username%\application data""or similar folders such as ""my documents""etc.

This is a way to allow you to heal this folders for each user without requiring to step outside of the msi to maintain the healing process. Therefore no need for active setup or other methods, this is all fully self contained within the msi.

To understand how this works its important to know how the duplicate file table works within the msi. The duplicate file table is used to reduce the size of an msi and increase performance by not replicating files inside the msi. For example if you have a file in your package in the following locations which is identical the default behavious of msi is to not add this file again.

i.e.

c:\program files\%appname%\folder1\file1.txt
c:\program files\%appname%\folder2\file1.txt

here we have 2 files with the same name and structure. Under normal conditions the msi would recognise this file is the same and it would make an entry in the duplicate file table. If we assume in the above example .\folder1\file1.txt was the first file to be placed into this msi it would then show in the file table as a normal file as expected. However when we add .\folder2\file1.txt what you would expect is that another entry would be added to the file table as per the previous entry. However if the msi recognises the file is identical it does not use another entry in the file table instead it creates an entry in the duplicate file table. The duplicate file table then makes a pointer back to the first location where this file was installed to.

Therefore .\folder1\file1.txt was the first entry so instead of .\folder2\file1.txt being added again it uses the duplicate file table and makes a reference back to the install directory of the first file1.txt. In this case ""c:\program files\folder1\file1.txt"". What this means is that .\folder2\file1.txt does not get installed from the cabs of the msi but installed directly from its first install directory.

In other words the .\folder1\file1.txt is copied to .\folder2\file1.txt.

Hopefully that hasn't confused you too much :-).

The next step is to do this.

As with the first guide I wrote you create your feature structure with the HKCU feature at the top of the tree. You then do this.

HKCU - (CurrentUser components)
-
- Complete Feature (remainder of app)


We now create a folder under [INSTALLDIR] or ""C:\program files\%appname%\_user""or whatever naming convention you like. I like ""_user"". We then add any files into this folder that we would like to be delivered to the users profile. For example if you want ""C:\documents and settings\%username%\application data\file1.txt""then we would create the following.

""c:\program files\%appname%\_user\application data\file1.txt""and so on.

For each file that you want to be healed by this method you need to have the same file delivered to ""C:\program files\%appname%\_user""

Once you have completed this you then add those same files again into the normal locations of ""c:\documents and settings\%username%""however this time the duplicate file table comes into play!!!. These files that are being added for the 2nd time are recognised as already being in the package and the follow the same rules as above with the duplicate file table. Therefore they have entries in the duplicate file table instead of the file table. This also means that these files are healed from the local machine and not from the MSI.

This has a few benefits, one is that you do not require the MSI to be present during healing time. So if you haven't got a connected source it gets around that issue (mind you I am not saying don't use [SourceList]) Its just a workaround if needed.

Now the final touch is to move all the components that were created during this step into the HKCU feature, my preference is to put the files in the same component as the HKCU registry entries that were created via the first guide.

Therefore you would have the following configuration.

HKCU - CurrentUser (component)
- Contains = HKCU registry
- = Duplicate File infomation


- Complete
- All other components

This means that HKCU is at the top of the tree and contains both the CurrentUser components containing the HKCU registry entries. And the duplicate file table entries are in the same component.

The complete feature just contains the main application.

Putting it all together.

When you run the application and a user has not logged on before the HKCU entries are not present. Therefore when advertising is run from the complete feature the Complete feature is checked, all component keypaths are checked if something is missing from the Complete feature it is healed in its entirety. As per normal the MSI will then step up the tree and run the checking functionality as per before. However in this instance as the advertising is downlevel from the HKCU feature the healing process changes slightly and steps into what is classed as Component level healing. Therefore if a keypath is missing only the single component is healed and not the entire feature. This is the reason why I like to put the duplicate file info into the same component as the HKCU registry entries.

If you delete the HKCU entries when advertising is next run it will put back both the HKCU entries and the files as they are in the same component as the HKCU keys.

Or move all the current user registry entries and files to the same feature at the root level (actually I am not sure if the feature HAS to be at the root). You cannot do this with a transform but you can do it if you can successfully edit the MSI. Since you are using Wise you'll probably have to turn off the recompile option if all the files for the MSI are inside the MSI. Then when the user logs in the MSI should populate the user profile with the per-user file and registry entries.

When use deploy software to computers, the system account is used and so all profile settings are set in the system profile.

When you want to have these things in the logged-on user profile you have to distributed this program to your users. Don't know your Group Policy, but useally Elevated Priveleges, are nessecary.

I have read the information in this thread with great interest. I am currently trying to get files in my package to copy to the USERPROFILE location (with no success so far).

I have created a component with a file in my installdir. And then made a duplicatefile entry for the userprofile copy. I have had to make the duplicate file entry by manually entering the information in the table. This is because if I just re-add the same file to the second location it creates it as a seperate file tabe entry and not a duplicate file entry.
I am using Instalshield 10.5 btw.

I know the duplicatefile entry is correct because the installer is getting the file in his userprofile.

Currently only have 2 components in this package under one feature.

Comp 1 has the application exe and the advertised shortcut
Comp 2 is the instaldir copy of the file + the HKCU keypath (this is also the component asscoiated with the duplicatefile entry)

Am I missing something here?

Thanks



Got it working....I took a closer look and did not have the registry key as the key path. Once I set that the healing worked.
Happy Days!

Hi everybody...
Im a new member ..and new to packaging too...This site has a loot of tricks and tips to be employed in repackaging apps..thanks to everyone

Hi jmcfadyen

Ur mail was very informative....Thank you.

np ..

emuringer sorry i completely missed your post. As for the reg key bit everyone always misses that for some reason. Perhaps I never wrote it clear enough i haven't read it in a few years now.

I read jmcfadyen's post with great interest and the technique works awesomely well for getting files into the USERPROFILE area.

One question I had was on self-healing of files in the USERPROFILE area. We have an application for which we have a enterprise license. The license file needs to go into the Application Data directory of the user profile for each user. I have used jmcfadyen's technique to get the file in there and all is working fantastically well, until someone deletes the file. Due to the fact that the key path is a registry value, not the file itself, the application does not self-heal the file, and the user is running unlicensed.

I tried making the key path to the "CurrentUser" component the file itself, but that did not work.

Any help or advice would be greatly appreciated.

Try using AppSearch for finding the file and if found the property you define will be set (ex. MY_PROPERTY).
Then have a condition that removes the registry keypath for the condition if the file is missing (ex. NOT MY_PROPERTY).
Make sure to have entrypoints for broken components to be checked.

Won't that only work at install time? What if the file is deleted after installation?

Why doesn't it work if I just set the file to be a key file?

Best practices is to use a HKCU registry entry for a file located in the user's profile.
However you can still use a file as a keypath but you will get an ICE during validation, just have that in mind.

If the user who is running the entrypoint is using an admin-account the component (file) will not be found as broken. Any admin-user are allowed to read other user's files stored under their profile so that's why a registry entry is used instead as they are not loaded until the user is logged in. If your users are not local admins then you don't anything to worry about while having a profile file set as keypath.

the reason you need to use the registry key as the keypath is because when files are used as keypaths full path is written to the registry.

this post shows where these keys are written
http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!136.entry

using that information when create a component where the file is the keypath you get this written to the suggested location in the registry (see post for details)

the value will show as

c:\documents and settings\john\application data\file.txt

other users may not have access to this location unless they are admins as Kim (AngelD) stated.

for this reason the file cannot be used as the keypath because the file is not present for all users as locked down users will not have access to the path. By using the hkcu key the same item is present for each user.

Although I haven't tested Kim's plan i think it will work in your case. (using appSearch )

I have a problem with NetOP MSI-package as well. We have to distribute 2 files to [AppDataFolder]. However when a selfrepair triggers the installer checks the last users path and not the current user path in AppDataFolder. And the current user doesnt have any permissions in the last user appdatafolder.

So I have tried to follow the guide with a HKCU feature with a component under it, containing a HKCU reg value which is keypath, and the two files in the same component. Before that I added the files to a folder i created under the installdir, named _user.
The entries weren´t added to the duplicatefile table automatically though so I tried to add them manually. Maybe I did this part wrong? Because I´m unable to install the msi with the mst I just created. Errorcode 2709.
I added this under DuplicateFile:

Filekey: comprof.ndb
Component: AllOtherFiles
File: comprof.ndb
DestName: <empty>
DestFolder: [AppDataFolder]Netop\Netop Remote Control\Guest

And the same for another file.

The files are added to AppDataFolder in a component named: "AppData". I dont really see the connection between "AppData"-component and the files? Am I doing something wrong?

David,

there is no need to duplicate the files in the Installdir. Just the file entries in the AppData folder should suffice, in combination with the HKCU keypath.
A few points to keep in mind for these kinds of scenarios

1) make sure you do a per-machine install of the package and not a per-user one (ALLUSERS property should be 1)
2) in order to copy the files to the profiles during the repairs, the users should have (read-)access to the original location from which the msi was installed. Otherwise Windows Installer will complain about not finding the original installer for the product and the repair will fail. This is because the locally cached version of the msi in <Windir>\Installer does not contain the files of the package.
3) in order to make sure the selfheal only repairs the impacted files, make sure you structure your features correctly. For more info on this have a look at this thread.

Rgds,

PJ

I always use per machine installations with ALLUSERS=1.
And yes the error with not being able to reach the original MSI is handled so that´s not the issue either.
I have tried to follow the guide that you are referring to. I create a parent feature to the whole featuretree and name it HKCU. Then I create a component in that feature with the HCKU entry to trigger self repair and the files and folder which goes under AppDataFolder. The keypath is set on the reg value.

Maybe I didn´t mention it but at installation time the AppDataFolder being used is the systems account and then somehow that path is saved when another user starts up the application. Instead of that users AppDataFolder.

I finally got it working now, I don´t know why it didn´t work later though.
I put the regentry and files in the same component and put the regkey in HKCU as keypath.