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:

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\customXML




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:

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 file




Limited 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 file




Your suggestions will be very much appreciated.
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
- 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.
Answered 01/25/2011 by: VBScab
Red Belt

Please log in to comment
0
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. ;)
Answered 06/07/2011 by: GrGrGr
Orange Belt

Please log in to comment
0
Did you remember to give the components that contain per-user files keypaths that are HKCU registry keys?
Answered 06/07/2011 by: pjgeutjens
Red Belt

Please log in to comment
0
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
Answered 06/07/2011 by: AngelD
Red Belt

Please log in to comment
0
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?
Answered 10/03/2011 by: zzpack
Orange Senior Belt

Please log in to comment
0
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).
Answered 10/03/2011 by: itolutions
Orange Senior Belt

Please log in to comment
0
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
Answered 10/03/2011 by: Matias M Andersen
Senior Yellow Belt

Please log in to comment
0
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...?
Answered 10/03/2011 by: zzpack
Orange Senior Belt

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