Search code examples
installationinstallshield

Is the Install Shield Silent response file (.iss file) login user rights dependent

So i have a scenario where i am using a ISS file to install an instance of oraclexe on windows systems. It works for all machines with "Administrator"(localadmin) rights. However it is failing on domain user logins(these logins are part of the Administrators group).

When i install the oracle separately on that machine we get the install fine. My doubt is that the installer response file is old and was likely recorded on a Administrator login. Can that be a possibility.

Solution

  • Application Repackaging: In corporate settings one often resorts to application repackaging to deal with legacy setup.exe setups, and this is usually exactly because of their problematic behavior in silent installation scenarios. I describe this process here: How to monitor and log manual installation (section "Capture / Repackaging").

    Technical Details: At a technical level Application Repackaging is shockingly simple in its approach. It involves scanning the system before install and after the install and then capture the changes, clean out a lot of junk settings and wrap the finished, new installer in an MSI package (or some other format). Despite the technical simplicity, the quality of such packages depend a lot on the knowledge of its creator. Badly packaged MSI files can be loose cannons.

    Package Format: Application Repackaging can be done in various formats, but the established MSI format (Windows Installer) has a number of benefits for corporate use centering around reliable silent running and reliable remote management - arguably the most important aspects of corporate deployment. Please see this answer for some more details: How to create windows installer. Once you have an MSI you install it silently using standard msiexec.exe command lines.

    Tools: Commercial tools Advanced Installer and Installshield are the most well-known repackaging tools. They are quite pricey. Sometimes people pay deployment consultants to do the single package they have to convert. Very advisable in terms of the knowledge needed to succeed as well. List of repackaging tools from installsite.org.

    Technical Limitations: Repackaging has limitations. Localization (support for different language versions) is one problem area - you capture the English version, so where are the German files for the German version? That kind of stuff. These issues are always different from setup to setup. It is reverse engineering to be honest. Also, dynamically generated content that is machine and user specific such as license keys, certificates, database connection strings with machine names and similar means you might have to do a lot of work to get things to operate correctly, and sometimes it is even technically impossible. It is a black art, but when done right MSI files of excellent quality results that deploy silently without much drama.

    (Re)Packaging Team: Many corporations have whole teams dedicated to capturing and preparing legacy and modern setups for large scale deployment. Many of them are offshore and unknown to most employees. I would check if your company has such a team.

    Logging?: What does the log files say? Is this a legacy setup.exe installer or does it install an MSI file under the hood? I would also check the system's event log for any clues - especially if you don't have a good log file. There should be a default Setup.log file created in the same directory and with the same name (except for the extension) as the response file.

    The /f2 parameter can be used to specify a different log path:

    setup.exe /s /f2"C:\Setup.log"

    Here is a Flexera article on the subject of silent installation: https://resources.flexera.com/web/pdf/archive/silent_installs.pdf

    And the most common silent install with logging command line:

    setup.exe /s /f1"C:\sample\uninstall.iss" /f2"C:\sample\uninstall.log"

    Response Files: The honest truth is that silent response files have never been reliable to achieve silent running. What often happens is that a special dialog pops up that was never recorded in the response file run, and then it all falls apart. This can be a "low disk space" warning or some other form of unexpected, random dialog that nobody predicted could show up.

    Unexpected Dialog: Accordingly there could indeed be something different showing up when you install as domain users that are members of the admin group, although I can't really think of anything in particular that springs to mind as a likely candidate. I suppose the issue could also be one of privilege and access nonetheless. There could be certain NT privileges that are denied accounts in the standard user list for example. All just theories, I would go for the logging to get something concrete to start with.

    Installshield Help File:

    There are several relevant sections in the Installshield help file. Please study these if you need more tweaking of the installation parameters. All switches are documented here - these links are for the 2018 edition of Installshield:

    Some Links: