/bundles/itninjaweb/img/Breadcrumb_cap_w.png

Blog Posts tagged with Software Deployment

Ask a question

AppDeploy Command Line Installation Tips

Command Line Installations
Triggering unattended application installation from the command line.

The surest way to deploy an application with the least amount of issues is to use the setup routine designed for the application in the first place. Repackaging is necessary when a using a deployment tool that requires it, or when a command line installation is not supported. Often poorly documented, or not at all, you may find it difficult to discover how to go about this. You may also be surprised at the number of ways that exist to silently install an application from the command line when you know where to look and what to try. By "from the command line" we are talking about the use of command line switches to initiate the unattended installation of software such as "SETUP.EXE /SILENT". There are a number of steps you can take in your attempt to uncover a means of command line installation and we will cover them all here. As always, if you know of something over looked, shared in the comments below!

  • Check Your Resources: Places To Look 
  • Windows Installer Setups
  • Built In Command Line Support
  • Troubleshooting Your Command Line Installation

Check Your Resources: Places To Look

ITNinja

It is the goal of ITNinja to be the best place to start your search for any information relating to deployment. This especially includes how to deploy various applications. In working toward this goal ITNinja offers a Software Knowledge Base. This feature of our site provides consolidated details on the deployment of specific applications. We also have a well used Q&A feature here where you can ask others for help, or just see if another visitor has already addressed your question.

Included Product Documentation

In the form of a README.TXT or other included document you may get lucky and find the information you need. Unfortunately, vendors make it difficult if not impossible to scrape together any help by very often overlooking the issue of remote deployment altogether. Still, to expend efforts trying to uncover information that may have been provided to you up front is certainly not the best use of your time. Take a look- you may be fortunate enough to have the answer right in your hands.

Online Support

Many vendors now provide a knowledge base and user forums at their websites. This is an excellent source for finding silent installation information. You are unlikely to find much information in a FAQ, but there may be a knowledge base article covering the topic. The most likely place though, is the user forums or message boards where another user has come before you in search of the same information.

SMS Package Definition File (PDF)

No matter if you are using SMS or not, a Package Definition File is a great source of command line options if your software happens to include one.

PDF files are actually INI files, which may be viewed with a simple text editor such as notepad. Look for the "COMMANDLINE" entries in the file for unattended installation command lines. Many older Microsoft applications include PDF files and there have been a number of other software companies that had deployment of their applications in mind and also provided a PDF. For more information on PDF files check here.


Windows Installer (MSI) Setups

Microsoft's new Windows Installer format is the latest answer to solving issues with installation, removal and, yes, deployment of applications. A Windows Installer based installation is currently a logo requirement for Windows 2000 (and later) compatibility. This means more and more applications are surfacing as MSI installations. You are still likely to see a "setup.exe" so don't stop looking when you see it. A program named setup.exe is still often included as a wrapper for the Windows Installer installation, which checks for the existence or for the installed version of the Windows Installer service. If it is missing or out of date, the setup.exe will install or update the service before triggering the Windows Installer installation process. Do a search of your installation media for a file with a "MSI" extension to be certain. When found your command line installation just became one of the best documented of its kind:

I recommend the following command line for the silent installation of MSI setups:

MSIEXEC.EXE /I "path and filename of MSI" /QB- /LWAMOE c:\temp\install.log ALLUSERS=1

  • MSIEXEC.EXE - the MSI executable, the program that performs the actual installation of the application.
  • /I - this switch informs the Windows Installer to install the specified application (as opposed to removing, reinstalling or repairing the application)
  • /QB-  - this switch instructs the Windows Installer to perform the installation with a basic user interface requiring no dialog boxes to be displayed. You might also use /QN to perform the installation with no user interface at all.
  • /LWAMOE c:\temp\install.log - this switch instructs the Windows Installer to generate a log file at the specified path and file name (in this case, "c:\temp\install.log") and to include the following details: Non fatal errors, start up actions, out of memory or fatal exit information, out of disk space messages and all error messages. There are several other options (see the AppDeploy FAQ for more details) to include all possible details in the log file use "/L* c:\temp\install.log"
  • ALLUSERS=1 - including this will cause the shortcuts for the application to be placed in "all users" instead of the current user profile.

See the Windows Installer (MSI) tag for more information.


Built In Command Line Support

