Software Deployment

You will have to just place the keys in HKCU and as each person runs the app it will do a mini self repair and add the keys for them.

You should add the keys as their own component separate from the HKLM and HKCR keys.

You might also like to read this article about HKCU keys because it works very well in my testing and I have adopted it as a standard practice.

http://www.myitforum.com/inc/upload/8446currentuser.txt

Hi,
the procedure is well described in WISE Knowledgebase article #1438. I have used the
method in some of my packages with great success.
Good luck.

oh by the way I wrote a second part to that article.

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 at http://www.itninja.com/question/current-user-self-healing . 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 folder 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. This is because the duplicate file components do not have keypaths therefore technically dont have a healing reference. Hence putting them in the HKCU component ensures a heal for each new user.

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.

This stuff is pretty hard to put into words so if you have any questions please ask, as this may help both you and I.

Note this is not the only way to heal files in user profiles but its a way that I find the cleanest as it requires no outside scripts or configuration.

thx

John McFadyen
huckey@mindless.com

Thanks John

I'll give that some testing and see how it goes in my environment.

Its nice to see you posting here as well :)

Would you recommend doing this for vendor supplied MSIs as well?

I wouldnt change a vendor msi with this sort of change unless you intend repackaging it.

This method can be (and has been) employed with vendor's MSIs. There are a couple of caveats though.
Firstly, ALWAYS use a transform rather than modifying the vendor's MSI.

For simple structures it is easy to re-arrange the vendors features so that you can create your own 'HKCU' feature above the vendor's installation.
This can be extended for multi-feature applications - just add a HKCU-n above each feature that contains advertised resources.

Of course, if the vendor's MSI is not well-structured or is extremely complicated, your chances of pulling this off successfully are fairly remote.

Does anyone know if the self-healing technique can be used successfully to map a drive under a users profile?

I have tried it out and it will enter the user keys correctly but it seems that the drive will not be visible to the user within explorer without restarting the explorer.exe.

Is there a better or easier way to do this?

Thanks