Application Packaging: Silent Installers

Licensing

Software clickwrap agreements require a user to click “I agree” or “I accept” before the software can be downloaded or installed. Recent court decisions have made it clear that clickwrap agreements are legal and binding contracts and therefore are subject to University contracting policy. Under this policy, these agreements may only be entered into by someone who has authority to enter into a contract binding the University. Another issue that the University faces with these agreements is that they generally contain provisions that are prohibited by North Carolina law.  All applications used at NC State must have its software agreement evaluated and approved.

The software we package and deploy falls into two main categories:

  • Freeware
  • Licensed Software

Licensed software does not necessarily mean paid-for software; it does mean the software has a licensing requirement, which may include but is not limited to:

  • Intended Purpose: Teaching, Research, Administration, infrastructure, and so on
  • Installation Location: Physically on campus or not
  • Ownership of the Hardware (where the software is installed): University-owned versus personal machines; college or department
  • Intended User(s): Are the users in a given discipline, taking a certain class, or affiliated with the university?
  • Participation in a program: For example: Microsoft Imagine

This information will be needed once you create the application.

Understand the Type of Application

Perform the following procedure to gather and document information about the application:

  1. Create a document to record your notes. Record your findings…
    1. Is it a Single installer or separate 32-bit and 64-bit installers?
    2. What Type is it?
      Microsoft Installer (MSI), Installshield installer, Wise installer, or some other installer type
  2. Get a copy of the installation media from the Software Manager, or download it from a known location.
  3. Determine whether it has a single installer or separate 32-bit and 64-bit installers.
    NOTE: If separate installers, it is likely you will need to run through this entire process twice.
  4. Determine whether it is a Microsoft Installer (MSI), an Installshield installer, a Wise installer, or some other installer type.
    NOTE: Typically, you can find this information in the installation instructions from the vendor. If not, you can determine this by looking at the properties of the binary or running the installer with the command-line parameter, <forward slash><question mark>: /?
  5. Determine whether you need to consider soft or hard prerequisites or dependencies. Record your findings…
    1. Dependencies:
      List any hard dependencies required
      Hard dependency: If unavailable, the application cannot install (or function) on the machine. This failure could include shared Microsoft components like .Net Framework or C++ redistributables or something bundled with the installer. Or, it could be a case where you are packaging an add-on that requires the primary application to be on the machine prior to this installation.
      List any soft dependencies required
      Soft dependency: If unavailable, it changes the way one or more applications function, but will not inhibit the installation or functioning capability.
    2. Examples include:
      MS Office for MathType — MathType can be used as a standalone application or as a plugin for Office.
      Surfcam and Solidworks — A plugin allows Solidworks to export CAD drawings in a Surfcam file format, which is the format used by some of ISE’s multi-axis lathes.
  6. Based on the installer type, you will need to figure out the what the installer requires regarding Command-line Parameters or Transforms. Record your findings…
    1. Command-line Parameters
      1. Non-Installshield MSI
        Install: msiexec /i <NAME OF MSI.msi> /qn
        Uninstall: msiexec /x <PRODUCT CODE> /qn
        MSI command-line options (msdn.microsoft.com)
        Msiexec.exe Command Line: Advanced Installer User Guide
        Passing MSI Properties: PROPERTY=<some string> at the command line, before the /qn
      2. Installshield
        Install: setup.exe /s /f1<answer file>
        Uninstall: C:\Program Files (x86)\InstallShield Installation Information\<PRODUCT CODE>\setup.exe /s /f1<answer file>
        To record an answer file, run the installer (or uninstaller) with this parameter:
        <forward slash><the letter r>: /r
        To pass command-line switches to an embedded MSI, run the installer with this parameter, <forward slash><the letter v>: /v:
        Setup.exe and Update.exe Command-Line Parameters
      3. Wise
        Install: setup.exe /m=<answer file> /s
        Uninstall: unwise.exe /S c:\my\program\directory\install.log
        Command-line parameters for WiseScript (support.symantec.com)
      4. InnoSetup
        Install: /SILENT or /VERYSILENT or /SUPPRESSMSGBOXES
        Response files: Use /SAVEINF and /LOADINF to create and use InnoSetup response files
        InnoSetup Setup Command Line Parameters

      5. Nullsoft Scriptable Install System
        Install: Installer.exe /S
        Uninstall: C:\Path\To\Program\Directory\Uninstaller.exe /S
        http://nsis.sourceforge.net/Docs/Chapter3.html#installerusage

    2. Answer Files—A number of applications use answer files; for example, Visual Studio, Labview, SAS, Ansys, and so on. The process for creating answer files is different per installer type. Some installers, like Labview, are completely customized.
    3. Transforms—A Transform is an overlay to the MSI database; About Transforms (msdn.microsoft.com).  Transforms can be made manually using Orca, automatically using AdminStudio response transforms, or sometimes using a custom app developed by the application vendor.
  7. Make two batch files: install.bat and uninstall.bat
  8. Once you have a good idea of the command-line parameters most likely needed, put them in batch files for installation and uninstallation so you aren’t trying to remember them; you can be consistent if you need to do multiple test installations.
  9. Do the installation instructions indicate a required reboot? Record your findings…

