Hey guys!!!

TGIF! hehehehe

Anyway, here's my problem.... Once again, I have a package that deploys some files in My Documents folder. The files are in the My Documents part of Wise in my Installation Expert.

Now, I did a ActiveSetup with msiexec /fua switch, making sure everything should be there for all my users. When I test it with my administrator user, works. I log in with my test user, still working. I do the same exact test under Windows 2000, still working.

That was conclusive enough for me. But here's the catch: when I install my package on a production machine (same environment as my 2nd test machine) the file isn't copied in My Documents of that User.

Now, having learned my lesson, I already did copy the Windows NT/2k/XP install shield lines to set user profiles.

I also have logged my self healing. (I ran the StubPath command manually, adding log parameters). Here's what I have that seems to be pertinent to my file:

MSI (s) (B8:38) [13:25:57:447]: Component: Default.WSP; Installed: Local; Request: Local; Action: Local
MSI (s) (B8:38) [13:26:00:531]: Executing op: ComponentRegister(ComponentId={B8EF2822-74EF-4144-8789-8B72847716CB},KeyPath=C:\WINNT\Default.WSP,State=3,,Disk=1,SharedDllRefCount=0,BinaryType=0)
MSI (s) (B8:38) [13:26:12:578]: Executing op: FileCopy(SourceName=Default.WSP,SourceCabKey=Default.WSP,DestName=Default.WSP,Attributes=16384,FileSize=5945,PerTick=32768,,VerifyMedia=1,,,,,CheckCRC=0,,,InstallMode=20971520,HashOptions=0,HashPart1=-1797855051,HashPart2=1295704441,HashPart3=-662232289,HashPart4=2143812
MSI (s) (B8:38) [13:26:12:578]: File: C:\WINNT\Default.WSP; Overwrite; Won't patch; REINSTALLMODE specifies all files to be overwritten
MSI (s) (B8:38) [13:26:12:578]: Source for file 'Default.WSP' is compressed
MSI (s) (B8:38) [13:26:12:588]: Verifying accessibility of file: Default.WSP
MSI (s) (B8:38) [13:26:12:608]: Note: 1: 2318 2: C:\WINNT\Default.WSP


What am I missing here for this to be working oddly as it is?

Thanks guys!

Steph
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
Error 2318 means 'File Not Found' http://itninja.com/question/help-with-msi-140657

which M A Y well be the problem...
Answered 05/09/2008 by: VBScab
Red Belt

Please log in to comment
0
i think the souce msi from which you have installed is not available for the msi to repair. Just make sure that you have msi available for user also so that successfull repair can happen.
Answered 05/09/2008 by: blacklisted_packager
Orange Belt

Please log in to comment
0
you need to find the component which contains the file you mentioned.

then create a dummy HKCU key in that component. Then mark the new registry key as the keypath to the component. This because windows installer is transactional in its deployment of files.

for example if file is YOURFILE.TXT

It records the deployment location as being c:\doc & settings\FirstUser\YOURFILE.TXT as such repairs attempt to go back to that location. The result some users do have access some dont.

In order to make this happen correctly for each user you need to make a dummy HKCU key as the keypath. As such the deployment of the remaining files get enum'd under the current context of %userprofile%\yourfile.txt
Answered 05/11/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
0
ORIGINAL: jmcfadyen

you need to find the component which contains the file you mentioned.

then create a dummy HKCU key in that component. Then mark the new registry key as the keypath to the component. This because windows installer is transactional in its deployment of files.

for example if file is YOURFILE.TXT

It records the deployment location as being c:\doc & settings\FirstUser\YOURFILE.TXT as such repairs attempt to go back to that location. The result some users do have access some dont.

In order to make this happen correctly for each user you need to make a dummy HKCU key as the keypath. As such the deployment of the remaining files get enum'd under the current context of %userprofile%\yourfile.txt





Thanks for the tip, I'll give it a try right this morning.

One thing I still don't get though is why on a test W2K machine, the file is on all tested profiles, and on a production machine, it isn't copied on my user's profile. As VB pointed out, the file *could* be not found, but it's contained in a .CAB file which the user has access in read & execute... So I'm still stumped about that one...
Answered 05/12/2008 by: Fau
Senior Purple Belt

Please log in to comment
0
Check for any component condition in combination with the VersionNT property.
Answered 05/12/2008 by: AngelD
Red Belt

Please log in to comment
0
Hey John,

Seems this works #1. I have a compenent very conveniently named "Default.WSP" (which was the file I couldn't get in my profile), added in that component a HKCU key named Dummy, with a value 1 and set it as a key path, and compiled.

Relaunched the installation on my client's computer, worked fine.

Now, is there something out there I could read, or maybe a quick explanation for my personal information here... I'm not sure I userstand the explanation of:

As such the deployment of the remaining files get enum'd under the current context of %userprofile%\yourfile.txt

Thanks guys again!
Answered 05/12/2008 by: Fau
Senior Purple Belt

Please log in to comment
0
Now, is there something out there I could read, or maybe a quick explanation for my personal information here... I'm not sure I userstand the explanation of:

When a component is "installed" it will be registered along with the keypath.
If a file is installed in a profile the keypath will first point to the installers path ex.
C:\Documents and Settings\AngelD\Application Data\Default.WSP

When a self-check occur due to an entrypoint is executed each component's keypath will be checked and if missing or corrupted a repair will be triggered. A user that is a local admin he also has read permissions on other users profile folder including the user who installed the MSI or the user whom a repair occured previously for. So when the keypath is checked (C:\Documents and Settings\AngelD\Application Data\Default.WSP) (retrieved by the MsiGetComponentPath function) it will be found under my profile so the component holding the Default.WSP file isn't found as broken.

When a non-admin user executed an entrypoint the component's keypath will be retrieved (C:\Documents and Settings\AngelD\Application Data\Default.WSP) and verified. In this case the user do not have access to my profile thus the file isn't found and the component will be "set" as broken and a repair will occur. The "new" component registration "metadata" (keypath) will be written for the component into the registry and in this case changed to ex. C:\Documents and Settings\NON-ADMIN-USER\Application Data\Default.WSP.

Hope that helps abit.
Answered 05/12/2008 by: AngelD
Red Belt

Please log in to comment
0
this goes into more detail of what AngelD just explained.

http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!136.entry

this expands on self healing somewhat.

http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!123.entry

if you get really bored read the lot it will be worth the effort.
Answered 05/12/2008 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
0
ORIGINAL: jmcfadyen

this goes into more detail of what AngelD just explained.

http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!136.entry

this expands on self healing somewhat.

http://johnmcfadyen.spaces.live.com/blog/cns!9DD01136FC094724!123.entry

if you get really bored read the lot it will be worth the effort.



Bored? Rarely.

But reading stuff like this is really usefull, so I'll start right away!

Thanks again!
Answered 05/13/2008 by: Fau
Senior Purple Belt

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