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.
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:
Setup.exe and Update.exe Command-Line Parameters (Basic MSI, Installscript MSI)
Advanced UI and Suite/Advanced UI Setup.exe Command-Line Parameters (Suite Projects)
Some Links:
Uninstalling an InstallShield Installscript MSI program using C# silently
Create MSI from extracted setup files
Related
It's a common practice to disallow users from installing programs without elevated privileges, especially in larger companies. When the user runs the installation executable (whether .exe or .msi), the user is prompted for these admin credentials before User Access Control will allow the installation. A lot of programs that require installation take advantage of the default Windows installer .msi packaging or something similar, but an executable file could perform all the same functionalities, right?
Is it this common installation-packaging solution that tells Windows, "Hey, I'm an installer. Something is being installed."? Windows isn't analyzing the actual behavior of the executable file, right?
If your question is about asking for admin credentials, that's normal behavior when an executeable has a manifest that says it requires admin privilieges. I guess that if you say your InnoSetup requires admin privileges it will include a manifest requiring elevation, and Windows will show the elevation prompt.
There is no such thing as Windows InstallShield, in case you are thinking that InstallShield is a Microsoft Windows product. InstallShield is a 3rd party product that in many cases creates an MSI file. MSI files are marked (when built) as to whether they require elevation or not. It's the summary information strean Word Count that says whether the MSI requires elevation to install or not:
https://msdn.microsoft.com/en-us/library/aa372870(v=vs.85).aspx
In the case of an .MSI, sure, Windows automatically knows your installing something. I think your question is more along the lines of what about anything other then an .MSI? Windows has some heuristics built in that AFAIK are managed by the application compatibility team. They do things to detect what they is a setup (like file name, process name, inspection of the summary information stream and so on ) and perform various functions such as detecting a possible failed install, asking if it was an install and if it failed and them performing application compatibility shims such as version lying and forced UAC elevation prompting.
You get to avoid this ugly world my authoring properly designed MSIs. :)
MSIs can be authored per-user or per-machine. Per-user installs won't ask for elevation by default. Per-machine installs will ask for elevation once they hit the InstallExecuteSequence.
I have a freeware software, which i want to install on a network share. The reason is, if the software is installed on a network share, all users which has access to this network share folder should be able to use the program.
Now, I run the setup.exe on my machine and choose on the step "destination installation" my network share \sharename\TestFolder.
The software was installaing on this sharefolder and after the installation it was possible to run the program on my computer without any errors and use it..
After that I try to start the program on other client but there is always an error message, that it starts with a false operator.
Now my question is, is there a software, which can observe on which files the program want to access when I make double click on the (program.EXE).
Thank you, I hope you can help me.
Yes, there are several tools that can monitor or observe system changes performed by a setup.exe.
Many of these tools are quite old and may not operate correctly in new versions of Windows. The most recent one I found that looks acceptable was EMCO MSI Package Builder. I never tested the monitor feature, but it is at least an updated capture product.
In my experience these monitor tools capture way too much low-level system stuff, and you will need to spend quite a bit of time to sort out what is really needed for the software to operate. If you have experience with software development you may get just as much information from using a System Internals tool such as RegMon, FileMon or ProcMon. See Microsoft site: http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx . These tools are exceptionally useful and known for their small size and great feature set. You can run a ProcMon on the launch of the application executable.
It is also possible that the setup.exe is a wrapper for an MSI file. These files can be viewed with free tools such as Orca and EMCO MSI Package Builder and you can basically see what registration settings are needed for the application to operate. Try opening a command prompt and write setup.exe /a and see if it offers to create an "administrative installation point" - or similar.
If I were to guess I'd say that the software needs to have COM servers registered locally, registry keys added to each local computer and possibly you need to install a couple of runtimes on each system - for example Microsoft C runtime of a particular version. This is just a wild guess. What is the name of the software? If it is a .NET application you may need assemblies installed to the Global Assembly Cache GAC.
I have a service installation that in order to get it to work on Win2k, I had to include instsrv.exe in the installer, since Win2k doesn't include sc.exe (which I use for XP and up) and instsrv.exe is not always installed...so I cannot count on it being there. (instsrv and sc are both used to create/install the service on the system).
I have not been able to find the license terms or distribution rights for instsrv however. Is there going to be a legal issue with me including this Microsoft exe in my own installer and therefore distributing it to the customers of the product? If you can point me to an actual license document for this exe it would be greatly appreciated.
The instsrv.exe program appears to come from the Windows 2003 Resource Kit, which you can download freely from Microsoft. The referenced page indicates that when you install it, you'll encounter the EULA (End User License Agreement), which would be where you'd read about the license terms regarding things like redistribution.
You should read that agreement yourself. The way I read it, you can't bundle the Kit with your installer, though you could certainly arrange to have it downloaded automatically and have its own installer invoked by yours, with your end user having to click to accept the Microsoft EULA at that time.
What about using a different approach? I believe for a simple service installation there are probably only a few registry keys or something to tweak. Maybe a simple script (Python or such?) could do the job as well.
I'm no legal expert, but is the issue the use of instsrv.exe or that it's lying on the PC until you uninstall your product?
Would it be redistribution if you craft your installer in such a way that you merely package instsrv.exe, unpackage during the install process, run it via a custom action, then let the installer cleanup process delete it from the temporary location?
As a big sidestep, you could change installers to WiX v3. They have standard custom actions to install services. You get the added Msi easily active directory integrated bonus. You could go with something else entirely but I assume this is a very last resort.
In the end, services are nothing more than registry entries in a specific format so you are not entirely limited to using those programs. You just get the bonus of blaming Microsoft if either instsrv or sc happen to blow up the registry.
I have an old legacy application around for which I only have the installer. it doesn't do anything more than uncompress and register itself and his library's.
As i don't have the source-code it gives me a lot of headaches in maintenance problems. In some particular computers (Acer Aspire One with Windows) just do not run.
I would like to extract the files and re-create this installer with NSIS. Is this possible or I'm nuts?
The original installer has been created with Ghost Installer Studio.
One option is to find a machine that it does run on, and then install some "install guard" software (often called things like Acme Uninstaller). Use this to track what actually gets installed and then copy the relevant files and write your own.
It looks like a lot of hassle to me, and you may be on thin ice with regards to the licence.
You could try using a program that monitors new files being installed and then get the files that were installed from their respective paths.
For instance, I found this in about 10 seconds with Google, there are more programs like it, but I am inexperienced with those available for Windows.
If it uses a MSI file, you can use Orca or SuperOrca to get at the stuff packed inside.
This is typically the job of Repackaging Software. There are a few ways such tools work but typically it is by taking a look at a system before and after you install it on a clean system and building a custom installer from the detected changes. This is normally done to generate a customized installation and/or one that can be automated in its deployment. I'm not aware of one that generates an NSIS package, the standard format today is MSI (Windows Installer).
If you have the original installer any repackager will do, but even without the original setup program you can do as some of the others here suggest and monitor the use of the application for its requirements. The two most popular repackaging tools are InstallShield AdminStudio and Wise Package Studio. The feature may also be part of a setup authoring solution, so check with your in-house developers if you can.
A full list of repackaging tools can be found here at AppDeploy.com
One free repackaging tool available for creating Windows Installer setups from another [legacy] setup tool (with which I must divulge I'm involved) is the AppDeploy Repackager. Another free repackager is WinINSTALL LE.
As most of you probably noticed, when uninstalling an MSI package Windows will ask for the original .msi file. Why is that?
I can only see disadvantages to that:
not resilient to network changes.
not resilient to local disk changes.
unexpected by users.
typically requires users to leave their desk and start a crusade to get the correct CD.
kind of proves installations are not self-contained.
promotes the use of unsafe tools such as msizap.
which in turn promotes the "next time I'll just use a zip file" mentality.
Could someone shed some light on this?
Fix Broken Uninstall: You can try the newest FixIt Uninstall tool from Microsoft if you have problems uninstalling an MSI. And one more link: Uninstalling an MSI file from the command line without using msiexec (a plethora of different ways to uninstall an MSI).
UPDATE:
This new support tool (this tool is now also deprecated) can be tried on recent Windows versions if you have defunct MSI packages needing uninstall (rather than the outdated, deprecated, unsupported msizap.exe).
Some have suggested to use the tool linked to here by saschabeaumont: Uninstall without an MSI file. If you try it and it works, please be sure to let us know. Feedback in that answer indicates that it works (I don't have any stuck setups to test with as of now).
Why are you asked for the original installation media?:
The original MSI is not needed for uninstall unless the MSI itself is badly designed - or the cached MSI is missing (see details below).
All installed MSI files are cached in %SystemRoot%\Installer\*.* using a random hex name.
The cached MSI file is used for any maintenance, repair and uninstall operations - and it is sufficient for uninstall in the vast majority of cases.
In some cases this cached file can be missing, and then uninstall is not possible at all in some cases (some theories as to why this can happen - MSI design errors, anti-virus quarantining, system restore, tinkering, developer system in erroneous state from development work, etc...). See more info below - and links to force uninstall or unregistration of the product.
The original source is only needed if files need to be copied to disk (for a maintenance install), or the MSI does an explicit request to resolve the original source via the standard action ResolveSource or via a custom action (which shouldn't be done in a properly authored package - I think the MS Office package contained this ResolveSource error back in the day, causing everyone to go looking for their installation CDs/DVDs).
In previous editions of Windows this cached MSI was stripped of all cabs, and hence contained the installer structure only, and no files.
Starting with Windows 7 (MSI version 5) the MSI files are now cached full size to avoid breaking the file signature which affects the UAC prompt on setup launch (a known Vista problem). This may cause a tremendous increase in disk space consumption (several gigabytes for some systems). Check this article and especially the discussion at the bottom for more intel.
To prevent caching a huge MSI file, you can run an admin-install of the package before installing. This is how a company with proper deployment in a managed network would do things, and it will strip out the cab files and make a network install point with a small MSI file and files besides it. Note that this may yield a UAC prompt is some cases since the extracted MSI file is no longer signed - this must be tested with your SOE / desktop configuration.
Read my answer in this thread for the full description of admin installs: What is the purpose of administrative installation initiated using msiexec /a? or this similar but perhaps more accessible answer: admin install and its uses
In some rare cases the cached MSI (with the random name) can be erroneously missing, and uninstall will then ask for the original MSI in order to complete the uninstall. This does not happen often. It used to be the case that one could use MsiZap.exe to clean out such an install, but this tool is outdated, deprecated and unsupported. Don't use it - there are too many incompatibilities with newer Windows versions and you create new problems. Perhaps try this support tool instead (also deprecated). The only option I can suggest now is this answer from saschabeaumont. If you try this tool, please let us know if it works for you. If you want to figure out what could have caused the cached MSI to be missing, try to read section 12 here: Uninstalling an MSI file from the command line without using msiexec (in short potential causes range from interference with system restore, anti virus and cleanup scripts, to erronous manual tweaking, low disk space, power outages, developer box debugging errors, badly designed MSI files with duplicate package codes, failed patches, etc... Many theories, few certainties I am afraid).
As a last resort you can try system restore (unless it has been disabled entirely or partly) to go back to a previous installation state and see if this solves your uninstall problem (you can find video demos of this on youtube or a similar site).
Be aware that system restore might affect Windows Update that must then be re-applied - as well as many other system settings. I have seen new, unsolvable installation problems resulting from a system restore, but normally it works OK. Obviously don't use the feature for fun, it's a last resort and is best used for rollback of new drivers or setups that have just been installed and are found to cause immediate problems and such issues. The longer you go back the more rework you will create for yourself. A lot of self-evident stuff, but I guess it needs to be mentioned.
Since I mentioned system restore I suppose I should mention the Last Known Good Configuration feature. This feature has nothing to do with uninstall or system restore, but is the last boot configuration that worked or resulted in a running system. It can be used to get your system running again if it bluescreens or halts during booting. This often happens after driver installs. This will do nothing to fix your failing uninstall though (or I would be very surprised).
Related answer:
Uninstall without an MSI file
In addition to this answer, perhaps this article on various ways of uninstalling MSI packages is of interest. It is a rather popular article with a high number of views:
Uninstalling an MSI file from the command line without using msiexec.
There are a few reasons for keeping the original msi:
The uninstaller uses it to know what files and registry keys were installed and make sure they are all cleaned up.
The msi may contain special uninstall actions that need to be performed.
It allows you do to a 'repair' operation from the Add/Remove Programs menu, regardless of whether or not you saved the install file yourself.
The normal way of things is for Windows to keep the file cached for you, so you don't have to think about it. See your %WINDIR%\Installer\ folder. The only reason it would ask your for the original msi is if something is wrong with the saved file. This addresses most of your concerns, though it does raise a new one (disk-space).