Wise Packaging

A Guide to MSI Healing 

09-17-2007 05:38 PM

This document describes several methods of MSI healing (repair) techniques to populate HKCU keys for other users.

The best methods are documented first with other alternative ways following later.

Method I

Active Setup Method:

This is one of the best practices in MSI Packaging which uses the native Active Setup behavior of Windows XP and Windows Installer HKCU keys repair techniques.

One should follow these specific steps while using this method:

  1. Make sure all HKCU keys in the MSI Package that we are creating are under structured component names like CurrentUser, CurrentUser1, etc.
  2. The Package author should be able to judge and set the key path for that Component properly.
  3. As per Microsoft Component guidelines, make sure the components containing HKCU keys are as few in count as possible, for example only one component (CurrentUser) with all HKCU keys with best key path set is the best practice.
  4. Create the following registry keys under the main hive:
    HKLM\Software\Microsoft\Active Setup\Installed Components\{GUID of the MSI}
    ComponentID=PackageName_ComponentName
    StubPath=[SystemFolder]msiexec.exe /fu {Product Code of the MSI} /q
    Version=ProductVersion
    
    

The principle of Active Setup behavior is when a new user logs on for the first time, then the Active Setup will perform a checksum between HKLM\Software\Microsoft\Active Setup\Installed Components\{GUID of the MSI} and HKCU\Software\Microsoft\Active Setup\Installed Components\{GUID of the MSI}; and if the GUID is not present under HKCU, then it performs all actions which are under that main hive (StubPath, Version) and populates the GUID under HKCU. The main Advantage of Active Setup is it performs an action only once per User with the Checksum behavior by matching the entries under HKLM and HKCU.

Method II

Active Setup Method:

This method can be used for both MSIs and Non-MSIs (SMS or WSE Script executables).

Create a silent SMS script or Wise Script (for eg:-Script.exe) which will create the needed HKCU registry entries for the application. Then place that EXE in the Application [INSTALLDIR] in your MSI Pkg or Executable binary memory.

Then create the following additional registry entries in the MSI Package or within the Script whichever is applicable:

HKLM\Software\Microsoft\Active Setup\Installed Components\{GUID or AppName}
ComponentID=PackageName_ComponentName
StubPath="[INSTALLDIR]Script.exe"
Version=ProductVersion

The Active Setup performs the regular checksum (comparison of entries under) HKLM and HKCU and if the respective unique GUID or AppName is not present under HKCU hive, then it will perform all actions (StubPath, Version) and populates the GUID or AppName under HKCU hive too. This is only once per user -- for the first time -- to populate HKCU hive.

Method I and method II use the Active Setup feature, and One should understand the advantages of one over the other. Method I requires source resiliency to populate HKCU keys, where as method II does not require this as the Script.exe does everything.

Method I and method II can be used in any scenarios like if Advertised entry points are present or NOT present.

Method III

Windows Installer repair method with SMS or Wise Script:

Typically the body of the script will be;

Check for the existence of a Flag key under HKCU\Software\Company Name\Applications\{ProductName][productversion] Installed=True

If the key exists then quit else initiate the Windows Installer repair to populate HKCU keys:

Msiexec /fu {Product Code of the MSI} /q

And edit and create registry key (Basically a Flag Key which can be any key which your firm adopts) HKCU\Software\XYZ*\Applications\{ProductName][productversion] Installed=True End * XYZ= Name of the organization \ Company And keep this script exe in HKLM\Software\Microsoft\Windows\CurrentVersion\Run.

One should keep in mind that the /p switch can also be used to repair files (populate) user-specific data (Profile data) with the following syntax:

Msiexec /fup {Product Code Of the MSI) /q

Method IV

Silent empty exe with valid shortcut:

Create a silent empty exe and its Advertised shortcut and place both of them in the Application [INSTALLDIR]. And use them as entry points to trigger healing to populate HKCU keys.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

12-24-2011 04:42 AM

you can use :- REG LOAD KeyName FileName

command to load registry from other users HKCU.

ex. REG LOAD "HKU\TEMPreg" "C:\SYS\profiles\userName\NTUSER.DAT"

You can get list of user accounts present on target computer under following registry key.

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

you can loop through it and load HKCU registries...

for more detail follow the link

http://www.appdeploy.com/messageboards/tm.asp?m=56311

 

03-18-2009 12:33 AM

dont use regedit to repair things its a bad call.

most likely to be locked from corporate networks and limited access users, these methods should only be used when a MSI self heal (not described anywhere here above cannot be used)

 

03-16-2009 08:25 PM

You can also create an HKCU Feature, set this as the top level parent feature and dump all CurrentUser entries into this feature. This ensure that all CU entries are checked when an advertised entry point is triggered.

03-11-2009 07:26 PM

I apply this tricks, and was a litlle bit surprise when testing the removal process... Except I miss something, (allways possible), I see the Active Setup in # HKCU as long as the other HKCU regitry keys installed this method, are still there after running the /X {<Guid>}. I can run the remove for the 1st user, but not any more for the 2nd. Of course, the MSI is not there any more to process the deletion for the other users!

Such a mess to install or remove application: the only workaround I find, is to script  registry deletion in another Active setup package. But how can I delete this deletion package ???

Ok, I should have something wrong, it is not possible this could be such a complicated to add or remove USER registry ? Yes, it is ?

08-18-2008 01:02 PM

Small Note on Active Setup.
Instead of creating a WiseScript you can also use regedit.
- Create a .reg file with the HKCU keys.
- Add this to your package.
- Saves a little time.....

HKLM\Software\Microsoft\Active Setup\Installed Components\{GUID or AppName}
ComponentID=PackageName_ComponentName
StubPath==[SystemFolder]regedit /s \[INSTALLDIR]\HKCU.reg"
Version=ProductVersion

08-18-2008 04:37 AM

I have few problems with Active Setup;
- Can you ensure that the user-based installation process completed successfully
- How does this affect enterprise level conflict management?
- Will all users have the correct privileges to run the local process
- Do I have full control of the process, once initiated in the user environment
- Is there any real/pragmatic dependency checking to ensure that Active Setup process initiates correctly?
- How are custom actions handled in the local cached MSI?
Also, wasn't Active Setup a really common vector for malware a few years back?

08-15-2008 11:53 PM

Granted, you could set the self healing to be triggered by advertised components in the package, but what if you don't have any? I was looking for this solution a while back and this is exactly what I am looking for for several applications that I have that deliver user specific customizations to packages that I can't (or don't know how to) trigger a healing event with the short cuts.
I'm also going to use this in my company’s efforts to migrate from Novell to AD. We have to scrub out some user specific data (post Zen, Novell client and NICI uninstall) that is in HKCU and this was the most efficient way to do it on a per-user instance.
I can also see us using this in setting up any user specific customizations in our image. I have seen some applications do this, but I didn’t know how it was done.
Also, I went to the WPS Advance training and I tried to get this information from the instructor (cuz I knew it was possible, I had seen other pkgs do this) and he didn’t come up with this answer. Looking back, I’m somewhat disappointed at not getting the answer I was looking for and the fact that he didn’t know this technique.
Thanks for the article!

09-19-2007 11:14 AM

I understood the obvious abstract of your article and comment was supplementary to your article coz thought it was missing.
As if you allow user to repair package using Add remove program, even that will help. thats the simplest solution to heal the USER data.
But some time Group policy don't allow user to access ARP.
Even Like to add that you just mentioned about HKCU keys.It means only registries.
But this is not true, Even user profile files also get self heal with this. I think you can revise it.
Just Like to know the self healing is only for local user. But if the files are part of roving user then? what will be the resolution?

09-18-2007 08:38 AM

Thanks for the comment .
This Article describes only the self heal techniques .. This is obvious that it will be used only when there is user data and no entry points in the application like advertised shortcuts , file associations etc. This techniques are used only to populate the user data whenever the user logs on to the machine.
Cheers !!

09-18-2007 07:03 AM

Article is good and suffice every required information for self healing.
But Objective for self healing is missing. I mean there is no explaination about why we need to do this as windows installer provides self healing.
Just like to add thats above self healing techniques are useful when if package contains user data and there is no advetise entry point available for the application.
Else there is no need for forceful self healing. When you launch advertise shortcut it will automatically get self repair.
So to install user data for every user we need to look for forceful MSI healing.

Related Entries and Links

No Related Resource entered.