Setup.exe /s /f2"C:\Windows\SMSPkg\Logs\MiCOMS1V214_Setup.log" /v"ALLUSERS=1 REBOOT=REALLYSUPPRESS /lv C:\Windows\SMSPkg\Logs\MiCOMS1V214_MSI.log"

Am deploying an app with a response file. Now, when I do this via a batch file and launch, it works just fine. However launching the batch file or running this commandline via sms, results in the install dying. Anyone seen this b4 and know what might be the cause?

Log excerpt:

[font="courier new"]1: Standard project type, let scripting engine clean up setup files...skipping action
Action ended 12:59:50: ISSetupFilesCleanup. Return value 1.
MSI (c) (E8:40) [12:59:50:030]: PROPERTY CHANGE: Adding ISSETUP_UISEQUENCE_PROCESSED property. Its value is '1'.
MSI (c) (E8:40) [12:59:50:030]: Note: 1: 2262 2: Upgrade 3: -2147287038
MSI (c) (E8:40) [12:59:50:123]: Note: 1: 2262 2: ReserveCost 3: -2147287038
MSI (c) (E8:40) [12:59:50:123]: Note: 1: 2262 2: DuplicateFile 3: -2147287038
MSI (c) (E8:18) [12:59:50:280]: Entering MsiProvideComponentFromDescriptor. Descriptor: =_v`([font="courier new"]{G^@AYxj2P5WcqWFEATURE_ID>M5KDYSUnf(HA*L[xeX)y[font="courier new"], PathBuf: 2A6F0C8, pcchPathBuf: 2A6F0C4, pcchArgsOffset: 2A6F024
MSI (c) (E8:18) [12:59:50:280]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (E8:18) [12:59:50:280]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (E8:18) [12:59:50:358]: Entering MsiProvideComponentFromDescriptor. Descriptor: =_v`([font="courier new"]{G^@AYxj2P5WcqWFEATURE_ID>M5KDYSUnf(HA*L[xeX)y[font="courier new"], PathBuf: 2A6F0C8, pcchPathBuf: 2A6F0C4, pcchArgsOffset: 2A6F024
MSI (c) (E8:18) [12:59:50:358]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (E8:18) [12:59:50:358]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (E8:40) [12:59:50:420]: Entering MsiProvideComponentFromDescriptor. Descriptor: =_v`([font="courier new"]{G^@AYxj2P5WcqWFEATURE_ID>M5KDYSUnf(HA*L[xeX)y[font="courier new"], PathBuf: 12DB88, pcchPathBuf: 12DB84, pcchArgsOffset: 12DAE4
MSI (c) (E8:40) [12:59:50:420]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (E8:40) [12:59:50:420]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (E8:40) [12:59:50:420]: Entering MsiProvideComponentFromDescriptor. Descriptor: =_v`([font="courier new"]{G^@AYxj2P5WcqWFEATURE_ID>M5KDYSUnf(HA*L[xeX)y[font="courier new"], PathBuf: 12B448, pcchPathBuf: 12B444, pcchArgsOffset: 12B3A4
MSI (c) (E8:40) [12:59:50:420]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (E8:40) [12:59:50:420]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (E8:40) [12:59:50:436]: Note: 1: 2205 2: C:\WINDOWS\system32\CCM\Cache\PE100529.10.System\MiCOM S1 V2.14 - Software Tools.msi 3: ISAlias
MSI (c) (E8:40) [12:59:50:436]: Note: 1: 2228 2: C:\WINDOWS\system32\CCM\Cache\PE100529.10.System\MiCOM S1 V2.14 - Software Tools.msi 3: ISAlias 4: SELECT * FROM ISAlias
1: Ready to launch program block.
MSI (c) (E8:18) [12:59:58:796]: Entering MsiProvideComponentFromDescriptor. Descriptor: =_v`([font="courier new"]{G^@AYxj2P5WcqWFEATURE_ID>M5KDYSUnf(HA*L[xeX)y[font="courier new"], PathBuf: 2A6F0C8, pcchPathBuf: 2A6F0C4, pcchArgsOffset: 2A6F024
MSI (c) (E8:18) [12:59:58:796]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (E8:18) [12:59:58:796]: MsiProvideComponentFromDescriptor is returning: 0
MSI (c) (E8:18) [13:00:00:000]: Entering MsiProvideComponentFromDescriptor. Descriptor: =_v`([font="courier new"]{G^@AYxj2P5WcqWFEATURE_ID>M5KDYSUnf(HA*L[xeX)y[font="courier new"], PathBuf: 2A6EEAC, pcchPathBuf: 2A6EEA8, pcchArgsOffset: 2A6EE08
MSI (c) (E8:18) [13:00:00:000]: MsiProvideComponentFromDescriptor called for component {997FA962-E067-11D1-9396-00A0C90F27F9}: returning harcoded oleaut32.dll value
MSI (c) (E8:18) [13:00:00:000]: MsiProvideComponentFromDescriptor is returning: 0
1: User aborts the installation, ready to launch __OnAbort.
MSI (c) (E8:40) [13:00:00:375]: Destroying RemoteAPI object.
MSI (c) (E8:A0) [13:00:00:390]: Custom Action Manager thread ending.
=== Verbose logging stopped: 1/28/2008 13:00:00 ===
[font="courier new"]
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
since it looks like an installshield install I'm going to suggest that in SMS you choose the "local cache" option (i.e. copy the package to the workstation, then run, rather than run directly from the SMS share).

If this works I expect tons of ratings points :-)
Answered 01/28/2008 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
The extract you have produced is useless (no offence!). MSI logs can be tricky to decipher because many of the actions don't complete before the next one commences, meaning that when an error appears in the log, the causing action may be a few lines above. The trick is to search for the text 'Return value 3.' (without the quotes), - I shorten mine to just 'ue 3.' because I hate wasting time - since this is the return value you'll get 99.99999% of the time. The action which caused the error will normally be logged within 5-10 lines previous to where that text appears. Once you know which action caused the error, you're a good way along finding out why the install failed.

BTW, a good proportion of errors with InstallShield packages are due either:
- to the Identity of the InstallShield Driver being set to 'Interactive User' instead of 'Launching User' (there's a sample script available here on AppDeploy - and elsewhere - to fix this for all instances of the InstallShield Driver DCOM server)
- to the Custom Action's context being System instead of User
- a combination of the two.
Answered 01/29/2008 by: VBScab
Red Belt

Please log in to comment
0
-> it is already being cached locally & run from there. Changing DCOMM permissions did not fix it. Had already searched the log & it was all 1's and a 0 result for "MigrateDBStatus".
-> it is a small app, so have not spent too much time on it. turned out that issue may have been policy/permission related & company had a work around. laying to rest now as it has successfully deployed in testing.
Answered 01/29/2008 by: kiptek
Second Degree Green Belt

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