2

Is there a way to create an MSI file with the product key for the installer? In this particular case, I wish to deploy Office 2003 to a couple dozen workstations, but wish to do so silently, and without any intervention from the user. However, in my testing so far, it runs silently until it needs the product key to continue. Can I somehow 'bundle' the product key into the MSI?

2 Answers 2

5

You can create a MST file to transform the official MSI to do what you want. Check out the official documentation on the process at http://office.microsoft.com/en-us/office-2003-resource-kit/custom-installation-wizard-HA001140170.aspx.

3
  • That worked perfectly, at least for Office 2003. But beyond that, generally, how can I plug in the product key into an MSI for any other installation package? Dec 13, 2011 at 20:51
  • 2
    @CitizenChin It will depend on the vendor, product and version of the title you're deploying. For Office 2010, MS built the "ork" functionality right into setup.exe. For some vendor's products, add a key is a simple as the correct value in the PROPERTY table. You may find AppDeploy helpful for some titles. See their "Package KB", in particular the "Command Lines" sections for titles you're deploying.
    – jscott
    Dec 13, 2011 at 20:55
  • Exactly. Every software package will have it's own process. Here are some good resources for researching: msfn.org/board/forum/80-application-installs appdeploy.com Dec 13, 2011 at 20:59
2

I dug up my old notes on the subject and am providing them here. I recommend reading the documentation to better understand the process but this below should get you going very quickly.

  1. Obtain the 'clean' installation source for the VLK version of Office 2003. (Either the eOpen website or installation media will work.)

  2. Copy it to a local folder for modification. I chose C:\office2k3.

  3. Replace setup.exe in the install root with the one from the self-extracting EntSetup.exe (http://www.microsoft.com/office/orkarchive/2003ddl.htm) This enables additional functionality for enforcing localized installation source which will be used later.

  4. In your installation tree you should see a 'FILES' directory. Under this directory, create a new one named 'PATCHES'.

  5. Using WinRAR or the command-line, extract each service pack and hotfix to the directory created in step 4. You do not need further subfolders. All files can coexist at this level. The installer will handle prioritizing of the service pack and hotfixes.

  6. Under 'PATCHES', open OHotFix.ini with a text editor and 'OHotfixUILevel'. Set it to 'q' for silent deployment.

  7. Install the Office 2003 Resource Kit (http://www.microsoft.com/office/orkarchive/2003ddl.htm) and open the Custom Installation Wizard. You'll create a MST file that is used at installation to fine tune setup options including the installation key. Save this MST file to the same path as PRO11.msi. I even borrowed PRO11 for the filename and went with PRO11.mst for convenience.

  8. The rest of the deployment preparation will occur in Setup.ini, find it under FILES\SETUP. Make a backup of this file. I recommend using setup.ini.bak. You can always then roll back to the unedited version when you mess something up!

  9. Locate the [MST] section of Setup.ini and reference the created MST file. If you placed the file in the same path as the installer and MSI, you don't need a path. My line looks like MST=PRO11.MST.

  10. We'll need to manipulate the installation GUI so that it will run without user interaction. Under [DISPLAY] set Display=reduced. This is equivalent to qb- at the command-line so you get the progress indicator.

  11. The next step is to setup version control. I'm sure I'll be adding hotfixes and changing tweaks in the MST file. Let's start keeping track of that stuff. I figured a good way to do it, would be to log a version number using the date of modification in the installation log. Under [LOGGING], I set the filename using Template=Microsoft Office 2003 Setup YEARMMDD(*).txt The date will coincide with a changelog entry in CHANGELOG.txt which I've created in the installation root. Now when I later go to a machine that has a problem, I can tell what's been fixed since that particular installation by getting the date from log file in the %WINDIR% folder. I'll know if that particular problem has been fixed.

  12. The next step is to enforce a localized installation cache or repair/reinstall. Many remote users have needed this and it's been broken since we started using Administrative Installation Point (AIP) to deploy office. (Note: we are no longer using AIP.) Fix it, with [Cache] ENFORCECACHE=1

  13. The last step is to setup the chained installs. These run after Office setup completes in numerical order starting with the Service Packs and Hotfixes.

[ChainedInstall_1]
TaskName=Integrate SP3 and Hotfixes
TaskType=exe
Path=.\FILES\PATCHES\OHotFix.exe
IgnoreReturnValue=1

[ChainedInstall_2]
TaskName=Install File Format Compatibility for Office 2007
TaskType=exe
Path=.\FILES\ADDONS\FileFormatConverters.exe
Cmdline=/quiet
IgnoreReturnValue=1

Setup can be ran now manually by double clicking setup.exe or by script with no need for commandline arguments. Everything is conveniently handled with setup.ini. As new updates are released, extract them and place the MSP file in the PATCHES directory then create the entry in your CHANGELOG to note the change. Don't forget to also update the date in setup.ini

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .