Tips, tricks, techniques, tools, and code for those who administer Windows desktops.

Free Repackaging Tool: CapaSystems ezMSI 3.6

Apr8th
2013 Written by mike

There are a number of application repackaging tools on the market. You may have worked with one of them, such as Flexera AdminStudio, the now-defunct Symantec Wise Package Studio, or any of a number of others. All of them have strengths and weaknesses, and nearly all of them cost money. CapaSystems is a Scandinavian software development house which also provides consulting services. Their software product line includes CapaInstaller, a suite of asset management, configuration management, and other tools.  In this post, we’ll be looking at their free application repackaging tool called ezMSI.

ezMSI, according to their web site, is a "free tool available for anyone on the planet earth".  The software is supported for their CapaInstaller Management Tool customers, but is free and unsupported for everyone else.

CapaSystems ezMSI has been tested (by CapaSystems) on Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Windows 7. I was able to run it successfully on Windows XP, but had issues with it on 64-bit Windows 7.  I suspect that it isn’t tested or intended for 64-bit Windows versions, but that is only a guess.

Installing ezMSI

ezMSI downloads as a zip file, which unpacks into a directory containing four files. Two of these are MSIs, one is an INI, and the last is a batch file:

image

The batch file (install.bat) begins the installation process.

image

Once launched, it starts the installation wizard for ezMSI.

image

Clicking the Next button brings up the license agreement screen.

image

Clicking "I accept the terms in the license agreement" button and clicking Next again provides the option to change where the software is installed.

image

Clicking Next again provides a final confirmation of installation.

image

Installation takes place in a few seconds (depending of course on your system load and configuration).

image

The installer ends with a completion message:

image

At this point the batch script runs the second MSI silently and copies the INI file into the installation directory.  ezMSI is ready to use at this point.

Using ezMSI to Repackage Software

You begin by launching the application from the Start Menu shortcut.

image

This interface is slightly confusing.  For a typical repackaging task, where you’re capturing a legacy installer into an MSI, select "Create new MSI package".  Then, fill in the file name, version, and product name.  For example, to repackage Mozilla Firefox 17.0, I would begin with the following settings:

image

Clicking Next, ezMSI offers the opportunity to exclude files and directories from the snapshot process:

image

In this case, I choose to eliminate the patch directory and the D: drive.

image

I’m then offered the opportunity to exclude certain registry keys:

image

I click Next and ezMSI is ready to begin taking its "before" snapshot of the system.

image

Clicking next begins the snapshot process.

image

Once the initial snapshot has been taken, ezMSI prompts for the installer to be captured.

image

I select the Mozilla Firefox 17.0 installer and click Next.  The Firefox installer is launched.

image

I click through the rest of this installation wizard to install Firefox.  This leaves me back at the ezMSI window:

image

Clicking next, ezMSI lets us know that installation is complete and that it is ready to begin the final snapshot process.

image

Clicking Next begins the final snapshot process.

image

When the snapshot is complete, ezMSI offers the option to edit the capture:

image

Clicking Yes opens the registry editing dialog:

image

Any desired changes can be made here. Clicking Next displays the INI editor.

image

Clicking Next again displays the File editor:

image

I find that it has captured some temporary Windows files, so I remove those from the capture and click Next.  I’m given the option to add or remove shortcuts.

image

Clicking Next gives me some final options before the MSI is created.

image

Clicking Next begins MSI capture and creation.

image

Clicking Next offers the opportunity to open the directory where the MSI was created:

image

ezMSI has in fact created an MSI for Mozilla Firefox 17.0:

image

Changing Capture Settings

The list of files, folders, and registry keys excluded from capture can be found in the CISetup.ini file located in the ezMSI installation path.  By default, that path is:

C:\Program Files\CapaInstaller\ezMSI

You can edit this INI file in Notepad or another editor.  This allows you to exclude additional registry keys, drives, directory trees, or files from captures.

image

If you edit the file, be sure to create a new snapshot of your packaging VM so that the changes become part of your "clean" capture configuration.

Conclusion

As repackaging tools go, this one is pretty bare-bones.  However, apart from the initial window, it’s very straightforward to use and seems to do a good job.

It’s not a complete solution to your repackaging needs, since it lacks an MSI editor, MST creation, and other features you might want.  However, if you’re on a limited budget and can live with its lack of 64-bit Windows support, it’s definitely a usable option.

