This story dates back to the year 2009 when I was struggling with a deployment of scientific software called Origin, version 8 at the time. Origin is used for statistics, curve fitting, charts and similar tasks. A good example of program that I know how to deploy but can't really tell how to use it. Well, version 8 setup was quite a mess and it turned out that there was no way to do a centralized deployment. There were issues originating from the old code the and the idea that user always has admin rights. For example, Origin tried to install fonts when a user accessed a feature in the program which needed those fonts. Without admin rights it just failed miserably. Eventually I repackaged the whole program (using WiX Toolset, of course) into a well-behaving msi package containing all necessary files, registry settings from self-reg .dll's, font files, etc. I had a few emails with "David" from OriginLab and they understood the situation and clearly had a vision to improve the setup process. Thanks to David and others who have been involved in improving the setup after that. Now six years later while deploying Origin 2015 I was more than happy to see a lot of improvement had been made since the last time. (Newest version, 2015 Service Release 2, is actually version 9.2 but we must admit that 2015 is a lot more impressive than nine-point-two.)
First step: Get the msi package (not .exe)
For some reason I can't completely understand Origin has two different installers. First one is an InstallShield Installer package. It has everything you can hope for including installers for required Visual C++ Runtime libraries and hotfixes for Windows XP to get those installers installed. On the downside that package is not quite usable for sysadmins and enterprise deployment. The second installation type is the msi package. To be exact, it is two msi packages. One 32-bit version of Origin for x86 Windows and one 64-bit package which has both 64- and 32-bit versions of Origin. In any case, if you are going to deploy Origin get those msi's from OriginLab Support page (link below). The msi's don't have any Visual C++ library prerequisite checks but support configuring Origin and with msi packages silent installation is not a problem. A lot of the customization and deployment process is covered on the support page documentation. You can even download an .mst file for configuration and a batch file to install those missing Visual C++ Runtimes. Excellent job.
See OriginLab support page "MSI Installation"
Second step: Configurations in Origin.ini
Origin has simple and easy way to define defaults for the new users. If I had written a book called "User settings management best practises for software vendors" or something like that this would be in the book. Among all cryptic files, there is a file called "Origin.ini"
in Origin's installation folder, apparently "C:\Program Files\Originlab\Origin 2015\"
for most of us. When a new user - in the sense that this user has never launched Origin before on this specific computer - launches Origin, she will get Origin.ini
copied into folder "OriginLab\2015\User Files"
under her local Documents folder. Basically this means that whatever settings you can lure into the Origin.ini under Program Files, user will get those as default settings. Simple and effective. But the real power of using the quite ancient .ini files comes from the fact that Windows Installer is able to modify them during installation as a Standard Action. So we can just define the desired changes into our .mst file and let Windows Installer take care of the rest. See the description of IniFile table on MSDN
Setting user path is described in the Origin installation help. And this is a setting in Origin.ini. So all we need to do is to add a line in the IniFile Table. It has already been made in the OriginLab .mst file. Below is the row added into IniFile Table.
Basically that means that into Origin.ini (which comes with the package and is in INSTALLDIR folder) under ini-file section [UserFiles] we add a new line "Path=1". And this change is tied into Component INISet_0001 already in the package. In a resulting .ini file it will look like this:
We want to add a few more entries in Origin.ini. To get rid of the registration prompt for new users - which is especially disturbing and useless for students in the computer lab - we add another line in Origin.ini under "Registration" section to get the Origin.ini look like this:
How did we know what to add? I simply installed Origin, launched it twice until I got rid of the registration message and went to see the changes in registry and user's instance of Origin.ini. Even without Process Monitor or diff tool like WinMerge it didn't take too long to find out the new line "RegDlgNoShow=1" in Origin.ini file. To test if it really works, I added that manually into master Origin.ini, cleared user settings, launched Origin again and didn't get registration prompt anymore.
Skip "Tip of Day"
Finding out how to get rid of the tip of the day prompt was similar to the registration prompt. Under Origin.ini we need a cryptic line 20046=1 under "ReminderMessages" section.
So we need to add two more rows to the IniFile Table:
Third step: License server
As the version we have purchased uses a FlexLM licensing with concurrent user licenses we need to add a FlexLM license server information file USE_LICENSE.lic
to the clients. The file itself is a simple text file which has license server name and port. OriginLab .mst has also that part covered. You just add the the USE_LICENSE.lic
file into the same folder as Origin's .msi and define the file in the .mst being a resource outside of the .msi. But there is something more interesting concerning the uninstall.
After uninstall a single file "OLicense.lic"
was left alone in "C:\Program Files\Originlab\Origin 2015\"
(which is [INSTALLDIR]). The file defines some licensing information and is not added by Windows Installer Standard Actions but created with one of the Custom Actions. To make the file go away during uninstallation and finish what Custom Action has left behind we must define the file OLicense.lic in RemoveFile table. When the file gets deleted during uninstall process the whole INSTALLDIR directory "C:\Program Files\Originlab\Origin 2015\"
will become empty and magically disappear. (You surely remember that Windows Installer is clever, selfish and lazy enough not to clean up any mess it hasn't done itself. It happily leaves a directory structure unremoved if there is a file someone else put there. That's a difference between boy scouts - or girl guides - and Windows Installer going camping. When scouts leave the forest it is cleaner than it was before they came. When Windows Installer leaves the forest is just as clean as it was before. Oh, and when Custom Action leaves the forest there is usually trash all over the place.) So to be prepared for uninstallation, too, adding one line in the RemoveFile table will do the job:
See the description of RemoveFile table on MSDN
Fourth step: Shortcuts
I felt there was a way too many Shortcuts in the Start Menu so in the .mst I deleted the following rows from the Shortcut Table:
- shortcutAddorRemoveFiles (Uninstall shortcuts are useless for standard users)
- shortcutLabVIEWSamples (This was quite useless because there is already shortcutSamples and on top of that this didn't ever work because it happened to have a wrong path)
- shortcutOriginFolder (Yes, Origin is installed here but there is nothing for a user)
If you would like to deploy the package with a different set of shortcuts just delete the shortcut rows you - or the users - don't need.
Ready for deployment
Now we have Origin 2015 .msi package (actually the .mst file) prepared for deployment that we know (after testing) will just work from the installation to uninstallation. Just deploy the package and make sure that you have also those required Visual Studio Runtimes installed!