I am repackaging an application and using self-healing. The problem that I have is with using the USERPROFILE variable. When the application attempts to self-heal a missing file, its attempting to use the location of the originally installed file. This is not preferred, nor logical.

Scenario

Copying a file called 'properites' to the [USERPROFILE].java directory using self-healing.

The initial installation is done via Administrator (for this case, ADMIN) and works flawlessly.
When an ordinary user logs in (for this called STDUSER) and they click on the Advertised shortcut, the self-healing process attempts to find the file C:\Documents and Settings\ADMIN\.java\properties. Because STDUSER does not have access to the file, its never found (NOR should it be looking there for the file) and the self-healing process takes place every time after that.

Shouldn't the self-healing process be using the USERPROFILE variable, not the name returned by the variable upon the initial installation?

Does anyone know why this is occuring and if/when the problem can/will be fixed?

Much thanks in advance.

MyITGuy - Automating your life to make my life easier.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I have found the issue and am working to test whether there is a bug in Windows Installer or if its a packaging issue. (I'm leaning toward Windows Installer.)

Standard Self-Healing

I have tasked to repackage Oracle JInitiator 1.1.8.14 due to a checkbox needing to be unchecked within the configuration for Oracle JInitiator 1.1.8.14 . The checkbox setting is held in a file called 'properties', located in the current users profile directory under the directory '.java'.

I repackaged Oracle JInitiator 1.1.8.14 using Installshield AdminStudio 6. When repackaged, the installation had one Feature with all Components located under it. I opened the Component named 'RegistryData_User' and added the 'properties' file (which is configured with the correct checkbox settings). I made the 'properties' file a Primary Key. I then Advertised the shortcut for the Componet 'jrew.exe'. I then compiled the MSI.

Results

  • As an Administrator on the machine, I installed Oracle JInitiator 1.1.8.14. Oracle JInitiator 1.1.8.14 worked without issue.
  • As a standard user on the domain (locked down), I clicked on the Advertised shortcut. The application self-healed and Oracle JInitiator 1.1.8.14 worked without issue.

Small-Footprint Self-Healing

Per documentation on creating a smaller self-healing process (More Information), I created a new Feature called 'PerUserSettings' and moved the original Feature under it. I removed the 'RegistryData_User' Component from the original Feature and added it to the 'PerUserSettings' Feature. I then compiled the MSI.

Results

  • As an Administrator on the machine, I installed Oracle JInitiator 1.1.8.14. Oracle JInitiator 1.1.8.14 worked without issue.
  • As a standard user on the domain (locked down), I clicked on the Advertised shortcut. The application self-healed BUT Oracle JInitiator 1.1.8.14 did not work.

Issue

Small-Footprint Self-Healing does not work as expected.


More Information

PLEASE NOTE: I'M STILL RESEARCHING THIS ISSUE. THE INFORMATION FOUND HERE IS PRELIMINARY.

When using Small-Footprint Self-Healing, The process kicked off by the Advertised does not pull the USERPROFILE variable, but instead uses the original installers USERPROFILE variable. If the user does not have permissions to read the original location, the self-healing process attempts to reinstall the feature.

One portion of this issue that I have not been able to resolve: The self-healing process does create the '.java' directory, but never places the 'properties' file in the directory.

As a standard user, the self-healing process registers the following Windows Event Log messages:

  • Event Type: Warning
    Event Source: MsiInstaller
    Event Category: None
    Event ID: 1004
    Description:
    Detection of the product '{ProductCode}', feature 'FeatureName', component '{ComponentCode}' failed. The resource 'C:\Documents and Settings\OriginalInstallerProfileName\.java\properties' does not exist.

    For more information...

  • Event Type: Warning
    Event Source: MsiInstaller
    Event Category: None
    Event ID: 1001
    Description:
    Detection of product '{{ProductCode}', feature 'FeatureName' failed during request for component '{{ComponentCode}'

    For more information...

If anyone can offer any light on this subject or can verify its validity, PLEASE...PLEASE reply.

Thank you much in advance.
Answered 11/16/2004 by: MyITGuy
Yellow Belt

Please log in to comment
0
User-profile based components should have a registry keypath - not a file.

Check out ICE38.
Answered 11/16/2004 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
I would agree with that if the component never installed correctly. But it did. It only didn't when I moved it to another feature.

Also, as for this project even, I don't have registry information to release to the current user. Nor do I want to add bogus information just for getting the package to work.

Putting that aside, I did test placing a registry setting into the HKCU key and set it as the Primary Key.

Guess what??...it worked. Thank you much for assisting.

One last thing, it is a bug! I say that only because a Primary Key is a Primary Key, it shouldn't do lookup and repair ONLY on registry setting. It should do it on any Primary Key specified by the installer. Like I said, I only want to put a file in, not start filling the registry with bogus information.

Thank you again for the work-around. (Even if Microsoft states it as "working as designed".
Answered 11/16/2004 by: MyITGuy
Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity