Self-healing per-user settings causing headache...
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.
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
Answers (3)
Please log in to answer
Posted by:
MyITGuy
20 years ago
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
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
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:
If anyone can offer any light on this subject or can verify its validity, PLEASE...PLEASE reply.
Thank you much in advance.
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
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.
Posted by:
WiseUser
20 years ago
User-profile based components should have a registry keypath - not a file.
Check out ICE38.
Check out ICE38.
Posted by:
MyITGuy
20 years ago
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".
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".
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.