If your installation is not a Windows Installer setup and no specific information can be uncovered regarding a means of silent installation, you may still have a very good alternative. If the setup.exe was created with an InstallSheild authoring program, a number of command line switches are supported by the setup that may help you to deploy it.

Integral is the ability to create an answer file and then use that answer file to perform the silent installation of the application. It does not always work just the way you would like, and keep in mind that the vendor may not even be aware of this ability they have provided. However, it often works just fine and should be pursued as a means of deployment before resorting to repackaging the application.

Create an answer file by launching the setup with the "/r" switch. This will take you through the normal series of dialogs to the completed installation of the application. When done, simply copy the "setup.iss" file created in your system directory (normally, c:\winnt\setup.iss) and place it in a folder along with the application's other installation files. This folder is often a copy of the installation CD on a network share, but the end result should be that you have your created setup.iss file and the application's setup.exe file in the same folder.

To kick off the silent installation of the application you may now simply specify the "/s" switch to make use of the answer file you have created. During installation there will be no prompts or indications the installation is taking place or complete. View the Windows Task Manager to see the process activity if you are interested.

You can view the setup.iss file in a simple text editor such as notepad to see what was recorded in the answer file. If serial number information was requested during installation, you will hopefully see it reflected here. This is most often the point of failure for use of an answer file such as this. If the capture of your responses does not include the serial number information, or any information for that matter, the installation may hang, fail or a pop up dialog may be presented requesting missing information. For this reason through testing should be performed (as always.)

See our full listing of InstallShield command line switches for more detail.


Troubleshooting Your Command Line Installation

Nothing happens at all? If you are watching the task manager processes and do not even see your setup initiating, your call to it is in error. Make sure all files referenced are where you are specifying them to be. If you are not specifying a path, that too can be your problem. In a batch file for instance, the current directory may reset to the system directory where your installation files can no longer be found. To ensure this is not your problem, specify the entire path to all files referenced (when spaces are involved in directory or file names, be sure to include them in double quotes.)

MSI

If something goes wrong during installation, you may see the dialog with the progress bar moving in reverse. This means an error was encountered and the Windows Installer is putting everything back the way it was to avoid problems. You can easily see what the problem is by viewing the log file created by the Windows Installer (see recommended command line above with /L switch)

ISS

If you see your setup start in the Windows Task Manager (processes tab) and it remains while utilizing zero CPU cycles- you have a problem. Likely there is a dialog response not being provided by the answer file and due to the lack of a display, you cannot see where the problem lies. For more switches you can use in troubleshooting, check here.

No SETUP.ISS file is generated? First make sure you are dealing with an InstallShield setup. Some vendors have been known to wrap their setup programs in self-extracting archives. If you believe this to be the case for your situation, initiate the installation and at the first dialog prompt change windows (do not abort the installation) and browse to the TEMP directory (by default this is in your profile directory "C:\Documents and Settings\username\Local Settings\Temp" for Windows 2000 and later). Here you may find a temporary directory generated that contains the actual installation files. You may then copy the installation files from this directory elsewhere (it is removed when the setup is completed or aborted.) The copy of setup.exe found here is very likely to support the process documented above (if it is an InstallShield setup and not an MSI setup or other vendor generated setup program.)

Check the log file generated in the setup.exe directory for its [ResponseResult] section. InstallShield places one of the following return values after the ResultCode keyname:

0 Success.
-1 General error.
-2 Invalid mode.
-3 Required data not found in the Setup.iss file.
-4 Not enough memory available.
-5 File does not exist.
-6 Cannot write to the response file.
-7 Unable to write to the log file.
-8 Invalid path to the InstallShield Silent response file.
-9 Not a valid list type (string or number).
-10 Data type is invalid.
-11 Unknown error during setup.
-12 Dialogs are out of order.
-51 Cannot create the specified folder.
-52 Cannot access the specified file or folder.
-53 Invalid option selected.
 

Still No Luck?

Perhaps there is some undocumented process you can uncover. Below are some command lines found to work for other applications in the past, try "setup.exe /?" first then go through the list below- you may get lucky!

  • setup.exe /q
  • setup.exe /qn
  • setup.exe /silent
  • setup.exe /s
  • setup.exe /NoUserInput
  • setup.exe /unattended
  • setup.exe /CreateAnswerFile
  • setup.exe /quiet