To get ezMSI, visit the download page on the CapaSystems web site.

Software Packaging    , , , , ,

How to Fix iPod Touch Update Errors

Jan29th
2013 Written by mike

While updating my fourth-generation iPod Touch to iOS 6.1, I encountered a problem. The iTunes software generated an error that prevented the update from happening. The iPod was left in the “Connect to iTunes” mode.

I tried restarting the PC and reconnecting the iPod, but iTunes still did not recognize it.  After a number of false starts, I finally managed to get it updated and restored.

The following instructions are based on those found in multiple pages on Apple’s web site:

· Disconnect the iPod Touch’s USB cable.

· Hold down the home button and the power button until either the “power off” slider appears or the iPod turns itself off.

· Hold down the home button while plugging the USB cable back into the iPod. It should now power back on and go into the same “Connect to iTunes” display.
clip_image002[1]

· Several seconds later, iTunes will indicate that it sees the device:
clip_image003

· Click OK.

· Back in iTunes you’ll see a button labeled “Restore iPod”.
clip_image004
(Your iTunes window might look a little different from this, or contain a different date. That is OK.)

· Click the “Restore iPod..” button.

· iTunes will begin attempting to update the iPod to the current iOS version and restore the backup to it. If you’re lucky, this will be the end of it and your iPod will be back to normal. If so, stop here. If your iPod still didn’t restore, continue to the next step.  (In my case, I got an "unknown error" code.)

· Verify that your iTunes software is the most current version. On Windows, launch the Apple Software Update software to see if an update is available. If so, install it. On Mac OS X, use Software Update.  (This was not the issue I had.)

· On Windows, make sure you have the latest Windows Updates installed. Use the Windows Update control panel or the Windows Update web site.  (This also was not my issue.)

· Disconnect all the USB devices from the computer except for the keyboard, mouse, and iPod. Try Restoring the iPod again. If this works, reconnect all the devices.  (This allowed the process to get further on my system, but it still received an error code 9.)

· Temporarily disable your antivirus software and try restoring the iPod again. Some antivirus software can conflict with iTunes updating the iPod.  (Did not help in my case.)

· Temporarily disable your firewall software and try the update again. Firewall software can in some cases prevent the update. (Did not help in my case.)

· If you’re getting an error message during synchronization, look up that error number here: http://support.apple.com/kb/TS3694
The above page provides detailed descriptions and troubleshooting steps for many different error numbers reported by iTunes.

My answer turned out to be a variation on the last bullet above.  The third-party cable I was using to do the synchronization was apparently dropping its connection to the PC every so often causing the update and restore to fail.  Swapping the USB cable out with an Apple-manufactured one solved my issue (probably in combination with disconnecting all non-essential USB devices).

References

The following pages provided information used to produce this article.

· Stuck on screen with USB under arrow pointing to iTunes logo:
https://discussions.apple.com/thread/4353898?start=0&tstart=0

· iOS: Unable to update or restore:
http://support.apple.com/kb/HT1808

· iOS: Device not recognized in iTunes for Windows:
http://support.apple.com/kb/TS1538

· iOS: Resolving update and restore alert messages:
http://support.apple.com/kb/TS1275

· iTunes: Specific update-and-restore error messages and advanced troubleshooting:
http://support.apple.com/kb/TS3694

· The iPod could not be restored. An unknown error occurred(9).
https://discussions.apple.com/thread/1175936?start=0&tstart=0

Troubleshooting    , , , ,

How to Install Applications Silently

Jan11th
2013 Written by mike

What is Silent Installation?

Application Repackagers often receive installers that are delivered by the vendor as an executable program, typically with a name like “Setup.exe”.  These installers can be clicked through manually by an administrator to install the software.  However, busy administrators don’t have time to spend running around to machines and clicking through installers.  They’re looking for ways to automate the installation and avoid the need for all the tedious clicking. 

Generally speaking, application installations can be classified as follows:

  • Normal, Manual, or "loud":  These installations require a human being to click through various wizard-based pages, one at a time, entering information like server names and serial numbers.  For these installations, interaction with a user is necessary.
  • Passive or Automated:  In these cases, the installation doesn’t require human intervention.  Server names, installation choices, serial numbers, etc., are all provided through the command line, a configuration file like an INI or XML file, a response file, or through a transform (MST) in the case of an MSI installer.  In these cases, the installer is usually visible on-screen to the user but it doesn’t require any interaction or input (and typically cannot be interrupted by the user).
  • Silent or Quiet:  In this case, the installation requires no interaction on the part of the user and also displays no messages or progress information on-screen.  Apart from seeing their hard disk activity indicator blinking, or noticing a slight drop in system performance, users will not normally know these installations are happening until the software shows up as an icon on the desktop or in the Windows Start Menu.

While some application vendors do not support any form of passive or silent installation, most vendors (especially those selling software to corporations for general use) do provide the option. The problem is that there are many different installer technologies out there, and there is no consistency in how these handle silent installations. This article attempts to provide a framework for identifying available passive and silent installation options and suggests how to locate any available information for the application in question.

Quick Reference

Following is a quick reference to the techniques discussed here:

  • Analyze any documentation or manuals available from the vendor. Silent installation instructions are often documented there.
  • Check the Internet via a search engine, to see if someone else has already documented how to automate the installation of the application.
  • Ask the installer itself, using a “/?”, “-?”, or “/help” switch at the command line.
  • Look at the installer icon to see if it resembles any common installer technologies. Approach it using the command lines associated with that technology.
  • Examine any INI or config files shipped with the installer for silent options
  • Use the Sysinternals Strings tool to see if any of the text in the file gives an indication as to the technology used to create the installer.
  • Use Procmon to analyze what the installer is doing, to see if it’s extracting an MSI or another executable that you can use for silent installation.
  • Open the executable with 7-zip to see if it contains another installer or an MSI that can be used instead.
  • Try common silent install switches with the executable and see if the work.

If there is a way to silently install the application, this combination of actions will usually find it, unless it’s a very obscure application from a vendor who uses a very unusual method of silent installation.  Let’s look at these activities in more detail.

Continue reading “How to Install Applications Silently” »

Software Packaging    , , ,

InstallShield for Administrators–Part 9

Dec11th
2012 Written by mike

In Part 1 of this series, we discussed the challenges an InstallShield based installer presents administrators. In Part 2, we described ways to identify that a given installer is based on the InstallShield technology. In Part 3, we discussed how to determine what is going on inside the installer, to help you figure out how to construct a command line to run it silently. In Part 4, we talked about the recording and playback option. In Part 5, we looked at executables with embedded executables. In Part 6, we looked at executables that contain embedded MSI installers and how to silently install those. In Part 7, we looked at the “Extreme Cases” where the creator of the InstallShield based installer did something complex that requires a very unusual command line to install silently. In Part 8, we looked at how it is sometimes possible to extract an embedded MSI installer from an InstallShield installer and use that to perform a silent install. Part 9 is a quick reference for InstallShield installers and a list of online sites where you can learn more.

InstallShield Quick Reference

Process Explorer Example Most Likely Situation
clip_image002 Standalone executable with no embedded installers. Use a response file or a simple “/s”.
clip_image004 Executable with embedded MSI
clip_image006 Executable with embedded executable
clip_image008 Executable with embedded executable that installs an embedded MSI.
Situation Command Line Switch To Use
Create a response file for EXE installer /r /f1”<path-to-response-file>”
Use response file for silent install /s /f1”<path-to-response-file>”
(may also need:) /f2”<path-to-log-file>”
Silent install of embedded MSI /s /v/qn /norestart
(everything after /v is passed to MSIEXEC)
Silent install of embedded EXE /s /a /s
(everything after /a is passed to the inner executable)
Silent install of embedded EXE with embedded MSI /s /a /s /v/qn /norestart
Silent install of EXE w/o response file /s

InstallShield References Online

Following are some InstallShield references on the Internet which may be helpful when packaging and deploying an InstallShield based application:

Software Packaging    , , , , , ,

InstallShield for Administrators–Part 8

Dec10th
2012 Written by mike

In Part 1 of this series, we discussed the challenges an InstallShield based installer presents administrators. In Part 2, we described ways to identify that a given installer is based on the InstallShield technology. In Part 3, we discussed how to determine what is going on inside the installer, to help you figure out how to construct a command line to run it silently. In Part 4, we talked about the recording and playback option. In Part 5, we looked at executables with embedded executables. In Part 6, we looked at executables that contain embedded MSI installers and how to silently install those. In Part 7, we looked at the “Extreme Cases” where the creator of the InstallShield based installer did something complex that requires a very unusual command line to install silently. In Part 8, we look at how it is sometimes possible to extract an embedded MSI installer from an InstallShield installer and use that to perform a silent install.

Unwrapping and Using Embedded MSIs

For those installers with embedded MSIs, it is possible (in some cases) to use these without the wrapper executables. Launch the wrapper executable and click through it to the point that Process Explorer shows the MSIEXEC process running:

clip_image002

Right-click the MSIEXEC process and choose Properties. Look for the path to the MSI file being installed. Navigate to this path in Windows Explorer. The extracted MSI and other files will likely be found there:

clip_image004

Copy these files to a “safe” location that will survive the reboot or reimage of the packaging machine, such as a server share or second disk on the packaging machine.

Exit the installer that is running and reset the packaging machine to a clean condition.

If in the extracted directory containing the MSI there is another MSI file with a name that starts with “ISScript” (or something similar), there is a good chance that the main MSI makes use of the InstallShield Scripting engine and drivers. For the initial test of the extracted installer, start by installing this InstallShield Script engine MSI. (Later, you can test the MSI without it to see if it’s really needed. At this point, you want to determine if the extracted MSI is complete and usable as-is.)

clip_image006

With any InstallShield Script engine installed, launch the MSI file. In some cases, it will launch immediately and allow the installation to continue. In others, the following error (or something very similar) will be displayed:

clip_image008

If this error occurs, open the MSI file in an MSI editor such as Orca or Wise Package Studio. Go to the Property table, and add the property “ISSETUPDRIVEN” and supply the value of “1” (the numeral one):

clip_image009

Attempt to run the MSI again. It should not display the error this time.

Note that if there are more MSIs than just the ISScript MSI and the application’s MSI, it may be necessary to install all of the MSIs for the application to work. It may even be necessary to install the MSIs in a particular order. You can discover the order by trial and error, or by using Process Monitor to record the original installer at work. Scanning through the Process Monitor log, it will be possible to see in which order the MSI files are being installed. Replicate this same order of operations in the deployment process for the application and it should work.

Unfortunately, this is another situation where the flexibility and power of InstallShield can work against administrators who are trying to install an application silently or passively.

There are installer developers who incorporate some of the installation logic outside the MSI, so the extracted MSI will deliver an incomplete application.

Other installer developers may extract a completely empty MSI and populate it at runtime with the elements needed to install the application on a particular machine. The extracted MSI will therefore do little or nothing.

In some of these extreme cases, it may be necessary to perform a capture of the application installed and construct a repackaged MSI. Be aware, however, that a repackaged installer may not contain all of the necessary prerequisites or features to enable the application to function properly on all Windows operating system versions and configurations. Testing the application on all relevant configurations in the organization is recommended, though not always practical.

Earlier, it was mentioned that the InstallShield Script Engine might not always be required by the installers which extract it. The easiest way to determine if the engine is needed is to reset the packaging machine to a clean condition. Then, launch the MSI file and see if it can be installed. If the InstallShield Script Engine is needed, a message similar to the following will be displayed:

clip_image011

If this error appears, then it is necessary to include the Script Engine in the deployment.

Note:  There are some InstallShield installers which are dependent upon the executable that extracts them.  You may find that, for a given installer, extracting the MSI will not result in a working install or a usable application.  In those cases, you’ll need to do what you can to silently install the application using the executable rather than the MSI.

This series will be concluded tomorrow night with a quick reference document for silent installation of InstallShield installers and a list of online references for InstallShield.

Software Packaging    , , , , , , , ,

InstallShield for Administrators–Part 7

Dec9th
2012 Written by mike

In Part 1 of this series, we discussed the challenges an InstallShield based installer presents administrators. In Part 2, we described ways to identify that a given installer is based on the InstallShield technology. In Part 3, we discussed how to determine what is going on inside the installer, to help you figure out how to construct a command line to run it silently. In Part 4, we talked about the recording and playback option. In Part 5, we looked at executables with embedded executables. In Part 6, we looked at executables that contain embedded MSI installers and how to silently install those.  In Part 7, we’ll be looking at the “Extreme Cases” where the creator of the InstallShield based installer did something complex that requires a very unusual command line to install silently.

More-Extreme Cases

Note that it is possible for installer creators to have a Setup.exe wrapped around another Setup.exe, wrapped around an MSI. Once the order of execution is visible within Process Explorer, it is possible to “mix and match” the command line syntax to build a command that works. For example, for a Setup.exe wrapped around a Setup.exe that contains an embedded MSI that should all be run silently, the syntax looks something like this:

Setup.exe /s /a /s /v/qn /norestart

In the above example, the outer Setup.exe gets the “/s” to run silently. It recognizes the “/a” as an indicator to pass the rest of the command line on to the embedded Setup.exe. That executable reads the “/s” and runs silently also. It sees the “/v” as an indicator to pass the rest of that command line on to MSIEXEC, which recognizes the “/qn” switch as an indicator to run silently and the “/norestart” as an indicator to avoid rebooting the machine.

Because there are a number of ways installer creators can mix and match the InstallShield options, cases may be encountered that are not explicitly described here. In these cases, use Process Explorer to determine what the installer is doing, and construct a command line designed to fit with that particular scenario.

It’s possible that a situation might be encountered that cannot be reliably dealt with in a single command line, or perhaps it is taking an undesirably long time for the extraction process to extract each embedded component.


Simplifying Extreme Cases of Embedded Installers

It’s possible to remove wrappers from InstallShield installers and strip them down to a much simpler case. For example, it is possible to launch a Setup.exe and run it to the point that it extracts the inner Setup.exe (or MSI). Once this extraction has occurred, the Process Explorer tool will show that the inner Setup.exe is running. Right-clicking this Setup.exe item in Process Explorer and choosing Properties will provide the path to the inner executable:

clip_image002

While the installer is still running, navigate to this path in Windows Explorer and the extracted installer should be visible as one or more files in that folder:

image

Copy all of these files to a “safe” location that will survive the packaging machine being rebooted or reimaged/reset.

Terminate the running installer by canceling out of it. (When the running installer ends, it typically deletes the extracted inner installer. This is why it’s necessary to copy the extracted installer to a “safe” location, such as a server share or second disk on the packaging machine, while it is still running.)

Exit the installer that is running and reset the packaging machine to a clean condition.

Run the extracted installer manually to ensure that it contains all the necessary components. Test the installed application to ensure that it works properly. If so, the original installer can be ignored or discarded and the extracted installer used instead.

Treat this new installer as though THAT was what the vendor shipped you and you will simplify the installation and the command line needed.

In Part 8, we will look at embedded MSI installers and how those can sometimes be extracted and used for silent deployment.

Software Packaging    ,

InstallShield for Administrators–Part 6

Dec8th
2012 Written by mike

In Part 1 of this series, we discussed the challenges an InstallShield based installer presents administrators. In Part 2, we described ways to identify that a given installer is based on the InstallShield technology. In Part 3, we discussed how to determine what is going on inside the installer, to help you figure out how to construct a command line to run it silently. In Part 4, we talked about the recording and playback option. In Part 5, we looked at executables with embedded executables.  In Part 6, we look at executables that contain embedded MSI installers and how to silently install those.

Executable with Embedded MSI

It is very common for InstallShield installers to launch as an executable and then extract an MSI which does the heavy lifting. In these cases, Process Explorer will show the MSIEXEC.EXE process running underneath the Setup.exe. The InstallShield command line syntax makes it possible to pass parameters on to the underlying MSI if needed. This is done through the “/v” switch. The “/v” switch is similar in function to the “/a” switch used with installers that have embedded executables. For example:

Setup.exe /s /v/qn /norestart

This command line tells the outer Setup.exe program that it is to run silently. The “/v” instructs it to pass the rest of the command line on to MSIEXEC when it runs the embedded MSI. The “/qn” is an MSIEXEC switch to run silently. The “/norestart” switch tells MSIEXEC not to reboot the machine, even if the installer wants to reboot.

In addition to passing the “/qn” switches on to the MSI, it is also possible to pass long parameter values and even transform files if they are available. Think of the “/v” as saying “add everything after me to the MSIEXEC command line”. For example, to specify ALLUSERS=1 to the MSI in the above example, use:

Setup.exe /s /v/qn /norestart ALLUSERS=1

