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
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)
Please log in to answer
Posted by:
naveen.packager
13 years ago
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.
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
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
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
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?
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
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
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
Posted by:
pjgeutjens
13 years ago
Posted by:
anonymous_9363
13 years ago
Posted by:
kuijkens
13 years ago
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...
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
Posted by:
pjgeutjens
13 years ago
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
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
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.
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
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.