/build/static/layout/Breadcrumb_cap_w.png

Self healing MSI keeps putting user profile files into the systemprofile

Dear all,

Im packaging a program called GHS.
It needs to store some files in the userprofile directory which is offcourse no problem using the self healing (duplicate file) method.

Now when im finished compiling my MSI and run it manually on the target computer everything works fine.
Starting the program for the first time triggers the self healing part and all the files are being copied to the user profile directory.

When I silent install this msi using pc-exec from my own pc the install looks fine.
After a user then logins to the computer and runs GHS.exe the self healing part is triggered but this time all the files are copied to the systemprofile directory (C:\Windows\SysWOW64\config\systemprofile\ etc instead of C:\Users\<username>\ etc).

The target computer is a Windows 7 pc and I need a per machine (ALLUSERS = 1) install.

Thnx in advance!

p.s. Im using Wise Studio Package 8.0

0 Comments   [ + ] Show comments

Answers (12)

Posted by: naveen.packager 13 years ago
Green Belt
0
In silent install are the files are copied to the desired (C:\Users\<username>\) folder after installation in the account which it has been installed?

I think the reason is your type 51 custom action which sets USERPROFILE is present only in UI mode. If so copy that custom action to Execute Immediate sequence and try silent installation.
Posted by: pjgeutjens 13 years ago
Red Belt
0
Sander,

make sure of a couple things in your package:

1) ALLUSERS property =1, to do a machine-based install
2) the components that contain the user profile files should have keypaths that are registry keys in HKCU

The symptoms you describe make me think criterium 2 above is not met by your package. (since you mention putting ALLUSERS to 1)

Rgds,

PJ
Posted by: kuijkens 13 years ago
Senior Yellow Belt
0
I guess #2 of your checklist is indeed not met, although im not quite sure how to fix it.

If i create a registry key, lets say, "HKCU\Software\GHS\Path" with value "[ProfileFolder]GHSdata".
Now i cant select this registry key as keypath in the GHS.LF duplicatefile component.

What am i doing wrong here?
Posted by: pjgeutjens 13 years ago
Red Belt
0
Sander,

Assuming the component's install directory is somewhere in the userprofile, try setting a regkey that you add yourself, something like HKCU\Software\GHS\UserSettingsCopied = 1, as the keypath, this should be possible in your authoring tool.
The fact that this key will be missing for users will trigger the repair for each of them.

Also, I don't know if you're running silent repairs, but the users that repair the msi need to have access to its original installation location if you want the repair to put files into the profiles. If it's only registry keys you're ok without this access, but for files, the original MSI is needed.

Rgds,

PJ
Posted by: kuijkens 13 years ago
Senior Yellow Belt
0
Dear PJ,

The problem is not that the self healing does not trigger itself.
I already add a HKCU key "GHS=1" to trigger the self healing, but somehow the user profile folder is not recognized and it uses the systemprofile folder
Posted by: pjgeutjens 13 years ago
Red Belt
0
oops my bad,

what's the keypath for the components causing you grief?
Also, when you say 'duplicate file' method, could you clarify what you mean specifically?

If I'm not mistaken, as long as the files are in a correctly setup component, you don't actually need to use duplicate files.

PJ
Posted by: anonymous_9363 13 years ago
Red Belt
0
I was intrigued by the mention of the "duplicate file" method, too!
Posted by: kuijkens 13 years ago
Senior Yellow Belt
0
Just 1 file called GHS.LF needs to go to C:\Users\%username%\GHSdata
In Wise you can select the Destination Directory as Windows\Profiles\GHSdata

Normally this works just fine, have created many succesful MSI using this strategy.
Only this time the users profile directory somehow gets overruled and the msi uses the systemprofile directory.

Via the Duplicate File method you create the file in C:\Program Files\GHS\_user and then duplicate this file to C:\Users\%username%\GHSdata.
This way you always have a copy of the file ready on the local machine and therefore an network connection is not neccesary (just in case of).

The keypath of the GHS.LF file in the _user is just GHS.LF.
I cant select a keypath for the duplicate file, guess thats where it goes wrong...
Posted by: kuijkens 13 years ago
Senior Yellow Belt
0
@naveen

The ProfilesFolder custom action is also present in the Execute Immediate sequence
Posted by: pjgeutjens 13 years ago
Red Belt
0
Sander,

Ok, I found out what you mean by the 'duplicate file' method, as in the method described by John in this post. I have to admit I've never extensively used this method.

As for troubleshooting the issue, have you logged these repairs (system-wide logging on all Windows Installer transactions) to have a detailed look at the installation flow, focussing on directory and property resolution, and possible CA's messing with your directories.

PJ
Posted by: jmcfadyen 13 years ago
5th Degree Black Belt
0
ill be honest I didn't read all of this.. but the duplicate file fix works by using the keypath as an HKCU entry.

This works because the user path is resolved as part of costing. none of this was tested against UAC enabled machines I wrote this pre windows xp days.

I think hummingbird uses a similar technique successfully on windows 7. So I suspect the issue is with your profiles CA's.

log it and look for the ProfilesFolder action values and the user profile directories etc.
Posted by: kuijkens 13 years ago
Senior Yellow Belt
0
I have logged the repair and the installation looks normal.
The profilefolder property is set properly and nowhere is a referal to the systemprofile directory.

Besides that, the User's start menu (which is in the profile directory as well) is being installed as supposed.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