Setting Up the Environment and Doing a Test Install

  1. Make sure the machine you choose is fully patched before using it for a test installation.
  2. If you determined there are hard dependencies, determine whether they are available from SCCM:
    1. If available from SCCM, use the installer from the \\wolftech.ad.ncsu.edu\files\sccm source location to install them on the machine.
    2. If not available from SCCM, install them on the computer before working on the application and save a copy of the installer.
    3. Record that the dependency is installed on the machine; itemize the hard and soft dependencies installed.
  3. Make sure MSI logging is enabled:  Enable Windows Installer logging (support.microsoft.com)
  4. At the least, you need a copy of the Sysinternals psexec.exe tool.
  5. You should probably have copies of the following software available:
    1. The whole Sysinternals suite
    2. LUA Buglight — For identifying local permissions issues
    3. Orca
  6. Reboot the machine to make sure everything is clean from patching and installing dependencies.
  7. Log in as an account with USER-level permissions on the machine.
  8. Run the installer as the local SYSTEM account (using the -s switch) with the ability to interact with the desktop (using the -i switch):
    1. Run as cmd.exe as an account with ADMINISTRATOR-level permissions on the machine.
    2. Within that cmd.exe shell, run: psexec.exe -s -i <batch file from above> Record your findings…
      1. Success or failure?
      2. Document any errors.
      3. Document any windows that appeared.
      4. Unexpected reboot required? If so, document the cause.
        1. If the machine required an unexpected reboot, one of the following reasons is the likely culprit:
          1. The machine installed a system service and the installation instructions were insufficient.
          2. The machine replaced files the operating system was using. On a clean machine, this means Microsoft components are embedded in the installer, and that one of the following conditions is also true:
            1. Those components are newer than what is on the machine, which means we should go find them as dependencies.
            2. The installer is forcing older binaries over newer ones, which is bad.
  9. Launch the application and take note of any pop-up windows. Record your findings… For each pop-up window, record the following information:
    1. Required for application functionality? (Yes/No)
      Is the pop-up window asking a question required for the application to be useful?
      If so, that is something we need to address as a command-line option or via Group Policy.
    2. EULA license? (Yes/No)
      Is it a EULA license?
      If so, NCSU staff are not allowed to accept EULAs, so we should attempt to silence it either as a command-line option or via Group Policy.
  10. Try loading an example project (or run some example code) in the application. Record your findings…
    1. Success or failure?
    2. Document any errors.
    3. Document any permissions errors, which indicate the application is not designed to run in a USER-level permissions environment.
  11. If permissions errors occur, run the application through LUA Buglight to determine the elevated permissions required.
    1. Throughout the application run, LUA Buglight creates a log of the elevated permissions required.
    2. We will need to address those via Group Policy.

Doing a Test Uninstall

  1. Run and update the uninstall batch script until it is bug-free:
  2. Make sure the application is closed.
  3. Run the uninstall batch script you created. Record your findings…
    1. Success or failure?
    2. Document any errors.
    3. Document any pop-up windows.
  4. Clean up the remnants:
    1. Update the uninstall batch file… For all remnants not benign, update the uninstall batch file to clean up every left over piece of the install. This uninstall batch file will be used later with the SCCM deployment type.
    2. Look in the following places for remnants of the application still on the machine, identifying all remnants not benign:
      1. Programs and Features
      2. HKLM\Software
      3. HKLM\Software\Wow6432Node
      4. C:\Program Files
      5. C:\Program Files\Common Files
      6. C:\Program Files (x86)
      7. C:\Program Files (x86)\Common Files
    3. For each, determine whether it was a chained installer, or just left over files/reg keys. If it is a chained installer, you will need to determine how to automate the uninstall of each.