Any of the valid MSIEXEC switches can be specified after the “/v”. Some commonly used MSIEXEC switches include:

Switch Meaning
/qn Install silently with no progress indicators
/qb Install with a progress indicator but no user interaction
/norestart Do not reboot, even if the installer wants to.
/update “patch.msp” Apply the patch.msp patch during installation
/log “install.log” Log details about the installation to “install.log”.

For more information on the available switches, launch a command prompt and enter “MSIEXEC /?” to view the detailed help for MSIEXEC.

In Part 7, we will look at the “Extreme”  cases of InstallShield installers.  These are situations where the person who created the installer decided to do build a Setup.exe that calls another Setup.exe which in turn runs an MSI.  These installers can often be silently run as well, but the command lines can be a bit strange looking.

Software Packaging    , , , , , ,

InstallShield for Administrators-Part 5

Dec7th
2012 Written by mike

In Part 1 of this series, we discussed the challenges an InstallShield based installer presents administrators. In Part 2, we described ways to identify that a given installer is based on the InstallShield technology. In Part 3, we discussed how to determine what is going on inside the installer, to help you figure out how to construct a command line to run it silently. In Part 4, we talked about the recording and playback option.  In Part 5, we look at executables with embedded executables.

Executable with Embedded Executable

While watching the action in Process Explorer, it may become apparent that there is an outer or “wrapper” executable running an inner Setup.exe. To run the combined installer silently, it is necessary to pass a silent install switch (“/s”) to both the wrapper and the inner executables. This is done by supplying the wrapper executable with a “/a” or “-a” switch, which indicates that everything else in the command line applies to the inner executable. For example:

Setup.exe /s /a /s

This command line tells the outer “Setup.exe” program that it should be silent, and that it should pass along (the “/a”) to the inner executable a “/s” to run silently.

It is possible that the inner executable is of the “Recording and Playback” variety. In this case, there are two steps required to run it silently. First, the manual install should be recorded. This requires the command line:

Setup.exe /s /a /r /f1”<path-1>

In the above, “” should be replaced with the path to the response file to be generated.

When this command is executed, the outer Setup.exe will be silent, and will begin recording a response file at the “” location. The administrator will need to click through the installation wizard, selecting the necessary options along the way. When the wizard is finished, there should be a recording file.

To use this recording file for a future silent installation, the syntax looks like this:

Setup.exe /s /a /s /f1”<path-1>” /f2”<path-2>”

In the above example, the first “/s” silences the outer executable. The “/a” passes the rest of the command line on to the inner executable. That executable receives the “/s” switch to be silent, and uses the response file in “” to perform the install. It also writes a log file at “”.

Note that some installers will fail without the “/f2” switch, because they try to write the log in the same path as the original Setup.exe, which may not be writable by the person running the installer. And some installers may not behave properly if writing a log file, so it may be necessary to eliminate the “/f2” switch and path.

In Part 6, we will look at how to deal with an InstallShield executable that contains an embedded MSI installer.

Software Packaging    , , , , , , , ,

InstallShield for Administrators–Part 4

Dec6th
2012 Written by mike

In Part 1 of this series, we discussed the challenges an InstallShield based installer presents administrators. In Part 2, we described ways to identify that a given installer is based on the InstallShield technology. In Part 3, we discussed how to determine what is going on inside the installer, to help you figure out how to construct a command line to run it silently.  In this part, we will discuss how to use the “recording and playback” method to perform a silent installation with an InstallShield installer.

InstallShield Recording and Playback Method

If you discovered during the Deconstruction phase that the InstallShield installer does not call any other executable or MSI, there is a good chance that the installer will support the Recording and Playback method for silent installation.This is a two-step process.

NOTE:  For consistency, I will describe all the command line switches as starting with a slash (“/”).  However, some versions of InstallShield do not respond to switches that begin with a slash, but instead expect the switches to begin with a dash or minus sign (e.g., “-r” rather than “/r”).  If one form doesn’t work with the installer you’re packaging, try the other before assuming that recording and playback aren’t supported.

First, launch an administrator command prompt. Use this to launch the installer with the “/r” (or “-r”) switch, followed by the “/f1” (or “-f1”) switch. This tells the installer that you want to “record” the installation process and store the results in the file whose path you specify in the “f1” switch.

For instance, to launch a Setup.exe located in your C:\Temp directory, and to create a “response file” in that same directory called “install.iss”, use the command:

C:\Temp\Setup.exe /r /f1”C:\Temp\install.iss”

When this command is executed, the installer will launch normally, as through you double-clicked it in Windows Explorer. Click through the installer wizard, selecting all the options for the application which are required. When the wizard ends, a response file will be created in the path specified.  (If no such file is created, this installer does not support the recording and playback method.)

To perform a silent install using this response file, use the “/s” (for “silent”) switch, followed by the “/f1” switch to specify the exact location of the response file. (Most InstallShield installers require the full, explicit path to the response file, even if it is located in the same directory as the Setup.exe.) The finished command looks something like this:

C:\Temp\Setup.exe /s /f1”C:\Temp\install.iss”

Some installers, or perhaps some InstallShield versions, want an additional parameter added to this command. These installers seem to always want to write a log file out, and will default to writing this in the same directory as the Setup.exe. If the person or script installing the software does not have write access to the directory where Setup.exe is stored, the install will fail. To get around this issue, add the “/f2” parameter to the command line as illustrated below:

Setup.exe /f1”\\server\share\install.iss” /f2”C:\Temp\install.log”

In this example, the response file is stored in the path \\server\share. The log file created during installation will be written to “C:\Temp\install.log”. Note that whoever installs the software must have write access to the C:\Temp directory or the installation will fail.

While many InstallShield installers support the recording and playback functionality, you will find many that do not.

In Part 5, we will examine how to deal with InstallShield installers that contain an embedded executable.

Software Packaging    , , , ,

InstallShield for Administrators–Part 3

Dec5th
2012 Written by mike

In Part 1 of this series, we discussed the challenges an InstallShield based installer presents administrators.  In Part 2, we described ways to identify that a given installer is based on the InstallShield technology.  In this article, we’ll discuss how to determine what an InstallShield installer is doing behind the scenes, so that we can figure out how to construct a command line that will allow us to install the software silently.

Deconstructing an InstallShield Installer

To determine what command line options might work for an InstallShield installer, you need to first understand what that installer is doing behind the scenes. Is it extracting another executable? Is it extracting an MSI? Or both? Or neither? These observations will help you construct a command line that will silently install most applications. But how do you know what is going on.

There are two free Sysinternals Tools which can help you in this effort:

  1. Sysinternals Process Explorer: This free tool from Microsoft monitors the programs running on your system and can provide detailed information about them.
  2. Sysinternals Process Monitor: This free tool from Microsoft can tell you what files, registry keys, and processes are being created by an installer. This can help you identify any executables, MSI files, etc., that the installer is extracting and find them.

Let’s look at Process Explorer first. Launching Process Explorer with administrator permission and launching one InstallShield installer reveals this:

clip_image002

If we click through the entire installer and see only “Setup.exe”, we can assume that this is a self-contained InstallShield installer. This type of installer can usually be automated using the “Recording and Playback” method discussed later.

In other cases, you might see something like this in Process Explorer:

clip_image004

In this case, the InstallShield executable is calling the “msiexec.exe” process, which part of the Windows Installer technology for installing MSI files. This is a good indication that the installer has extracted an MSI somewhere.

Right-clicking the MSIEXEC process will tell us where the MSI file it is installing can be found on our PC or virtual machine:

clip_image006

This tells us that the Setup.exe program contains an embedded MSI file. The command line for dealing with an InstallShield embedded MSI file is very different from that used for a “Playback and Recording” style installer.  That command line differs from the one used for a Package for the Web installer that has an embedded executable.

If Process Explorer shows you that that the Setup.exe launches another Setup.exe, then you know that you’re looking at an executable embedded in another executable. This will require a different command line from the others we’ve discussed here.

Process Explorer could even show a Setup.exe running another Setup.exe, which in turn runs an MSIEXEC.EXE process to install an MSI. Understanding what the executable is doing is key to building an InstallShield silent install command line that will work for you.

Once you have identified what is happening inside a given installer, you are in a better position to identify how to construct a silent install command line for it.

In Part 4 of this series, we’ll look at how to use the “Recording and Playback Method” to perform a silent install for an InstallShield installer that supports this functionality.

Software Packaging    , , , , , ,
← Older Entries

Sponsored Links