Once again I was asked to generate a list of some stuff and thought I'd post it here in case it turns out to be useful for someone else.
This is a table of all the File versions, sizes and time/date stamps for nlnotes.exe going back to V604 which is when we started putting file versions on.
Interesting note is you can see how we've evolved our versioning strategy over time with respect to fixpacks (ugh it took us til v6.5.4FP1 to get it right?)
Release Version Size Date Time
---------------------------------------------------------------------------
V604 6.0.40.4152 1036337 6-01-2004 10:19:34
V605 6.0.50.5086 1044529 3-28-2005 7:39:18
V651 6.5.10.4008 1036337 1-21-2004 17:43:18
V651DSF1 6.5.10.4075 1036337 3-16-2004 10:42:21
V652FP1 6.5.20.4319 1036337 11-15-2004 13:21:18
V653 6.5.30.4258 1040433 9-15-2004 4:39:40
V653CPP1 6.5.30.4315 1040433 11-11-2004 6:35:24
V653FP1 6.5.30.4350 1040433 12-16-2004 6:29:30
V654FP1 6.5.41.5170 1044529 6-20-2005 4:41:05
V654FP2 6.5.42.5255 1044529 9-13-2005 19:10:34
V654FP3 6.5.43.6009 1044529 1-10-2006 5:46:05
V655 6.5.50.5334 1044529 12-01-2005 8:27:06
V655FP1 6.5.51.6101 1044529 4-12-2006 4:14:03
V655FP3 6.5.53.7081 1044529 3-23-2007 4:03:29
V656 6.5.60.7065 1044529 3-07-2007 8:28:18
V656FP1 6.5.61.7114 1044529 4-25-2007 13:23:46
V656FP2 6.5.62.7290 1044529 10-18-2007 8:34:02
V656FP3 6.5.63.8087 1044529 3-28-2008 8:04:55
V70 7.0.0.5229 1110016 8-18-2005 10:27:26
V701 7.0.10.6017 1114112 1-18-2006 8:55:28
V701FP1 7.0.11.6107 1114112 4-18-2006 7:46:39
V702 7.0.20.6269 1114112 9-27-2006 6:30:12
V702FP1 7.0.21.7010 1114112 1-11-2007 8:20:45
V702FP2 7.0.22.7134 1114112 5-15-2007 5:39:14
V702FP3 7.0.23.7347 1114112 12-14-2007 10:34:21
V703 7.0.30.7269 1114112 9-27-2007 9:53:28
V703FP1 7.0.31.8055 1114112 2-25-2008 16:37:33
V704 7.0.40.9082 1114112 3-24-2009 12:35:39
V704FP1 7.0.41.9201 1114112 7-22-2009 11:15:01
V80 8.0.0.7214 2248704 8-03-2007 11:07:50
V801 8.0.10.8038 1287560 2-08-2008 16:29:16
V802 8.0.20.8220 2041224 8-08-2008 15:52:06
V802FP1 8.0.21.9012 2041224 1-13-2009 14:45:24
V802FP2 8.0.22.9173 2041224 6-23-2009 13:35:50
V802FP3 8.0.23.9281 2035712 10-09-2009 10:50:17
V802FP4 8.0.24.9344 2035712 12-11-2009 9:53:00
V802FP5 8.0.25.10103 2035712 4-14-2010 11:08:46
V802FP6 8.0.26.10196 2035712 7-16-2010 10:01:42
V85 8.5.0.8340 2647432 12-06-2008 9:35:25
V85FP1 8.5.1.9166 2647432 6-16-2009 14:07:33
V851 8.5.10.9271 1676680 9-29-2009 11:27:55
V851FP1 8.5.11.10005 1676680 1-06-2010 11:14:31
V851FP2 8.5.12.10076 1676680 3-18-2010 11:10:06
V851FP3 8.5.13.10143 1676680 5-24-2010 5:33:57
V851FP4 8.5.14.10206 1676680 7-26-2010 11:33:37
V851FP5 8.5.15.10272 1676680 9-30-2010 7:46:10
V852 8.5.20.10222 1680776 8-11-2010 10:24:45
V852FP1 8.5.21.10333 1680776 11-30-2010 7:18:13
V852FP2 8.5.22.11081 1680776 3-23-2011 5:34:18
V852FP3 8.5.23.11191 1680776 7-11-2011 8:09:26
V852FP4 8.5.24.11321 1680776 11-18-2011 7:23:35
V853 8.5.30.11258 1869192 9-16-2011 8:32:53
V853FP1 8.5.31.12067 1870984 3-08-2012 7:36:40
Jeff Mitchell | 14 May 2012 12:00:42 PM ET | Littleton, MA | Comments (1) | Permanent Link
I'm down at Lotusphere, mostly sitting in the meeting room known as Asia 1 underneath the "IBM Lotus Notes Client" sign answering your deployment questions. Stop by!
Jeff Mitchell | 16 January 2012 04:13:22 PM ET | Littleton, MA | Comments (0) | Permanent Link
I recently ran across this article about combining Notes 8.5.1 and Sametime 8.5 into a single kit. For later versions of Sametime, this article is the recommended procedure. If you take a quick peek, you'll notice they recommend radically different procedures. The older method details how to manually merge the Sametime bits into the Notes installer. The later article recommends chaining the install kits for Notes and Sametime (hey that script looks familiar!). I was curious if the older method would work for later versions of Notes so I tried it out. Here are the steps I followed:
The following steps work best if run from a command prompt:
1. Create a working area on a drive with approximately 2 gigs of free space. For example use "C:\ComboKit"
mkdir C:\ComboKit
cd C:\ComboKit
2. Download the required installation kits:
Obtain the Notes 8.5.3 Notes client only web kit.
Obtain the Sametime 8.5.2 Addon installer.
3. Copy the downloaded files to the root of your work area.
4. Extract the required files from the downloads:
Run the Sametime 8.5.2 Addon installer. At the following dialog, select the 2nd option and change the installation path to the work area created in step 1.
After the kit is extracted, click "Cancel" on the "Choose Setup Language" dialog box to exit the installation. This will end the installation process before the Sametime Addon installer is run, and will leave the extracted kit contents in the specified directory.
Run the Notes 8.5.3 installer. At the following dialog, select the 2nd option and change the installation path to the work area created in step 1.
After the kit is extracted, click "Cancel" on the "Lotus Notes 8.5.3 - Install Wizard" dialog box to exit the installation. This will end the installation process before the Lotus Notes installer is run, and will leave the extracted kit contents in the specified directory.
5. Copy the required utilites.
In the directory where Notes 8.5.3 was extracted to there is a subdirectory named Utilities. In this Utilities subdirectory there is a zip file named NotesCustomizationKit_1_0.zip,'
This archive contains a utility used to update the Notes installation kit. It is called UpdateSiteMgr.exe. Extract it from the zip file and copy it to the root of the Notes extracted directory
6. Remove Sametime 8.5.1 from Notes 8.5.3 Install kit
Run the utility UpdateSiteMgr with the command line options "-r Sametime". This command will take a bit of time.
Time passes...
7. Prepare the Sametime addon
Copy the existing Sametime addon update site to a new name: updateSite.zip
Copy the existing Sametime addon install manifest to a new name: install.xml
UPDATE: It appears I was using the 8.5.4 version of UpdateSiteMgr which has a fix for a bug where some Sametime features are left in the manifest.
As Christian points out in the comments below, the following lines need to be manually removed from the manifest before the install kit will work correctly. Or you can use the 8.5.2 TrimUpateSite tool.
Around line 249 of deploy\install.xml remove these lines:
feature download-size="195" id="com.ibm.collaboration.realtime.browser.feature" match="greaterOrEqual" shared="true" size="163" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
feature download-size="286" id="com.ibm.collaboration.realtime.chat.logging.feature" match="greaterOrEqual" shared="true" size="254" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
feature download-size="339" id="com.ibm.collaboration.realtime.core.feature" match="greaterOrEqual" shared="true" size="354" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
feature download-size="582" id="com.ibm.collaboration.realtime.im.community.feature" match="greaterOrEqual" shared="true" size="550" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
feature download-size="408" id="com.ibm.collaboration.realtime.messages.feature" match="greaterOrEqual" shared="true" size="376" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
feature download-size="342" id="com.ibm.collaboration.realtime.people.feature" match="greaterOrEqual" shared="true" size="310" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
feature download-size="206" id="com.ibm.collaboration.realtime.rtc.core.feature" match="greaterOrEqual" shared="true" size="201" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
feature download-size="1358" id="com.ibm.collaboration.realtime.ui.feature" match="greaterOrEqual" shared="true" size="1392" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
feature download-size="122" id="com.ibm.rcp.realtime.livenames.feature" match="greaterOrEqual" shared="true" size="90" url="jar:${installer.root}/updateSite.zip!/" version="8.5.1.20110812-1126"/>
8. Add the Sametime 8.5.2 to Notes 8.5.3
Run the UpdateSiteMgr utility to merge the Sametime update site to the Notes update site.
Verify the updateSite.zip and install manifest were modified:
9. Run the new combined installer.
Jeff Mitchell | 7 December 2011 07:43:58 AM ET | Littleton, MA | Comments (6) | Permanent Link
These are the rough instructions on how to install and configure the Lotus Notes Smart Upgrade service feature on to a Windows Vista / Windows 7 that already has Notes installed but at a lower version level than Notes 8.5.3.
- Copy file SUService.exe to the Notes installation location on the target machine. By default this directory is "C:\Program Files\IBM\Lotus\Notes".
This can be done either directly on the machine or remotely. An Administrative account is typically required to write to subdirectories under the "C:\Program Files" location. The file SUService.exe will be installed as part of Notes 8.5.3 and can be copied directly from an installed version of Notes 8.5.3 to a network share, USB drive or other media.
- Create and configure the service on the target machine.
There are several ways to manually create services. This can be done either directly on the machine or remotely. Windows ships with a built in utility that allows service creation locally or remotely if the user is a Administrator of the machine. SC is the utility (http://technet.microsoft.com/en-us/library/bb490995.aspx , http://support.microsoft.com/kb/251192 ) To create the Notes Smart Upgrade service locally an Administrative user would type in the following command into a command prompt.
sc create LNSUSvc binPath= "C:\Program Files\IBM\Lotus\Notes\SUService.exe" type= own type= interact start= auto error= normal displayName= "Lotus Notes Smart Upgrade Service"
To create the same service remotely using the sc tool the Administrator would need to type the following command into a command prompt (where RemoteMachine is the name of the machine)
sc \\RemoteMachine create LNSUSvc binPath= "C:\Program Files\IBM\Lotus\Notes\SUService.exe" type= own type= interact start= auto error= normal displayName= "Lotus Notes Smart Upgrade Service"
- Once the service has been successfully created, it must be started prior to use. The SC tool can also be used to start a service, both locally and remotely. The following command will start the Lotus Notes Smart Upgrade service.
Locally: sc start LNSUSvc
Remotely: sc \\RemoteMachine start LNSUSvc
- To verify that the service is created and started successfully, the SC utility can be leveraged as well.
Locally: sc query LNSUSvc
Remotely: sc \\RemoteMachine query LNSUSvc
- Now that the target machine is ready to start the upgrade, the SUSetRunAsWizard would be run and the SURunAs.exe upgrade package would be generated as normal, using the SUSetRunAsWizard.exe from the Notes 8.5.3 Administrator install kit.
Jeff Mitchell | 14 October 2011 10:39:42 AM ET | Littleton, MA | Comments (12) | Permanent Link
We are aware of the missing ITW file from the Lotus Notes 8.5.3 install kits and are working on a formal technote etc. Until that is done I thought I'd just post the file here so you can get it now rather than later.
"The InstallShield Tuner for Lotus Notes configuration file (LotusNotes853.itw) was inadvertently excluded from the 8.5.3 Notes Standard Client, All Client (Notes, Admin, Designer) webkits and ISO images. The absence of this file will affect Administrators using the InstallShield Tuner for Lotus Notes to generate a transform file for customized installations on Windows.
Instructions:
- Download LotusNotes853.itw from the below file to the root of the Lotus Notes Client install kit.
Once extracted to the root of the install kit, customers can continue with normal Tuner operations."
LotusNotes853.itw
Some Frequently Asked Questions:
Who is impacted by this missing file?
The impact of this particular issue for customers is fairly minimal. The missing file is not an end user file. Only Administrators that generate transforms using the Tuner product are impacted. If you are not an Administrator and do not use the Tuner then you don't need the file. There are several other programs that allow transforms to be generated that do not require the missing file and will work perfectly without it. Once the file is downloaded and copied to the kit directory, no further work is required of the Administrator.
Why don't you guys just repackage and re-release the install kits?
As usual, it's just not that simple. Repackaging the kits would require that we rerun all the end game testing on the new kit. It's not acceptable to IBM quality standards to simply release a kit, even if it's just "repackaged", without full testing.
Why did this happen and how do you prevent it from happening again?
In this particular case, a test for this file's existence in the install kits prior to shipping wasn't run. It will be automatically run on all kits prior to shipping from now on.
Jeff Mitchell | 4 October 2011 01:37:16 PM ET | Littleton, MA | Comments (3) | Permanent Link
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.
Dev: Thanks.
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) | Permanent Link
Lotusphere 2011 Presentation Slides -ID202 Deploy In Style - Make Your Notes Client Install Perform!
The title of this presentation was "Weapons of Mass Deployment" but that didn't get past the censors.
ID202.odp
Jeff Mitchell | 2 February 2011 09:13:37 AM ET | Littleton, MA | Comments (0) | Permanent Link
As many of you are well aware, the SURunAs utility does not work on Windows Vista and Windows 7. Well I'm happy to let you know that this will change in the 8.5.3 release of Notes. Coding is still in progress so the updated feature will not be available in the code drop 2 release of Notes 8.5.3 that is coming soon. However it should be in the next drop after that one.
A high level synopsis of the new design:
The Lotus Notes installer will be modified to add a new Windows service during the installation. This new "Smart Upgrade Service" will run in the local system account, which has local administrative privileges and will provide a mechanism for Smart Upgrade to perform upgrades of Notes for users that do not have the capability themselves. Smart Upgrade will still use SURunAs to wrap the deployment package but will communicate with the SUService which will then validate the communicated information and perform the requested upgrade. Finally the SUService will communicate the results of the installation back to SURunAs which will then return the results back to SmartUpgrade. The communication between the client processes running in the user session and the service process running in the system sessions will be encrypted and validated to prevent unauthorized transactions.
And a picture of this new design:
Jeff Mitchell | 2 December 2010 10:56:11 AM ET | Littleton, MA | Comments (7) | Permanent Link
Some of you have noticed a new feature that was sneaked (snuck?) into SURunAs in Notes 8.5.2. Rather than typing up a long winded description of exactly what this feature does, I'll let this picture do the talking.
If you click the highlighted check box, you get the following:
Pretty cool huh? The username and password requirements are ignored. Now you have the ability to create deployment packages similar in functionality to the Notes webkits. namely self extracting executables that run a program after extraction. We added this feature because a number of you requested the ability to customize our install kits and still use them in SmartUpgrade as attachments.
So now you can extract an install kit from one of our webkits, customize it to your hearts content using a transform and then repackage into a single file executable for use with SmartUpgrade. You simply include the transform in the list of files to repackage and then specify it on the command line used to launch the embedded executable (typically setup.exe). Like so:
This feature is completely version independent so you can grab the SUSetRunAsWizard.exe from an Notes 8.5.2 Designer (Allclient) installation and use it to repackage any Notes version you need to. Happy repackaging!
Jeff Mitchell | 9 November 2010 08:15:48 AM ET | Littleton, MA | Comments (0) | Permanent Link
If you don't know what NSD is you should probably go read this,
Once upon a time, NSD had a command line option -kill. This is the description of that option from NSD's help.
Runs NSD in a special mode that kills all Notes/Domino processes in the current "partition" (i.e. all processes that are accessing Notes shared memory and that are running from the same location as NSD
Sounds pretty ominous huh? We'll it was. It is also slow and dived deep into the OS to do the dirty work of getting Notes killed. At some point in NSD's evolution, a lighter implementation of -kill was created. This new approach leveraged the NotesInit and NotesTerm API functionality that all processes that worked with Notes invoked. The NSD -kill option was changed to kill processes listed in the pid.nbf. "Wait what is the pid.nbf you ask?" "Go read this", I reply. However the old sledgehammer functionality was kept around and hidden under the command line option -k.
"That's nice, but so what?" you may be asking yourself. That's a pretty good question. For 99% of the time (a percentage I made up btw) -kill should be perfectly sufficient for killing Notes processes. However ever so often a rogue application somehow manages to get into a state that either doesn't update the pid.nbf properly or fails to be terminated even thought it's listed . In those cases NSD -k is a possible solution.
Happy Mitch?
Jeff Mitchell | 14 October 2010 02:18:51 PM ET | Littleton, MA | Comments (0) | Permanent Link