Please use our Q&A system to discuss these and other issues regarding the deployment of specific applications and deployment in general. Here the maximum number of experienced desktop engineers will have an opportunity to respond and all may benefit from it.

 Bob Kelly 9/23/01, Updated for ITNinja references/links on 11/8/12

 
View comments (1)

AppDeploy: Articles: ActiveSetup

Active setup provides a solution when the aim is to deliver user based components when no advertised entry points exist in an MSI package.

Most packages will contain some kind on entry point; commonly an advertised shortcut. When launching this kind of shortcut Windows Installer will check the keypath of the component the shortcut belongs to and verifies that the component is installed. If it is found to be missing Windows Install will kick off a repair.

This provides a great solution for installing current user data when the package is not installed in the user context. It is also a very good reason why you should never mix machine and user data in the same feature.

So what do you do if there are no shortcuts to advertise? Active Setup will solve the problem.

An MSI package has been created to install an Outlook plug-in. This package installs both user and machine data. User preferences are stored as a combination of HKCU registry and a XML file written to %USERPROFILE%. As this application is a plug-in it does not contain any shortcuts. There are no other advertised entry points that might trigger a repair.

Further, this package is installed by the privileged account NTAUTHORITY\system. In this situation the user registry and XML file will be delivered to the Administrators profile and will never be installed for the user. This is when using active setup is appropriate.

Implementation
On logon the following registry keys are compared:
HKLM\Software\Microsoft\Active Setup\Installed Components\<UID>
HKCU\Software\Microsoft\Active Setup\Installed Components\<UID>

<UID> has to unique; it is good practise to use a GUID.

If the HKCU key is not found the contents of the string value StubPath is executed. The HKLM key is then copied to HKCU.

The executable in StubPath can be anything (a VBS script, a regsvr32.exe call, etc), but our aim, in this example, is to deliver missing current user data from a previously installed MSI. To do this we need to force the package to repair so Msiexec.exe will be used:

Msiexec.exe /fpu/qn

/f - Repair
/p - only if file is missing
/u - all required user-specific registry entries

If you choose to, the entire installation can be repaired:

Msiexec.exe /fauvs/qn

Example HKLM installed components key
 
HKLM should look as follows:
 
[HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{44CCA842-CC51-11CF-AAFA-00AA00B6015B}]
"Version"="1"
"StubPath"="Msiexec.exe /fpu {44CCA842-CC51-11CF-AAFA-00AA00B6015B}"

Where a version is included; StubPath will only execute if the version of HKCU is less than the version of HKLM.

When a new user logs on Windows will find the HKCU active setup key missing, run Msiexec.exe with the repair arguments from StubPath and copy the HKLM key to HKCU. Next time this user logs in the repair won't run as the key already exists in HKCU.

Charlotte Gonella
charlotte_gonella@hotmail.com
June 2007

View comments (6)

InstallShield Setup Silent Installation Switches

Those setup.exe files generated with InstallShield inherently support the creation and use of answer files that may be used to silent install applications. Although it has no logic to handle anything not expected by the answerfile (more or less dialogs, more or less options in a dialog) it can be a helpful means of installation for some applications. The supported switches are as follows:

-d

Runs setup in debug mode. The -d switch also includes a [pathonly] option for specifying the path of the Setup.rul file. For more information, refer to the Visual Debugger help file.

-f[path\CompiledScript]

Specifies an alternate compiled script. Unless the compiled script (.ins file) also resides in the same directory as that of Setup.exe, the full path to the compiled script must be specified. _setup.dll must also reside in the same directory as your .ins file. For example, setup -ftest.ins will launch setup using Test.ins instead of Setup.ins.

-f1[path\ResponseFile]

Specifies an alternate location and name of the response file (.iss file). If this option is used when running InstallShield Silent, the response file is read from the folder/file specified by[path\ResponseFile]. If this option is used along with the -r option, the response file is written to the folder/file specified by[path\ResponseFile]. If an alternate compiled script is specified using the -f switch, the -f1 switch entry must follow the -f switch entry.

-f2[path\LogFile]

Specifies an alternate location and name of the log file created by InstallShield Silent. By default, Setup.log log file is created and stored in the same directory as that of Setup.ins. If an alternate compiled script is specified using the -f switch, the -f2 switch entry must follow the -f switch entry.

-m[filename]

Causes Setup.exe to generate a Management Information Format (.mif) file automatically at the end of the setup. Do not include a path - the .mif file is always placed in the Windows folder. [filename] is optional. If you do not specify a filename, the resulting file will be called Status.mif.

-m1[serial number]

Tells setup to place the indicated serial number in the created .mif file.

-m2[locale string]

Tells setup to place the indicated locale in the .mif file. English (ENU) is the default; refer to Microsoft documentation for a complete listing of locale strings.

-r

Causes Setup.exe automatically to generate a silent setup file (.iss file), which is a record of the setup input, in the Windows folder.

-s

Runs InstallShield Silent to execute a silent setup.

-SMS

Prevents a network connection and Setup.exe from closing before the setup is complete. This switch works with setups originating from a Windows NT server over a network. Please note that SMS must be uppercase; this is a case-sensitive switch.

-z

Prevents Setup.exe from checking the available memory during initialization. This switch is necessary when running a setup on a machine with more than 256 MB of memory; if it is not used, Setup.exe reports insufficient memory and exits.

-uninst

Runs the setup as an uninstallation without reading the script.

-verbose

Provides more detailed information when a Setup.exe error occurs.

Please note the following:

Setup.exe command line parameters are not case sensitive; upper case or lower case letters can be used.

Separate multiple command line switches with a space, but do not put a space inside a command line switch (for example, /r /fInstall.ins is valid, but not /r/f Install.ins).

When using long path and filename expressions with switches, enclose the expressions in double quotation marks. The enclosing double quotes tell the operating system that spaces within the quotation marks are not to be treated as command line delimiters.

View comments (9)

InstallShield Error Codes (Setup.log)

Setup.log is the default name for the silent installation log file and its default location is the same folder where Setup.ins is located. You can specify a different name and location for Setup.log using the -f2 switch with Setup.exe.

The Setup.log file has 3 sections:

[InstallShield Silent]

Identifies the version of InstallShield Silent used in the silent installation. It also identifies the file as a log file.

[Application]

Identifies the installed application's name and version, and the company name.

[ResponseResult]

Contains the result code indicating whether or not the silent installation succeeded. An integer value is assigned to the ResultCode keyname in the [ResponseResult] section. InstallShield places one of the following return values after the ResultCode keyname:

0 Success

-1 General error

-2 Invalid mode

-3 Required data not found in the Setup.iss file

-4 Not enough memory available

-5 File does not exist

-6 Cannot write to the response file

-7 Unable to write to the log file

-8 Invalid path to the InstallShield Silent response file

-9 Not a valid list type (string or number)

-10 Data type is invalid

-11 Unknown error during setup

-12 Dialogs are out of order

-51 Cannot create the specified folder

-52 Cannot access the specified file or folder

-53 Invalid option selected

For a successful installation, the log file should look similar to the example below:

[InstallShield Silent]

Version=v5.00.000

File=Log File

[Application]

Name=KiXscripts Editor

Version=1.10.000

Company=RWK Systems, Inc.

[ResponseResult]

ResultCode=0

View comments (2)

K1 Asset Managed Software Deployments at Image Time

Hey All,

Just thought I'd start showing some things through the blog which we use here at my workplace. I've already showed how we rename machines based on the K1 assets HERE which Dave polished and provided some very good updates for. So I thought I might show how we do some modular asset managed software installs.

Labelling and K2 scripting would probably work quite well in most organisations, but here we wanted to be able to see EVERYTHING from the asset's page and due to a 1600 odd mobile fleet, some larger packages needed to go on over the wire at image very quickly. So, we created an asset field for it.

In our soe/deployment script we then just do some basic vb scripting to check if the machine asset field contains a particular string. This way we can use the same wds or k2 image for multiple machines without having to worry about changing anything on them.

We also perform our driver installations and active directory OU movements and group memberships this way depending on how they are asseted. Makes things very asset central and gives us a definitave be-it-end-all solution for managing all manner of asset related things.

Smart labels are also created based upon the assets which have these selected so we can quickly view and update many at once.

If anyone would like any scripting or further in depth how-to's on this let me know!

Cheers,

Col

Be the first to comment
Showing 1 - 5 of 393 results

Top Contributors

Talk About ITNinja