Hope this isn't a Profile problem again...
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
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
Answers (9)
Please log in to answer
Posted by:
anonymous_9363
15 years ago
Error 2318 means 'File Not Found' http://itninja.com/question/help-with-msi-140657
which M A Y well be the problem...
which M A Y well be the problem...
Posted by:
blacklisted_packager
15 years ago
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.
Posted by:
jmcfadyen
15 years ago
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
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
Posted by:
Fau
15 years ago
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...
Posted by:
AngelD
15 years ago
Check for any component condition in combination with the VersionNT property.
Posted by:
Fau
15 years ago
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:
Thanks guys again!
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!
Posted by:
AngelD
15 years ago
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.
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.
Posted by:
jmcfadyen
15 years ago
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.
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.
Posted by:
Fau
15 years ago
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!
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.