Programming4us
         
 
 
Windows Server

Windows Server 2008 Server Core : Installing Applications with the MSIExec Utility

8/16/2011 3:42:21 PM
The Microsoft Installer Executive (MSIExec) utility helps you install applications on a system. The application setup package must appear in a form that MSIExec can understand, which is normally a file with a Microsoft Installer (MSI) extension, although you'll see these files with an EXE extension as well. Generally, the MSI packages are robust enough that you can install them unattended after you test the application setup on a test machine. In fact, if you have many machines to set up, using this approach, coupled with automation, can save you considerable time. Unattended installations of tested application setups are an excellent choice for after hours scripting. This utility uses the following syntax:
msiexec /Option <Required Parameter> [Optional Parameter]

You can categorize the command line switches for MSIExec into several functional areas. Each area performs a specific Microsoft Installer task. The following list describes each of the command line installation options.


{/package | /i}
{Product.MSI | ProductGUID}

Installs or configures the specified application. You can specify the application as an MSI package or as a GUID. When you use the GUID form, MSIExec looks for the application information in the registry and performs a configuration, rather than an installation. This installation option relies on the credentials of the current user.


/a
Product.MSI

Performs an administrative installation. An administrative installation unpacks all of the files into a directory, normally on the network, and creates a smaller MSI file. Clients can then perform a local installation by accessing this directory on the network. Normally, you'll use this command line switch to create a centralized location from which to perform an installation for a number of machines. You'll specify the installation location using the TARGETDIR parameter.


