Windows Installer repair issue for per-user folders/files
Good day,
I know this has already been discussed to some extent on these forums, but no working solution except manually implementing .vbs scripts has been mentioned, still looking for any alternative way to ensure that repair works, see below description.
Description:
Windows Installer does not repair files in per-user directories, such as [AppDataFolder], when initial installation is performed using system account (for example - distributing the package through SCCM or using psexec) and repairing under a user with administrative privileges (limited user repair works fine).
Example.
.msi installation installs a custom .xml configuration file to "[AppDataFolder]". We're installing .msi by using psexec /s. log output:
When a user with administrative credentials accesses the advertised shortcut repair is run on the component that has the .xml configuration file, event viewer has an entry about this.
The verbose repair log file shows the following entry:
Limited user repair log reads:
Your suggestions will be very much appreciated.
I know this has already been discussed to some extent on these forums, but no working solution except manually implementing .vbs scripts has been mentioned, still looking for any alternative way to ensure that repair works, see below description.
Description:
Windows Installer does not repair files in per-user directories, such as [AppDataFolder], when initial installation is performed using system account (for example - distributing the package through SCCM or using psexec) and repairing under a user with administrative privileges (limited user repair works fine).
Example.
.msi installation installs a custom .xml configuration file to "[AppDataFolder]". We're installing .msi by using psexec /s. log output:
MSI (s) (D8:F0) [15:19:01:214]: Executing op: FileCopy(SourceName=SETTIN~2.CON|customXML,SourceCabKey=customXML,DestName=customXML,Attributes=16384,FileSize=2633,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=58982400,HashOptions=0,HashPart1=-1992414570,HashPart2=1238809189,HashPart3=-80616146,HashPart4=146746036,,)
MSI (s) (D8:F0) [15:19:01:214]: File: c:\WINDOWS\system32\config\systemprofile\Application Data\customXML;
To be installed; Won't patch;
No existing file
MSI (s) (D8:F0) [15:19:01:214]: Source for file 'customXML' is compressed
MSI (s) (D8:F0) [15:19:01:230]: Note: 1: 2318 2: c:\WINDOWS\system32\config\systemprofile\Application Data\customXMLWhen a user with administrative credentials accesses the advertised shortcut repair is run on the component that has the .xml configuration file, event viewer has an entry about this.
The verbose repair log file shows the following entry:
MSI (s) (D8:E4) [15:22:27:667]: Executing op: FileCopy(SourceName=SETTIN~2.CON|customXML,SourceCabKey=customXML,DestName=customXML,Attributes=16384,FileSize=2633,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=16908288,HashOptions=0,HashPart1=-1992414570,HashPart2=1238809189,HashPart3=-80616146,HashPart4=146746036,,)
MSI (s) (D8:E4) [15:22:27:667]: File: c:\WINDOWS\system32\config\systemprofile\Application Data\customXML;
Won't Overwrite; Won't patch;
Existing file is unversioned and unmodified - hash matches source fileLimited user repair log reads:
MSI (s) (78:8C) [15:26:27:406]: Executing op: FileCopy(SourceName=SETTIN~2.CON|customXML,SourceCabKey=customXML,DestName=customXML,Attributes=16384,FileSize=2633,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=16908288,HashOptions=0,HashPart1=-1992414570,HashPart2=1238809189,HashPart3=-80616146,HashPart4=146746036,,)
MSI (s) (78:8C) [15:26:27:406]: File: c:\Documents and Settings\test\Application Data\customXML;
To be installed; Won't patch;
No existing fileYour suggestions will be very much appreciated.
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
anonymous_9363
13 years ago
- You should edit the log extracts so that they're enclosed in CODE tags: it makes the post easier to read.
- I'd guess that you have the file being installed to the System user's profile: vanilla users won't have access to that, hence the failure. That's not how self-repair works. Rather than repeat it here, Google for John McFadyen's blog on self-repair: that explains everything.
- I'd guess that you have the file being installed to the System user's profile: vanilla users won't have access to that, hence the failure. That's not how self-repair works. Rather than repeat it here, Google for John McFadyen's blog on self-repair: that explains everything.
Posted by:
GrGrGr
13 years ago
ORIGINAL: VBScab
- You should edit the log extracts so that they're enclosed in CODE tags: it makes the post easier to read.
- I'd guess that you have the file being installed to the System user's profile: vanilla users won't have access to that, hence the failure. That's not how self-repair works. Rather than repeat it here, Google for John McFadyen's blog on self-repair: that explains everything.
1) Ok. ;)
2) File is installed in per-user folder, but when repair is run as admin after the initial install being run as SYSTEM - the files are repaired in system profile folders, not the admin user. I've googled the blog - it is really useful, thank you. But the issue is still not solved for me, would appreciate more suggestions. ;)
Posted by:
pjgeutjens
13 years ago
Did you remember to give the components that contain per-user files keypaths that are HKCU registry keys?
Posted by:
AngelD
13 years ago
Doesn't look that way!
Installed file
c:\WINDOWS\system32\config\systemprofile\Application Data\customXML
Repaired file
c:\Documents and Settings\test\Application Data\customXML
Installed file
c:\WINDOWS\system32\config\systemprofile\Application Data\customXML
Repaired file
c:\Documents and Settings\test\Application Data\customXML
Posted by:
zzpack
13 years ago
I´m too having problems with this, on iTunes. The error Note: 1: 2318 is in the log file, for the user part.
But the repair behaves different in a way i don´t comprehend.
I have put "iTunesprefs.xml" (with a HKCU dummy key set as key path in that particular component)
into a .mst and it works fine, installing as administrator. When I log on as a new user, the repair starts.
For a brief moment I can see that the installer copies the file "iTunesprefs.xml" (with the older date)
to the correct destination. But then it is immediately overwritten with a fresh "iTunesprefs.xml" as
iTunes starts.
Any tips how to tackle this problem?
But the repair behaves different in a way i don´t comprehend.
I have put "iTunesprefs.xml" (with a HKCU dummy key set as key path in that particular component)
into a .mst and it works fine, installing as administrator. When I log on as a new user, the repair starts.
For a brief moment I can see that the installer copies the file "iTunesprefs.xml" (with the older date)
to the correct destination. But then it is immediately overwritten with a fresh "iTunesprefs.xml" as
iTunes starts.
Any tips how to tackle this problem?
Posted by:
itolutions
13 years ago
if you want to overwrite any non-PE file. You should at least set "version" field in File table + set overwrite flag for file (see MSDN).
Posted by:
Matias M Andersen
13 years ago
I log on as a new user, the repair starts.
For a brief moment I can see that the installer copies the file "iTunesprefs.xml" (with the older date)
to the correct destination. But then it is immediately overwritten with a fresh "iTunesprefs.xml" as
iTunes starts.
Sounds like iTunes is detecting an issue in the XML file and decides to create a new one. Procmon might be helpful to dig out the problem.
My own experience with iTunes is that modifying only "Properties" and "Adminflags" will save you hours and hours of headache, it almost seams like apple don't "trust" Windows (-Installer) to get the job done ;).
/Matias
Posted by:
zzpack
13 years ago
ORIGINAL: itolutions
... + set overwrite flag for file (see MSDN).
I want the file in my .mst not to be overwritten by the installation. So I don´t get your point here...?
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.