Here is what I imagine to be a typical conversation when a customer calls in with a installation issue.
Support: Hello, this is Support. How can I help you today?
Customer: Um, Hi. I'm having a problem installing Notes. Can you help me out?
Support: Sure. I'd be happy to. What exactly is the problem you are seeing?
Customer: Well, the installer keeps displaying an error message and exiting without actually installing the program.
Support: Ah I see. Can you describe the error messages that is being displayed?
Customer: Yes, it says "Error 1603: Something bad happened".
Support: Really? "Something bad happened"? That's a new one. I'm going to need to see some logs to dive on this further. You can find the logs in
Customer: Okay, I'll send those along. Is there anything else you'll need?
Support: Nope, that should be it until we've seen those logs.
Customer: Okay, Thanks for your time.
Support: You're welcome and thank you for calling Support. Have a nice day.
Remember this is my imagination so please no angry emails from my very good and capable friends in Support. I also made up the "Something bad happened" error message, that's not really in the installer. (But that pretty much is an accurate description of the Error 1603). Next this conversation occurs between a support engineer and a development engineer.
Support: Hey dev. I've got a customer that's have an installation issue "1603 something bad happened". Can you take a look?
Dev: Sure. I hate that error message. You have some logs?
Support: Yup, in your in-box.
A couple of minutes pass.
Dev: Okay, I see the error message but I'm not exactly sure what's leading up to the error. Do you have verbose logs?
Support: Nope, only the ones the customer sent me.
Dev: Hmm, we'll need to see those to determine exactly what's going on.
Support: Okay, I'll ask for them.
and finally later.
Support: Hello, this is Support calling back about the issue you were seeing during installation.
Customer: Hello. How'd it go with the logs?
Support: Well, the logs show the error but not the cause. We are going to need to see some verbose logs to really diagnose the issue.
Customer. Really? Why don't you generate logs with all the information you need to diagnose issues in the first place?
Support: Well the logs can get really big and for most of the installations there really isn't any need for them to be generated. It's only when there's an unusual problem that we need them and by then it's too late to turn them on.
Customer: Okay, I'll generate them and send them along.
Support: Thank you. Have a nice day.
That was probably a ridiculously long way to go about making the point of this post but I was feeling the creative writing mood today so you all had to suffer.
We wanted to turn on verbose logging for our installer. There is a way to do this via the registry http://support.microsoft.com/kb/223300 . The down side is that this solution turns logging for all Windows Installer based products and verbose log files can be quite large. Some customers are still disk space constrained this wasn't a very good solution. Also the verbose log files are created in the %TEMP% directory with a random name. It would be hard for customers to find the correct log file to send in. There is also the command line option to turn on verbose logging on a per installation basis which is what we've told customers to do but it was typically done after an installation issue had occurred which was too late in some cases.
In 8.5.2 we introduced a new installer launcher to address this problem. Previously we'd used the launcher from InstallShield that came with their install kit generating program. To prevent confusion and not break all the existing deployment infrastructure we named our launcher the same as it was before, "setup.exe". This new setup.exe was created to specifically address the issue of installer verbose log file generation.
The new setup.exe works by manipulating the command line passed to the msiexec call that actually does the product installation. It parses the existing command line, if any, and adds the "/L*v LotusInstall.log" string to it if it does not already exist in some manner. This turns on verbose logging for the current installation and dumps it into a file. It also stays around waiting for the installation to finish. Once the install is done, it takes the new log file and creates an archive of it compressing the size down. Because verbose log files are all text they compress very well. This addressed the concern for those customers with smaller disk drives. The archived log file is then moved to the installing user's My Documents directory as "LotusNotesInstallLog.cab" next to the long standing log file "LotusInstall.log" so it can be easily found.
There were some issues with some of the code in 8.5.2 that prevented the log file from being archived in all situations. These issues have been solved in 8.5.3. From now on the conversation for installation issues should be a lot shorter and more productive.
Jeff Mitchell | 7 April 2011 10:37:35 AM ET | Littleton, MA | Comments (5)