/j{u | m}
Product.MSI
[{/t
TransformList
| /g
LanguageID]

Advertises an application on a network. Use the /ju command line switch to advertise to the current user. The /jm command line switch advertises the application to all users on the network. Use the /jm command line switch when you need to install a package using elevated rights (privileges). The /t command line switch specifies a transform list used to advertise the product. A transform is a method of customizing the MSI database to meet specific needs. It's a property that you can specify at the command line using the TRANSFORMS parameter. For example, TRANSFORMS= ":1033" might select a file of advertising information in United States English based on a Locale Identifier (LCID) of 1033.You can also supply transforms as part of a Microsoft Transform (MST) file. The /g command line switch lets you specify a language identifier directly. The language is normally an LCID. You can find a list of common LCIDs at http://krafft.com/scripts/deluxe-calendar/lcid_chart.htm.


{/uninstall | /x}
{Product.MSI | ProductCode}

Uninstalls a previously installed application. You can uninstall the product based either on the original installation package or on the product's GUID.

In addition to installation options, the MSIExec utility supports a number of display options. The following list describes each of these options.


/quiet

Installs the product without any user interaction. The product installs using the default arguments. However, you can override the arguments using parameters when the developer sets up the installation program correctly. For example, you can select an installation type, such as custom or typical, using the INSTALLLEVEL parameter. Make sure you check the product documentation for any custom parameters that the developer might create to address specific installation needs.


/passive

Performs an unattended installation. The setup program won't ask the user any questions, but the user still sees a progress bar. The progress bar gives the user some idea of how far the setup has progressed and indicates continued activity. An activity indicator is essential when the user knows about the installation. Otherwise, users may overwhelm your help desk with questions about why the application setup didn't complete (even though it would have if they'd simply given it time to complete).


/q[{n | b | r | f}]

Defines the user interface level. The interface level determines what the user sees during the application installation. Each of these levels has a specific meaning as described in the following list.


n

Conceals the user interface (no user interface).


b

Displays a basic user interface. Normally, this includes only the features required to install the application.


r

Displays a reduced user interface. The package developer defines the user interface setup, which is somewhere between the basic and the full display in complexity.


f

Displays the full user interface.

Once the installation has completed, you need to consider whether to restart the machine. The only time you need to restart the machine is when you need to replace a DLL or other system component that is in use. Here's the list of restart options.


/norestart

Performs the installation without a restart.


/promptrestart

Prompts the user for a restart when necessary.


/forcerestart

Forces the system to restart after the installation is complete.

An after hours installation might not go as planned. Consequently, you'll want to log any installation events so you can review the installation process later. It's important that you review the log even when it appears the installation occurred as predicted. A small error might not stop the installation from completing, but could stop the application from working as intended. The following list defines the command line switches for logging an installation.


/l[I] [w] [e] [a] [r] [u] [c] [m] [o] [p] [v] [x] [+] [!] [*]
LogFile

Performs only the specified level of logging. You can combine multiple logging levels to obtain specific logging results. For example, using the /lia command line switch records all status messages and startup actions. The following list identifies the various logging levels that you can use.


i

Status messages


w

Nonfatal warnings


e

All error messages


a

Startup of actions


r

Action-specific records


u

User requests


c

Initial user interface parameters


m

Out-of-memory or fatal exit information


o

Out-of-disk-space messages


p

Terminal properties


v

Verbose output (you can only use this command line switch when you specify that you want all output by using the \l*v command line switch)


x

Extra debugging information


+

Append to existing log file


!

Flush each line to the log


*

Log all information, except for v and x options


/log
LogFile

Performs a level of logging equivalent to the /l* command line switch.

The MSIExec utility can do more than simply install or remove applications. You can also use it to perform an update of the application. The following command line switches tell about the update options.


/update
Update1.MSP[;Update2.MSP]

Performs an update based on the content of one or more Microsoft Patch (MSP) files. Separate the individual MSP entries with a semicolon (;).

NOTE

Some versions of MSIExec support a /p command line switch file updates where you supply the update package as the input argument. This form doesn't support multiple update packages and it doesn't provide a means of removing the patch. Use the /update command line switch if your version of MSIExec supports it. (The utility displays an error message when you attempt to use the /update command line switch with a version that doesn't support it.) The best way to determine the MSIExec version number isn't to use the MSIExec /? command. Check the MSI.DLL version number instead. When Microsoft performs an update, it usually updates MSI.DLL instead of MSIExec.EXE.


/uninstall
PatchCodeGuid[;Update2.MSP]
/package
{Product.MSI | ProductCode}

Removes an update based on the patch's GUID. You can remove additional, supplementary updates by supplying the MSP file.

If you've ever had an application act oddly and found that some small change in the system caused the error, you've wanted a repair option. Interestingly enough, the MSIExec option allows this action, even in cases where the product's installation interface doesn't supply the required functionality. Because it's easier to repair an application than to reinstall and configure it, you might try this option with any application that performs strangely. The following list describes the command line switch for repairing a faulty installation.


/f[p] [e] [c] [m] [s] [o] [d] [a] [u] [v]
{Product.MSI | ProductCode}

Repairs the product based on the original installation file or the product code. Use the original installation file for greater reliability in fixing an application. The following list describes the levels of repair that you can perform. You can combine multiple repair levels to achieve specific effects.


p

Replaces a file only when the file is missing.


o

Replaces a file when the setup program detects the file is missing or it finds another application has installed an older version of the file. This is the default action.


e

Replaces a file when the setup program detects the file is missing or it finds another application has installed an equal or older version of the file.


d

Replaces a file when the setup program detects the file is missing or it finds another application has installed a different version. This action replaces the file even when the file is newer than the one used by the application.


c

Replaces a file when the setup program detects the file is missing or the file's checksum does not match the calculated value. This option often helps you locate and replace files tainted by viruses.


a

Forces the setup program to reinstall all files.


u

Updates all required user-specific registry entries.


m

Updates all required computer-specific registry entries.


s

Updates all existing shortcuts.


v

Runs the setup program from a source media and caches the local package to the hard drive. This command line switch replaces the local package when it already exists.

You may have noticed more than a few references to properties in this section. Adding properties to the command line changes the way in which the MSI package unpacks. The properties that are available depend in part on the person who crafted the package, in part on the version of the Microsoft Installer used to create the package, and in part on your own personal requirements. The Windows Installer Property Reference at http://helpnet.installshield.com/robo/projects/helplibdevstudio9/IHelpPropReference.htm provides one of the most complete listings of properties you can use with Microsoft Installer. Of all these parameters, you'll use the special folder parameters, such as TARGETDIR, most often. To use a parameter at the command line, simply include the parameter name, followed by an equals sign (=), followed by the parameter value, such as TARGETDIR="C:\Program Files\My Application". Always enclose parameters with spaces in quotes.
Other -----------------
- Windows Server 2008 Server Core : Getting System Configuration Information with the SystemInfo Utility
- Setting Up Your Windows Home Server 2011 Network : Troubleshooting Network Problems (part 2)
- Setting Up Your Windows Home Server 2011 Network : Troubleshooting Network Problems (part 1)
- Windows Server 2008 : Working with Event Subscriptions - Managing Subscriptions with wecutil & Logging Events with eventcreate
- Windows Server 2003 : Managing Security Configuration with Security Templates (part 2)
- Windows Server 2003 : Managing Security Configuration with Security Templates (part 1)
- Setting Up Your Windows Home Server 2011 Network : Configuring Windows Home Server for Networking
- Introducing Windows Small Business Server 2011: Why Use Windows SBS 2011?
- Introducing Windows Small Business Server 2011: What is Included with Windows SBS 2011?
- Windows Server 2003 Security Configuration (part 2) - Creating Role-Specific Server Configurations
- Windows Server 2003 Security Configuration (part 1) - Windows Server 2003 Security Settings
- Windows Server 2008 Server Core : Accessing the WinPE Network Installer with the NetCfg Utility
- Windows Server 2008 Server Core : Managing the Boot Configuration with the BCDEdit Command
- Windows Server 2008 : Enabling and Testing Event Subscriptions
- Windows Server 2008 : Adding an Account to the Event Log Readers Group
- Windows Server 2008 : Enabling the Source Computer with winrm & Enabling the Collector Computer with wecutil
- Windows Server 2008 : Using Virtualization to Increase Productivity and Facilitate Consolidation
- Windows Server 2008 : Using Virtualization to Increase Productivity and Facilitate Consolidation - Installing Hyper-V
- Windows Server 2008 : Using Virtualization to Increase Productivity and Facilitate Consolidation - Introducing Virtualization & Server Consolidation
- Windows Server 2003 : Configuring IAS for Use with VLANs
 
 
Most View
- CSS for Mobile Browsers : Common Patterns (part 2) - Rounded corners
- Windows Vista : Custom Startups with the Advanced Options Menu & Useful Windows Vista Logon Strategies
- SQL Server 2008 R2 : Client Installation
- Exchange Server 2010 : Availability Planning for Mailbox Servers (part 8) - Designing and Configuring DAGs
- Windows Phone 7 : Forwarding Calls
- Windows Phone 7 : Working with SharePoint Documents
- User Interface : Detecting Changes in the Theme Template
- Windows 7 : Customizing Your Notebook’s Power and Sleep Buttons
- Windows Phone 7 : Saving Pictures to the Web
- Windows Server 2008: Performance and Reliability Monitoring (part 3) - Reports
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS