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

Mike’s Guide to the Galaxy S3 Alpha

Mike’s Guide to the Galaxy S3 Alpha

I found myself recently in a position to switch from Sprint to another carrier.  I eventually settled on Black Wireless, which uses the AT&T network.  AT&T has much better coverage in my area than Sprint did.  With Sprint, I lost coverage half way home from work and had to have an AirRave device in my house just to make and receive calls.  None of this is an issue with AT&T and Black Wireless.

To switch from Sprint to Black Wireless, I needed an unlocked GSM phone.  Having very much liked the Galaxy S3 I had with Sprint, I decided to get another GS3.  I ordered a used International Galaxy S3 from  When it arrived, I learned some good and bad things about the device.

On the good side:

  • The Galaxy S3 Alpha has a quad-core processor, versus the dual-core processor Sprint had in its Galaxy S3.  It also has more RAM. This makes it faster than my Sprint GS3 ever was (not that the old phone was a clunker).
  • The S3 Alpha has the same high quality screen and thin, light form factor as the GS3.
  • It’s a nice titanium gray color instead of blue.
  • The S3 Alpha uses a Micro SIM (not a Standard or Nano SIM) and thus is compatible with any U.S. carrier that offers a Micro SIM.
  • Its radio supports the U.S. GSM bands, the 3G and 4G LTE bands.

But there were some bad things about this phone:

  • It was built for NTT/Docomo in Japan.  Many of its prompts are in Japanese and cannot be switched to English, as far as I can tell.
  • The Android OS was set for Japanese.  I had to switch it to English, which isn’t hard (we’ll discuss that soon) but it’s a pain.
  • The Galaxy S3 Alpha doesn’t use the same battery as the American GS3, so my spare battery and external battery charger were worthless.
  • The S3 Alpha doesn’t use the same bootloader as any other Galaxy S3, American or International.  To swap out the Samsung bootloader with my own, so that I could install my own ROMs, I needed to get a special version of the bootloader that was customized for the S3 Alpha.
  • The S3 Alpha doesn’t use the same ROMs as other versions of the Galaxy S3, whether American or International.  More correctly, these ROMs have to be run through a script that prepares them to work on the S3 Alpha, a process that is (perhaps somewhat offensively) called “Japanizing” them.
  • The back cover of the device is slightly wider than the standard American GS3, and therefore cannot use replacement covers or snap on cases designed for that phone.
  • Because this is a phone intended for the Japanese market, finding cases, spare batteries, and the like will be more difficult than for a standard GS3.

I decided to keep the S3 Alpha, in part because I knew it would be a learning experience and in part because it’s a really nice phone… far nicer than my old Sprint GS3.

In this post, I want to share some things I’ve learned about the GS3 Alpha.  Others have blazed the trail and documented these things elsewhere (and I’ll link to those resources where possible and appropriate so that you can refer to them if you like), but I found that much of this documentation made assumptions about what I knew or was trying to do which were not always correct.  In this post, I’ll share what worked for me – in the hope that it will help you also.

Making the Galaxy S3 Alpha “Speak English”

Out of the box, the Galaxy S3 Alpha speaks Japanese.  I don’t speak or read Japanese (not that I wouldn’t mind being able to).  That presented a problem.

The solution is simple, though finding it was not.  The Android OS is international in nature and “speaks every language” out of the box.  You just have to know which menu options to choose.  (Credit:  This is based on the Chinavision support site’s instructions.)

First, power on the phone and skip past all the Google “welcome” screens in Japanese as best you can.  Once you’re at the standard Android application launcher, locate the settings icon by picture.  It will look something like one of these:

Tap that icon to open the Settings panel.

Scroll down through the settings until you see an icon with an “A” on it.  It will resemble the following, though it may not match exactly (and the text will be in Japanese)":


Tap that item to bring up a language list.  Scroll down that list until you find English and tap on it.


You should observe that the menus, prompts, icon labels, and nearly everything on the display is now in English.  A few applications and icons may retain Japanese characters.

Finding a Replacement Battery for the S3 Alpha

Identifying a replacement battery for the Galaxy S3 Alpha is tricky inside the USA.  I searched on and a number of other online stores.  Many of these seemed to think the battery for the S3 Alpha is the same one used in the U.S. Galaxy S3.  It’s not.  The battery in the Sprint GS3 I had was a few millimeters taller than the one in the S3 Alpha.  It was also a 3.7V battery rather than the 3.8V battery in the Alpha.

The part number on the battery supplied with my phone was EB-L1H2LLD.  A number of online suppliers have “replacement parts” for that number, but their ratings didn’t match up.  They were often 1400 mAh or 3.7V batteries.  The one that eventually worked for me was the Anker Li-Ion battery designed for the Samsung Galaxy Premier i9260.  Its specifications matched those of my original battery and the phone was happy with it.  I suspect that this battery may not have NFC capabilities, but I didn’t plan to use that feature of the phone anyway so I didn’t verify that. 

This battery appears to be a perfect match and perfect fit for my phone.  I’ve not used it long enough yet to have an opinion on the quality and life of this battery, but at $5.99 I’m not expecting OEM quality.  As long as it doesn’t catch fire or damage my phone, I’m OK with it.

Connect Windows Live Writer to Blogger

Connect Windows Live Writer to Blogger

The default settings in Microsoft Windows Live Writer don’t work with Google Blogger.  Fortunately, this is relatively easy to correct.  The following steps will get your Blogger account setup in Windows Live Writer.

First, go to the menu and select Options.


The options window will appear:


Click Accounts.  Then click the Add button to add an account:


Select the "Other services" button and click Next.


Pay close attention here.  This is where the setup gets a little tricky.

In the "Web address of your blog" box, you’ll need to put "https://" followed by the URL of your Blogger blog.  Note that if you have pointed an actual domain name at your Blogger blog, you should NOT use that here.  Instead, use the actual Google Blogger URL (e.g., "").

For "User name", supply your Gmail or Google Account address.

For "Password", supply your current Google Account password.  You may or may not choose to check the "Remember my password" box, as you see fit.

Click Next.

If you get an error about your account name or password being invalid, check the following:

  • Verify that your URL begins with "https" and not "http".  Google won’t accept the less-secure "http" protocol for this purpose.
  • Make sure you used the "" URL and not a custom domain name like
  • Make sure your correct Google account name is in the User name field.
  • Re-check that you’ve entered the password correctly.

Once you supply the correct information, Live Writer will connect to the blog and prompt you to select the blog type:


This can be a little tricky as well.  Don’t select the "Blogger" option here.  It won’t work.  Instead, choose "Atom Publishing Protocol".

The "Service document web address" must be constructed as follows:

  • "https://" (not "http://") followed by
  • Your blogger URL (e.g., "" or
  • The path "/feeds/posts/default"

For example, the finished Service Document Address for "" would be:

Provide the correct address and click Next.  Live Writer should connect and let you know that it detected the blog:


Select your blog if it’s not already selected and click "Next".

Click "Yes" or "No", whichever you prefer.  Live Writer will prompt you to indicate that the blog has been setup.

Click "Finish" to end the process.  Exit Windows Live Writer and re-launch it to see the blog in the drop-down list.

Congratulations!  You’ve just configured Windows Live Writer to work with your Blogger Blog.

Enable F12 in Internet Explorer for Dell iDRAC

By default, pressing the F12 key in Internet Explorer displays the developer tools bar at the bottom of the Internet Explorer window. If the user is an administrator who needs to access the Integrated Dell Remote Access Controller (iDRAC) to work with physical servers, this can be a problem as the BIOS on the servers is configured to use F12 to select boot options during power-up. In Internet Explorer, pressing F12 displays the Developer Tools bar instead of the server’s boot options.

This can be corrected on an individual PC basis by setting the following registry key for any user who needs access to the iDRAC:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IEDevTools\Disabled

This key should be created as a DWORD with the value of 1.

To block the Developer Tools for all users on a PC, the following keys can be set:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\IEDevTools]

[HKEY_CURRENT_USER\Software\Policies\Microsoft\Internet Explorer\IEDevTools]

Note that these keys can be set on a per-user basis, configured in the default system image, or pushed out through Group Policy preferences, set by a script, etc. – whatever makes sense in your organization.

Free Repackaging Tool: CapaSystems ezMSI 3.6

Free Repackaging Tool: CapaSystems ezMSI 3.6

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:


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


Once launched, it starts the installation wizard for ezMSI.


Clicking the Next button brings up the license agreement screen.


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


Clicking Next again provides a final confirmation of installation.


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


The installer ends with a completion message:


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.


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:


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


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


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


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


Clicking next begins the snapshot process.


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


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


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


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


Clicking Next begins the final snapshot process.


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


Clicking Yes opens the registry editing dialog:


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


Clicking Next again displays the File editor:


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.


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


Clicking Next begins MSI capture and creation.


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


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


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.


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.


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.

How to Fix iPod Touch Update Errors

How to Fix iPod Touch Update Errors

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.

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

· Click OK.

· Back in iTunes you’ll see a button labeled “Restore iPod”.
(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:
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).


The following pages provided information used to produce this article.

· Stuck on screen with USB under arrow pointing to iTunes logo:

· iOS: Unable to update or restore:

· iOS: Device not recognized in iTunes for Windows:

· iOS: Resolving update and restore alert messages:

· iTunes: Specific update-and-restore error messages and advanced troubleshooting:

· The iPod could not be restored. An unknown error occurred(9).

How to Install Applications Silently

How to Install Applications Silently

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” »

InstallShield for Administrators–Part 9

InstallShield for Administrators–Part 9

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:

InstallShield for Administrators–Part 8

InstallShield for Administrators–Part 8

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:


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:


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.)


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:


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):


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:


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.

InstallShield for Administrators–Part 7

InstallShield for Administrators–Part 7

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:


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:


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.

InstallShield for Administrators–Part 6

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.

Sponsored Links