deciphering MSInstall logs, etc.
Good Day everyone,
Being a bit new to needing to customize installation packages for gpo deployment (Administrative Assigned), i have a few pointed questions that I could use some info/verification on. I've spent a few hours reading various threads on this site and decided that it would be worthwhile to register and ask for some advice.
1.) --Need help dissecting MSInstaller log files
Having turned on logging for MSInstaller...
Which logging switches (registry key entry) are absolutely necessary to only find what command line properties/variables passed from the calling setup.exe to the called .msi.
I don’t need to see any extraneous information or errors unless it will tell me that a given parameter is unnecessary or some such. I've already run the vendor supplied installation process to collect logging - both with the full gamut of switches and also un-including those options that specifically cite error reporting, and I'm still not 100% sure of what I'm looking at.
2.) --I have (2x) .msi files, one of which is ISScript. Please verify the following:
ISScript.msi is independent of the actual installation that I am attempting to accomplish; (Having read about how to imbed it or find out if it is already imbedded, I have not been able to find the proper table, so I'm fairly confident that it is not.) It is runtime integration for MSInstaller and can be run independently of the actual application installation. If it is installed any time prior to an application installation the prerequisite is satisfied; It does not have to be a part of the same installation process. What I had in mind was a chained software deployment package... 2 msi files with one set as a prerequisite. (Please confirm)
3.) --The 2nd .msi file is the application installation. It currently relies on being called by setup.exe, however I'm unsure of what parameters are being passed from the calling .exe to the .msi. This is the reason for my first question. I'd like to be able to isolate this information and include it in a setup.ini file (or another answer file that will be read by the .msi...or simply hard-coded it into the .msi itself. (Our environment is static enough that I feel confident hard coding things like InstallToPath=c:\blahblahblah\blahblah\ or something like that.) In reading one of the threads, I found a mention of looking at the entries in the Property table (in the .msi file using ORCA, [I use InstedIT]). The only thing that I found in said table that may be a variable is DiskPrompt=[1], which I could hard code to c: or the entire path as I found in the MSInstaller log files (if what I was reading in the logs was indeed referencing this property). These are the things I need to verify by deciphering the MSInstaller logs.
I've found several posts on this forum that outline how to alleviate the 'Called by .exe' requirement, (Many Thanks by the way!!), but I need to be able to pass along any parameters that are typically passed by the calling .exe. (I'm familiar with GPO deployment, but am an .msi editing noob). I have 2 applications to help me do most if not all of the editing; InstED! and WinInstall LE...
Once I can definitively isolate the variable parameters being passed to my application .msi, I will take the steps outlined in a post by AngelD in "All Forums >> [AppDeploy Forums] >> Package Development >> TWO MSI INSTALL" to free my .msi from the clutches of setup.exe and attempt a GPO deployment.
Further reading pointed me to look at the Install level in the Feature table. The only module listed is set to Level 1, how can I verify that this will be ok when run as a standalone .msi rather than having been called.
I simply need some verification of theories and affirmation that I'm not barking up the wrong tree here as this is my first attempt at hijacking (maybe a bad word, lol) this application installation.
[BTW, so there are no questions:
The application is a point-of-sale application and the installer that I'm dealing with is installing a quasi-customized executable for MSTSC.exe (windows remote desktop client) which includes some additional driver functionality for things like cash drawers, pole displays, receipt printers, etc. Everything is fully licensed, including $18%/year support renewal - GAH!]
Thanks in advance everyone!!!
Being a bit new to needing to customize installation packages for gpo deployment (Administrative Assigned), i have a few pointed questions that I could use some info/verification on. I've spent a few hours reading various threads on this site and decided that it would be worthwhile to register and ask for some advice.
1.) --Need help dissecting MSInstaller log files
Having turned on logging for MSInstaller...
Which logging switches (registry key entry) are absolutely necessary to only find what command line properties/variables passed from the calling setup.exe to the called .msi.
I don’t need to see any extraneous information or errors unless it will tell me that a given parameter is unnecessary or some such. I've already run the vendor supplied installation process to collect logging - both with the full gamut of switches and also un-including those options that specifically cite error reporting, and I'm still not 100% sure of what I'm looking at.
2.) --I have (2x) .msi files, one of which is ISScript. Please verify the following:
ISScript.msi is independent of the actual installation that I am attempting to accomplish; (Having read about how to imbed it or find out if it is already imbedded, I have not been able to find the proper table, so I'm fairly confident that it is not.) It is runtime integration for MSInstaller and can be run independently of the actual application installation. If it is installed any time prior to an application installation the prerequisite is satisfied; It does not have to be a part of the same installation process. What I had in mind was a chained software deployment package... 2 msi files with one set as a prerequisite. (Please confirm)
3.) --The 2nd .msi file is the application installation. It currently relies on being called by setup.exe, however I'm unsure of what parameters are being passed from the calling .exe to the .msi. This is the reason for my first question. I'd like to be able to isolate this information and include it in a setup.ini file (or another answer file that will be read by the .msi...or simply hard-coded it into the .msi itself. (Our environment is static enough that I feel confident hard coding things like InstallToPath=c:\blahblahblah\blahblah\ or something like that.) In reading one of the threads, I found a mention of looking at the entries in the Property table (in the .msi file using ORCA, [I use InstedIT]). The only thing that I found in said table that may be a variable is DiskPrompt=[1], which I could hard code to c: or the entire path as I found in the MSInstaller log files (if what I was reading in the logs was indeed referencing this property). These are the things I need to verify by deciphering the MSInstaller logs.
I've found several posts on this forum that outline how to alleviate the 'Called by .exe' requirement, (Many Thanks by the way!!), but I need to be able to pass along any parameters that are typically passed by the calling .exe. (I'm familiar with GPO deployment, but am an .msi editing noob). I have 2 applications to help me do most if not all of the editing; InstED! and WinInstall LE...
Once I can definitively isolate the variable parameters being passed to my application .msi, I will take the steps outlined in a post by AngelD in "All Forums >> [AppDeploy Forums] >> Package Development >> TWO MSI INSTALL" to free my .msi from the clutches of setup.exe and attempt a GPO deployment.
Further reading pointed me to look at the Install level in the Feature table. The only module listed is set to Level 1, how can I verify that this will be ok when run as a standalone .msi rather than having been called.
I simply need some verification of theories and affirmation that I'm not barking up the wrong tree here as this is my first attempt at hijacking (maybe a bad word, lol) this application installation.
[BTW, so there are no questions:
The application is a point-of-sale application and the installer that I'm dealing with is installing a quasi-customized executable for MSTSC.exe (windows remote desktop client) which includes some additional driver functionality for things like cash drawers, pole displays, receipt printers, etc. Everything is fully licensed, including $18%/year support renewal - GAH!]
Thanks in advance everyone!!!
0 Comments
[ + ] Show comments
Answers (19)
Please log in to answer
Posted by:
aogilmor
14 years ago
Question 1)
no disrespect but if you're really new at this best place to start is rtfm
google windows installer command line log
msiexec /L
[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] Logfile Writes logging information into a logfile at the specified existing path. The path to the logfile location must already exist. The installer does not create the directory structure for the logfile. Flags indicate which information to log. If no flags are specified, the default is 'iwearmo.'
i - Status messages.
w - Nonfatal warnings.
e - All error messages.
a - Start up of actions.
r - Action-specific records.
u - User requests.
c - Initial UI parameters.
m - Out-of-memory or fatal exit information.
o - Out-of-disk-space messages.
p - Terminal properties.
v - Verbose output.
x - Extra debugging information. Only available on Windows Server 2003.
+ - Append to existing file.
! - Flush each line to the log.
"*" - Wildcard, log all information except for the v and x options. To include the v and x options, specify "/l*vx".
As for 2) and 3) there are TONS of messages and KB articles on Installshield and they're all over the map. I've found it best to go with what the vendor supports balanced on what gets the job done properly. There are ways to use setup.exe and have it do what you want? use it. If it doesn't, break it down
....there are also installshield merge modules (didn't work for me). Better just to let the installshield engine run
no disrespect but if you're really new at this best place to start is rtfm
google windows installer command line log
msiexec /L
[i|w|e|a|r|u|c|m|o|p|v|x|+|!|*] Logfile Writes logging information into a logfile at the specified existing path. The path to the logfile location must already exist. The installer does not create the directory structure for the logfile. Flags indicate which information to log. If no flags are specified, the default is 'iwearmo.'
i - Status messages.
w - Nonfatal warnings.
e - All error messages.
a - Start up of actions.
r - Action-specific records.
u - User requests.
c - Initial UI parameters.
m - Out-of-memory or fatal exit information.
o - Out-of-disk-space messages.
p - Terminal properties.
v - Verbose output.
x - Extra debugging information. Only available on Windows Server 2003.
+ - Append to existing file.
! - Flush each line to the log.
"*" - Wildcard, log all information except for the v and x options. To include the v and x options, specify "/l*vx".
As for 2) and 3) there are TONS of messages and KB articles on Installshield and they're all over the map. I've found it best to go with what the vendor supports balanced on what gets the job done properly. There are ways to use setup.exe and have it do what you want? use it. If it doesn't, break it down
....there are also installshield merge modules (didn't work for me). Better just to let the installshield engine run
Posted by:
anonymous_9363
14 years ago
Welcome to Hell.
I'm still not 100% sure of what I'm looking at.They can be a bit impenetrative. Try the Windows Installer Log Utility (WiLogUtl [?]), a freeware tool. An understanding of the underlying technology would help you decipher the log enormously. Have a browse of MSDN, get hold of Phil Wilson's Definitve Guide to Windows Installer, browse here, Symantec's Connect forum (if you can stand the UI) and InstallSite.org.
ISScript.msi is independent of the actual installationKind of. Most InstallShield-driven packages will at some point call functions in the support DLLs which ISScript.MSI installs so, to the extent, it's NOT independent of the main installation.
What I had in mind was a chained software deployment package... 2 msi files with one set as a prerequisite. (Please confirm)Spot on. You can either use groups to do that (where the dependent app is a member of the InstallShield deployment group) or by ordering the installation of the MSIs. In the latter case, add the MSIs to the GP in the order which you want them installed.
It currently relies on being called by setup.exe,Normaly, this can be circumvened by the simple addition of a property called ISSETUPDRIVEN with a value of 1.
Further reading pointed me to look at the Install level in the Feature table. The only module listed is set to Level 1, how can I verify that this will be ok when run as a standalone .msi rather than having been called.If a feature's Level is the same number or less than the InstallLevel property, it will be marked for installation. I say "marked for installation" because features may be "conditioned", i.e. relying on a property being some specific value.
Posted by:
MStrong
14 years ago
Thank you for the rapid response,
First, I am aware of the logging function. If you read the beginning of my post, I mentioned that I had the logging turned on and had applied various versons of the switches and re-run the vendor version of the install to collect logs. I'm simply not exactly sure how to decipher the output and pick out the lines that I am particularly interested in. It seems as if most everything on the first 2 pages of google directly or indirectly point back to this page: http://blogs.technet.com/richard_macdonald/archive/2007/04/02/How-to-Interpret-Windows-Installer-Logs.aspx ... While informative, it doesn't really tell me what I need to know.
Second, I have attempted to address this with the vendor, however their assistance is lacking. There is a definate language barrier here, most of the developers are in China and their Canadian based North America support team is mostly french speaking. As such, documentation is minimalistic at best and attempting to have a conversation with some of these people proves almost impossible. These guys are money hungry and want to charge me 1,100/day for 10 days (estimated) to build a custom installation package for me, rather than just edit the .msi or tell me which parameters need to be changed (which, consequently is what I had originally requested from them). What they are offering me and what I need are 2 different things. Also, their development department has already informed me that they are not familiar with GPO deployment and with that said, I generally do not wish to open that can of worms. I also refuse (not to mention our CFO refuses) to pay this rediculous fee for something that can be done in a matter of minutes by someone who actually has some experience in this. Since I'm the companies network director the job falls on me.
I've actually spent almost 2 days researching this using google as well as quite a number of articles from this wonderful forum for information; and seem to have found most of what I'm after. I had a few very pointed (i thought) questions to verify a few things before I went through the hair-tearing trial and error method.
Using the .exe would be the easy way out, however GPO deployment requires .msi files and I cannot currently execute the application installation.msi without setup.exe.
As mentioned, I believe that I've found pretty much what I needed, but would like some confirmation and a bit of specific info as requested in my original posting.
Thank you,
First, I am aware of the logging function. If you read the beginning of my post, I mentioned that I had the logging turned on and had applied various versons of the switches and re-run the vendor version of the install to collect logs. I'm simply not exactly sure how to decipher the output and pick out the lines that I am particularly interested in. It seems as if most everything on the first 2 pages of google directly or indirectly point back to this page: http://blogs.technet.com/richard_macdonald/archive/2007/04/02/How-to-Interpret-Windows-Installer-Logs.aspx ... While informative, it doesn't really tell me what I need to know.
Second, I have attempted to address this with the vendor, however their assistance is lacking. There is a definate language barrier here, most of the developers are in China and their Canadian based North America support team is mostly french speaking. As such, documentation is minimalistic at best and attempting to have a conversation with some of these people proves almost impossible. These guys are money hungry and want to charge me 1,100/day for 10 days (estimated) to build a custom installation package for me, rather than just edit the .msi or tell me which parameters need to be changed (which, consequently is what I had originally requested from them). What they are offering me and what I need are 2 different things. Also, their development department has already informed me that they are not familiar with GPO deployment and with that said, I generally do not wish to open that can of worms. I also refuse (not to mention our CFO refuses) to pay this rediculous fee for something that can be done in a matter of minutes by someone who actually has some experience in this. Since I'm the companies network director the job falls on me.
I've actually spent almost 2 days researching this using google as well as quite a number of articles from this wonderful forum for information; and seem to have found most of what I'm after. I had a few very pointed (i thought) questions to verify a few things before I went through the hair-tearing trial and error method.
Using the .exe would be the easy way out, however GPO deployment requires .msi files and I cannot currently execute the application installation.msi without setup.exe.
As mentioned, I believe that I've found pretty much what I needed, but would like some confirmation and a bit of specific info as requested in my original posting.
Thank you,
Posted by:
MStrong
14 years ago
VBScab,
Thank you for the info. You've verified most of what I had suspected. I will look at the MSDN and installsite.org (hadn't found that one yet) as well as Symantec's forum (yes, i have a login [&:] ). I was hoping that someone could point me in the direction of 'look for lines beginning with "parameter-blahblah"' or something simplistic to pick out the command line arguements passed between the 2.
As for the 'level'. How can I verify the (default?) install level property? Is there a windows default? Or is this something that is defined exclusively by the calling package (the .exe)... that being said, can I set the level in my .msi to something rediculous like -99 to ensure that it is installed no matter what? This application is not so complicated that an overwrite is going to damage anything.
I will attempt to add the ISSETUPDRIVEN property as described. I'm glad you touched on that because based on what I've read I was under the impression that the existance of this value would CAUSE the .msi to REQUIRE being called, obviously I was wrong. I've also noticed the property ISVERIFYSCRIPTINGRUNTIME, which I believed to be similar to the ISSETUPDRIVEN property; but after further reading, it seems that this is simply checking for something (whatever is installed by isscript.msi?) (Correct?) Can you please point me to where I might add the ISSETUPDRIVEN property? I've seen other installer properties, but where they are listed is in defining a sequence, rather than a boolean condition (0/1).
Again, thank you very much for the info. I will begin with my tests while I await your response.
P.S. Love the Icon [:D]
Thank you!!
Thank you for the info. You've verified most of what I had suspected. I will look at the MSDN and installsite.org (hadn't found that one yet) as well as Symantec's forum (yes, i have a login [&:] ). I was hoping that someone could point me in the direction of 'look for lines beginning with "parameter-blahblah"' or something simplistic to pick out the command line arguements passed between the 2.
As for the 'level'. How can I verify the (default?) install level property? Is there a windows default? Or is this something that is defined exclusively by the calling package (the .exe)... that being said, can I set the level in my .msi to something rediculous like -99 to ensure that it is installed no matter what? This application is not so complicated that an overwrite is going to damage anything.
I will attempt to add the ISSETUPDRIVEN property as described. I'm glad you touched on that because based on what I've read I was under the impression that the existance of this value would CAUSE the .msi to REQUIRE being called, obviously I was wrong. I've also noticed the property ISVERIFYSCRIPTINGRUNTIME, which I believed to be similar to the ISSETUPDRIVEN property; but after further reading, it seems that this is simply checking for something (whatever is installed by isscript.msi?) (Correct?) Can you please point me to where I might add the ISSETUPDRIVEN property? I've seen other installer properties, but where they are listed is in defining a sequence, rather than a boolean condition (0/1).
Again, thank you very much for the info. I will begin with my tests while I await your response.
P.S. Love the Icon [:D]
Thank you!!
Posted by:
kiptek
14 years ago
These guys are money hungry and want to charge me 1,100/day for 10 days (estimated) to build a custom installation package for me,
You could always ask for a quote from someone here if all you want to do is get a custom package built & ready for deployment... All you want is a GPO deploy ready MSI, right..?
Posted by:
MStrong
14 years ago
Kiptek,
Thank you for the offer, however I'm pretty sure that I've already got what I need. I've got the 2 .msi files, but one of them is whining about wanting to be called from an .exe. I simply need to break that dependancy and be able to discover/provide any variables that may need to be passed to the application .msi from setup.exe. The vendor is no help here and I have the applications to tweek the .msi files locally. If I end up truily stumped, I'll have no problem suggesting that we contract in assistance; however the companies CFO makes those final decisions. I will definatily keep you in mind!! I've already received some tips from VBScab which I'm about to begin testing with. I'll post back with results, for sure...
Thank you!!
Thank you for the offer, however I'm pretty sure that I've already got what I need. I've got the 2 .msi files, but one of them is whining about wanting to be called from an .exe. I simply need to break that dependancy and be able to discover/provide any variables that may need to be passed to the application .msi from setup.exe. The vendor is no help here and I have the applications to tweek the .msi files locally. If I end up truily stumped, I'll have no problem suggesting that we contract in assistance; however the companies CFO makes those final decisions. I will definatily keep you in mind!! I've already received some tips from VBScab which I'm about to begin testing with. I'll post back with results, for sure...
Thank you!!
Posted by:
kiptek
14 years ago
np... As Ian mentioned, get a copy of WiLogUtl.exe to look @ log files. To find an error, typically search your log for "Return Value 3" (just "ue 3" does the trick)... If the ISSETUPDRIVEN=1 does not solve the problem, you will probably find a CA throwing an error (usually something like OnCheckStilentInstall). Sometimes it will be possible to either comment out that CA or give it an impossible to meet condition. Search in here for ISSETUPDRIVEN & you will find numerous threads addressing this issue. Cheers!
Posted by:
turbokitty
14 years ago
I'd just like to add that I'm impressed with your (MStrong) attempts thus far to research on your own and understand your problem. For a packaging/deployment newbie, you've gone a long way already and we're always happy to help someone who's willing to invest a little of their own time before asking of ours.
We all started with no knowledge of this topic, so we're always here to help a new member that's got some initiative.
We all started with no knowledge of this topic, so we're always here to help a new member that's got some initiative.
Posted by:
joedown
14 years ago
If you have added the registry key for logging which I assume you have under "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\Logging=voicewarmup" then you will be looking in the log file for the following line:
Command Line: (properties passed to the msi by setup if any)
Also I would make a change to your ISSCRIPT#.msi by changing the registry value for RunAs from Interactive User to Launching User in the Registry table. Makes deployment using a true system account possible among other things. I don't know who originally discovered this bug in the ISSCRIPT msi's but many thanks to them.
Command Line: (properties passed to the msi by setup if any)
Also I would make a change to your ISSCRIPT#.msi by changing the registry value for RunAs from Interactive User to Launching User in the Registry table. Makes deployment using a true system account possible among other things. I don't know who originally discovered this bug in the ISSCRIPT msi's but many thanks to them.
Posted by:
aogilmor
14 years ago
you're welcome. Since most likely nobody here is going to know about the specific solution to your specific Installshield installed app, in your specific environment, maybe your time would be better spent looking at the already-done work and learning about windows installer, instead of trying to get individualized support from a packaging forum. Just a guess...
WRT your request for "specific" answers posed in your original query....well, since you know about the log function it is up to you to read up on technet/msdn/msi.chm and find out what specific log information would best suit your purpose. The "specific" answers WRT installlevel of features (and all the rest...) are all available in the aforementioned sources. Hint: if you ARE able to generate some kind of log using the vendor EXE/INI, then you will have the properties that are used with the vendor install, and may be in a better position to "break it down" and customize it with your own transform.
Hope this helps, best of luck!
WRT your request for "specific" answers posed in your original query....well, since you know about the log function it is up to you to read up on technet/msdn/msi.chm and find out what specific log information would best suit your purpose. The "specific" answers WRT installlevel of features (and all the rest...) are all available in the aforementioned sources. Hint: if you ARE able to generate some kind of log using the vendor EXE/INI, then you will have the properties that are used with the vendor install, and may be in a better position to "break it down" and customize it with your own transform.
Hope this helps, best of luck!
Posted by:
aogilmor
14 years ago
ORIGINAL: MStrong
I've got the 2 .msi files, but one of them is whining about wanting to be called from an .exe.
Did you try adding a property ISSETUPDRIVEN and setting it to 1 as Ian suggested? There may also be CAs as Kiptek points out.
Posted by:
anonymous_9363
14 years ago
If you have added the registry key for logging which I assume you have under "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\Logging=voicewarmup"GP-enabled logging is slightly sub-optimal in that files get dumped into %systemRoot%\TEMP, prefixed 'MSI' and named with random alpha-numeric characters. Additionally, it logs all the AD/Windows Installer activity, all of which makes it hard to know which log pertains to which install.
I suspect that our man is using the command line.
Posted by:
anonymous_9363
14 years ago
Can you please point me to where I might add the ISSETUPDRIVEN property?Properties go in the 'Properties' table.
Use InstEdit for adding it but please, do so via a transform, unless the MSI is one of your own making: directly editing vendor-supplied MSIs is a Bad Idea.
Posted by:
joedown
14 years ago
Actually log files are written to the temp directory of the launching user. When launched by a system account with no profile it goes to Windows\Temp by default. I dunno, every log file I've looked at tells you exactly what product is being installed. I wouldn't use this method in production but I find it very useful in a test environment.
ORIGINAL: VBScab
If you have added the registry key for logging which I assume you have under "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\Logging=voicewarmup"GP-enabled logging is slightly sub-optimal in that files get dumped into %systemRoot%\TEMP, prefixed 'MSI' and named with random alpha-numeric characters. Additionally, it logs all the AD/Windows Installer activity, all of which makes it hard to know which log pertains to which install.
I suspect that our man is using the command line.
Posted by:
MStrong
14 years ago
Woops...I've already edited the orig. But not to worry, I Makee Bak-uP
I've successfully added a row to the properties table with ISSETUPDRIVEN = 1
I've already found and removed the following 5 entries:
OnCheckSilentInstall - from - InstallExecuteSequence table
OnCheckSilentInstall - from - CustomAction table
IsVerifyScriptingRuntime - from - InstallUISequence
IsVerifyScriptingRuntime - from - AdminUISequence
IsVerifyScriptingRuntime - from - CustomAction
************************UPDATE************************
Actually, the installation process now works fine, the .msi file runs without coplaining and the application(s) are installed; tested and working. However... successfull execution only occurs on a machine that does not have the app currently installed. I've tested this on a machine that has never had this app installed and I've tested on a machine that HAS had the app installed by uninstalling and and immediatly executing the .msi file (no reboots or folder deletes).
Also had to add the ALLUSERS = 1 property, as it seemed to default to a per-user install. (Is there any detriment to doing the same to ISScript.msi?)
Now, that being said, I have 2 more small items that I need to address...
1.) Where do i have to look to figure out how to allow this to run on a machine that has the app currently installed (ie.'repair'). We've already manually installed the app to a few workstations, but when i do my major deployment push I dont want to encounter any errors.
2.) When I execute the application.msi it simply runs without any UI (shows progress and nothing more) and all seems well. When I manually execute ISScript.msi I still have a 'Welcome' dialogue box asking to click next, then the eula, and one final page with an 'Install' button before the installation process begins. I've set the 'Agree to License' property to 'Yes' which takes care of which radio button is set by default on the Eula page, but does not eliminate the step. How to eliminate those few things... Tried searching for switches, etc but found very little on that subject. If it won't make a difference once it's set up in GP, then I guess this is moot. I just don't want there to be ANY user inetraction, as the install will most likely run overnight after one of my maintenance reboots.
To address #1, I've included a chunk of the msinstaller log file from when it bombs on a 'repair' (machine with app currently isntalled), perhaps something will jump out at you that I've missed.
Logfile created using all switches (voicewarmup). I can make available a copy of the full logfile and post a web-link if necessary...
...Nothing prior to this seems to stand out as errant
=== Logging started: 8/19/2009 13:22:27 ===
MSI (c) (34:3C) [13:22:27:456]: Note: 1: 2262 2: PatchPackage 3: -2147287038
MSI (c) (34:3C) [13:22:27:456]: Machine policy value 'DisableRollback' is 0
MSI (c) (34:3C) [13:22:27:456]: User policy value 'DisableRollback' is 0
MSI (c) (34:3C) [13:22:27:456]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'.
MSI (c) (34:3C) [13:22:27:456]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'.
MSI (c) (34:3C) [13:22:27:456]: Doing action: INSTALL
Action 13:22:27: INSTALL.
Action start 13:22:27: INSTALL.
MSI (c) (34:3C) [13:22:27:472]: UI Sequence table 'InstallUISequence' is present and populated.
MSI (c) (34:3C) [13:22:27:472]: Running UISequence
MSI (c) (34:3C) [13:22:27:472]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'.
MSI (c) (34:3C) [13:22:27:472]: Doing action: ISVerifyScriptingRuntime
Action 13:22:27: ISVerifyScriptingRuntime.
Action start 13:22:27: ISVerifyScriptingRuntime.
MSI (c) (34:98) [13:22:27:488]: Invoking remote custom action. DLL: C:\DOCUME~1\MStrong\LOCALS~1\Temp\MSI189.tmp, Entrypoint: VerifyScriptingRuntime
MSI (c) (34:84) [13:22:27:488]: Cloaking enabled.
MSI (c) (34:84) [13:22:27:488]: Attempting to enable all disabled priveleges before calling Install on Server
MSI (c) (34:84) [13:22:27:488]: Connected to service for CA interface.
MSI (c) (34:68) [13:22:27:613]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
1: This installation can not be run by directly launching the MSI package; you must run setup.exe.
MSI (c) (34!4C) [13:22:36:267]: Product: Raymark Citrix Component -- 1: This installation can not be run by directly launching the MSI package; you must run setup.exe.
Action ended 13:22:36: ISVerifyScriptingRuntime. Return value 3.
Action ended 13:22:36: INSTALL. Return value 3.
MSI (c) (34:3C) [13:22:36:267]: Destroying RemoteAPI object.
MSI (c) (34:84) [13:22:36:267]: Custom Action Manager thread ending.
======================================================
Everything below this in the log seems to be a 'Properties' Dump; and the logfile closing...
I was told to keep an eye out for returnvalue 3, listed above... If I'm reading this correctly, it looks like it's failing because of something still in the InstallUIExecute table
All entries in that table are <null> with the exception of the following (numbers = sequence):
CCPSearch = CCP_TEST (250)
RMCCPSearch = Not CCP_SUCCESS And CCP_TEST (300)
ResolveSource = Not Installed (525)
I think there's something left in that table that is causing the 'repair' to bomb. Please advise,
BTW, I VERY MUCH APPRECIATE YOUR RAPID RESPONSES AND MYRID OF INFORMATION. I WOULD HAVE SPENT DAYS AT THIS WITHOUT YOUR ASSISTANCE, I'M SURE!!
THANK YOU ALL!!!
I've successfully added a row to the properties table with ISSETUPDRIVEN = 1
I've already found and removed the following 5 entries:
OnCheckSilentInstall - from - InstallExecuteSequence table
OnCheckSilentInstall - from - CustomAction table
IsVerifyScriptingRuntime - from - InstallUISequence
IsVerifyScriptingRuntime - from - AdminUISequence
IsVerifyScriptingRuntime - from - CustomAction
************************UPDATE************************
Actually, the installation process now works fine, the .msi file runs without coplaining and the application(s) are installed; tested and working. However... successfull execution only occurs on a machine that does not have the app currently installed. I've tested this on a machine that has never had this app installed and I've tested on a machine that HAS had the app installed by uninstalling and and immediatly executing the .msi file (no reboots or folder deletes).
Also had to add the ALLUSERS = 1 property, as it seemed to default to a per-user install. (Is there any detriment to doing the same to ISScript.msi?)
Now, that being said, I have 2 more small items that I need to address...
1.) Where do i have to look to figure out how to allow this to run on a machine that has the app currently installed (ie.'repair'). We've already manually installed the app to a few workstations, but when i do my major deployment push I dont want to encounter any errors.
2.) When I execute the application.msi it simply runs without any UI (shows progress and nothing more) and all seems well. When I manually execute ISScript.msi I still have a 'Welcome' dialogue box asking to click next, then the eula, and one final page with an 'Install' button before the installation process begins. I've set the 'Agree to License' property to 'Yes' which takes care of which radio button is set by default on the Eula page, but does not eliminate the step. How to eliminate those few things... Tried searching for switches, etc but found very little on that subject. If it won't make a difference once it's set up in GP, then I guess this is moot. I just don't want there to be ANY user inetraction, as the install will most likely run overnight after one of my maintenance reboots.
To address #1, I've included a chunk of the msinstaller log file from when it bombs on a 'repair' (machine with app currently isntalled), perhaps something will jump out at you that I've missed.
Logfile created using all switches (voicewarmup). I can make available a copy of the full logfile and post a web-link if necessary...
...Nothing prior to this seems to stand out as errant
=== Logging started: 8/19/2009 13:22:27 ===
MSI (c) (34:3C) [13:22:27:456]: Note: 1: 2262 2: PatchPackage 3: -2147287038
MSI (c) (34:3C) [13:22:27:456]: Machine policy value 'DisableRollback' is 0
MSI (c) (34:3C) [13:22:27:456]: User policy value 'DisableRollback' is 0
MSI (c) (34:3C) [13:22:27:456]: PROPERTY CHANGE: Adding UILevel property. Its value is '5'.
MSI (c) (34:3C) [13:22:27:456]: PROPERTY CHANGE: Adding ACTION property. Its value is 'INSTALL'.
MSI (c) (34:3C) [13:22:27:456]: Doing action: INSTALL
Action 13:22:27: INSTALL.
Action start 13:22:27: INSTALL.
MSI (c) (34:3C) [13:22:27:472]: UI Sequence table 'InstallUISequence' is present and populated.
MSI (c) (34:3C) [13:22:27:472]: Running UISequence
MSI (c) (34:3C) [13:22:27:472]: PROPERTY CHANGE: Adding EXECUTEACTION property. Its value is 'INSTALL'.
MSI (c) (34:3C) [13:22:27:472]: Doing action: ISVerifyScriptingRuntime
Action 13:22:27: ISVerifyScriptingRuntime.
Action start 13:22:27: ISVerifyScriptingRuntime.
MSI (c) (34:98) [13:22:27:488]: Invoking remote custom action. DLL: C:\DOCUME~1\MStrong\LOCALS~1\Temp\MSI189.tmp, Entrypoint: VerifyScriptingRuntime
MSI (c) (34:84) [13:22:27:488]: Cloaking enabled.
MSI (c) (34:84) [13:22:27:488]: Attempting to enable all disabled priveleges before calling Install on Server
MSI (c) (34:84) [13:22:27:488]: Connected to service for CA interface.
MSI (c) (34:68) [13:22:27:613]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
1: This installation can not be run by directly launching the MSI package; you must run setup.exe.
MSI (c) (34!4C) [13:22:36:267]: Product: Raymark Citrix Component -- 1: This installation can not be run by directly launching the MSI package; you must run setup.exe.
Action ended 13:22:36: ISVerifyScriptingRuntime. Return value 3.
Action ended 13:22:36: INSTALL. Return value 3.
MSI (c) (34:3C) [13:22:36:267]: Destroying RemoteAPI object.
MSI (c) (34:84) [13:22:36:267]: Custom Action Manager thread ending.
======================================================
Everything below this in the log seems to be a 'Properties' Dump; and the logfile closing...
I was told to keep an eye out for returnvalue 3, listed above... If I'm reading this correctly, it looks like it's failing because of something still in the InstallUIExecute table
All entries in that table are <null> with the exception of the following (numbers = sequence):
CCPSearch = CCP_TEST (250)
RMCCPSearch = Not CCP_SUCCESS And CCP_TEST (300)
ResolveSource = Not Installed (525)
I think there's something left in that table that is causing the 'repair' to bomb. Please advise,
BTW, I VERY MUCH APPRECIATE YOUR RAPID RESPONSES AND MYRID OF INFORMATION. I WOULD HAVE SPENT DAYS AT THIS WITHOUT YOUR ASSISTANCE, I'M SURE!!
THANK YOU ALL!!!
Posted by:
aogilmor
14 years ago
run the isscript.msi silently (/qb)
that'll take care of your dialogs.
for the already installed, you'll need to remove and reinstall if you want them to be all standard.
that'll take care of your dialogs.
for the already installed, you'll need to remove and reinstall if you want them to be all standard.
Posted by:
anonymous_9363
14 years ago
- The error returned for the action ISVerifyScriptingRuntime indicates that the property ISSETUPDRIVEN either isn't being tested or isn't present. Check the log for it.
- Rather than removing an action, it's simpler to apply an impossible-to-meet condition on its execution. Typically, I use '0=1'. Set conditions in the relevant sequence table.
- It's good that you have posted only the relevant part of the log. However, logs and other lengthy texts are easier to read when posted inside the CODE tag, accessible by using the button marked '<%' in the 'Reply to Message' window.
- Sematics now... :)
Owen is almost right in saying that the argument '/qb' gives you a silent install. It gives you an unattended install but there is a UI (only a progress bar and a 'Cancel' button, though). Specifying the argument '/qn' to MSIExec means you run a completely silent install, with no UI at all.
Running MSIExec with no arguments produces a screen showing you all the arguments and their qualifiers.
- Rather than removing an action, it's simpler to apply an impossible-to-meet condition on its execution. Typically, I use '0=1'. Set conditions in the relevant sequence table.
- It's good that you have posted only the relevant part of the log. However, logs and other lengthy texts are easier to read when posted inside the CODE tag, accessible by using the button marked '<%' in the 'Reply to Message' window.
- Sematics now... :)
Owen is almost right in saying that the argument '/qb' gives you a silent install. It gives you an unattended install but there is a UI (only a progress bar and a 'Cancel' button, though). Specifying the argument '/qn' to MSIExec means you run a completely silent install, with no UI at all.
Running MSIExec with no arguments produces a screen showing you all the arguments and their qualifiers.
Posted by:
AngelD
14 years ago
Maybe this will help:
http://www.appdeploy.com/messageboards/fb.asp?m=19850
http://www.appdeploy.com/messageboards/fb.asp?m=19850
Posted by:
MStrong
14 years ago
VBScab,
Sorry about the log snippet, I'll use the code tag in the future... The ISSETUPDRIVEN property is definatly there, in the properties table, with a value of 1; and it is not mentioned in the logs when it fails, so for some reason the process isn't even making it that far. What's wierd is, after playing around with it a bit more (on other pc's)... it appears as if it is only failing on my office workstation; but that's got to be another problem alltogether [:)]...
I've got someone going to one of our sattelite locations today, so I'll throw together a GPO and test it.
AngelD,
I read that whole thread the other day, that's actually what prompted me to sign up :)
And thanks for the switches, guys!! I'll try to post back this afternoon after i test-deploy this.
Sorry about the log snippet, I'll use the code tag in the future... The ISSETUPDRIVEN property is definatly there, in the properties table, with a value of 1; and it is not mentioned in the logs when it fails, so for some reason the process isn't even making it that far. What's wierd is, after playing around with it a bit more (on other pc's)... it appears as if it is only failing on my office workstation; but that's got to be another problem alltogether [:)]...
I've got someone going to one of our sattelite locations today, so I'll throw together a GPO and test it.
AngelD,
I read that whole thread the other day, that's actually what prompted me to sign up :)
And thanks for the switches, guys!! I'll try to post back this afternoon after i test-deploy this.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.