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).
Related
My install fails on uninstall because of a bug in my CustomAction. I've fixed the bug, but I now have a test machine with that product installed and I can't get it to uninstall (keeps rolling back and staying).
In the past (years ago), I used msizap.exe that comes with the Windows SDK. But it doesn't seem to come with it anymore. I installed it and can't find it. My only guess is that it's no longer relevant in Windows 10.
Anyway, is there a best way to forcibly remove the product so that Windows no longer thinks it's installed?
msizap.exe: You are correct, msizap.exe has been deprecated long ago.
Broken Uninstall Workarounds: This problem is very common. You can find a list of approaches for these kind of uninstall problems here.
The easiest and fastest is probably to just use the Microsoft FixIt tool to remove the package. This basically "unregisters it" by the looks of it, and is similar to msizap.exe in that regard.
If this is just a single machine you can hack the cached installation database using Orca (how to find cached msi path, powershell version, using Windows Explorer - point 2) - if it involves many machines you should make a patch. Please see details in link above.
Virtual Machines: It is obvious, but just to mention that you should check setups on virtual machines so you can just revert the virtual machine when you encounter "development and QA bugs" like these.
Custom Action Flag: You can also add a condition to each custom action so that you can disable the whole custom action from running by a custom command line sent to msiexec.exe.
If your flag is a property RUNCA="1", then you can disable it by setting this flag property to 0 via the command line - this is sort of a little inoculation for the package's uninstall feature breaking - you can disable custom actions from running at all during install / uninstall - it might even be useful for your tech-support guys and real-world installations:
msiexec.exe /x {PRODUCT-CODE} RUNCA=0
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
The app I work on is written mainly in VB6.
Some users report that when they start up my app a different MSI installer will automatically run and try to repair its own installation. Often this is for AutoCAD but sometimes other programs also.
Usually this occurs every time they start the app.
What is a procedure that we can use to diagnose why this occurs? Since it is a third-party's installer which is running we don't have any visibility into what it is doing.
AutoDesk does have some info published on this:
Unexpected installer launches
Windows Installer displayed unexpectedly
but these do not directly provide enough information. Ideally I want to be able to completely prevent this from occurring to my end users, rather than just telling them how to avoid it or clean it up.
Your installer is acting on a directory, file or registry key that Windows Installer knows is part of the AutoCad installation.
First, I would turn on global Windows Installer logging. This means that any Windows Installer activity - including AutoCad's installer - is written to an external log file (in %temp%).
How to Enable Windows Installer Logging
Next, run your installer, and let the AutoCad installer run.
Now go to %temp% and you should find files MSIXXXX.LOG - one for your installer, one for AutoCad. Open these and you can work your way through them and identify which file or registry key the AutoCad MSI find is missing or changed.
You may find WiLogUtl.exe helpful for this:
Wilogutl.exe
With any luck you will identify that the directory, file or registry key triggering autorepair is also in your installer. If you're really in luck you can identify it as an item you should not be installing anyway - perhaps you are referencing a system component that would be present anyway, something protected by Windows File Protection.
If not, you will have to look at something like RegFree COM to move files out of shared directories into your private directory and reduce registry conflicts. Also, if you are using (consuming) the Visual C++ Runtime MSMs to make your MSI, consider using the Microsoft EXE installer instead or (best of all) placing the DLLs directly in your program folder, since I've found that the MSMs can cause just this sort of problem.
With regards to Peter Cooper Jr's comment on VB6 causing self-repair. Please check out the heat.exe documentation for Wix. You will see that there is a special switch the tool supports to suppress extracting certain registry values that are owned by the VB6 runtime itself (and hence shouldn't be messed with or updated by any other MSI): http://wixtoolset.org/documentation/manual/v3/overview/heat.html
Go down the list to the switch -svb6 and read the description to the right. (Reproduced here:)
When registering a COM component created in VB6 it adds registry
entries that are part of the VB6 runtime component:
CLSID{D5DE8D20-5BB8-11D1-A1E3-00A0C90F2731}
Typelib{EA544A21-C82D-11D1-A3E4-00A0C90AEA82}
Typelib{000204EF-0000-0000-C000-000000000046}
[as well as] Any Interfaces that reference these two type libraries
Does your installer write to these keys? If so try to exclude them - this is good to do even if it isn't the culprit in this particular case.
Other than that there is a lengthy description of what can cause Windows Installer self-repair here: How can I determine what causes repeated Windows Installer self-repair?. It is a long article because there are so many different ways self-repair can occur. The common denominator is that different installers on your system are fighting over a shared setting that they keep updating with their own values on each application launch in an endless loop.
I am having trouble uninstalling a package from Windows 7 that I myself have created with InstallShield.
Running remove program from control panel only got 1/2 way before it aborted and rolled back.
Funnily it reported the problem being one of my install steps, not one of the uninstall steps.
Frustrated I used the Windows Install Cleanup and the package is no longer listed under Remove programs.
However when I try to run the installer once more it reports that a previous version of the software must be uninstalled before it can proceed.
I was guessing that the Unique ID was still present in the registry but is not.
How exactly does windows determine that a previous version of the software is installed on my machine?
The best solution to an uninstall issue that prevents the product from being uninstalled is to debug the issue (often a custom action) and fix it or delete it, then rebuild the MSI with the same ProductCode. Then reinstall it with a command line:
msiexec /I [path to msi file] REINSTALL=ALL REINSTALLMODE=vomus
which updates the product in place and the re-cached fixed product will now uninstall. Otherwise (because you can't recreate the MSI) it is possible to go into the cached MSI in C:\Windows\installer and change the MSI manually with Orca, conditioning CAs not to run, for example. But you need to know what you're doing.
In other words and unfortunately, it would have been better to get the uninstall issue dealt with before resorting to the installer clean up utility, which I believe may no longer be supported because it doesn't completely clean up the system.
Your best approach now is to change your ProductCode, UpgradeCode and PackageCode because they'll be among the items on the system that Windows will use to see that your product is already installed. This stuff is in the registry, but it's obfuscated (rearranged guids) and scattered around.
I am working on a VB6 application which has many executable and an Active X dlls.
And there are to be updated in c;lient machines to lates version once in a while which i am asking the user to update manually.
Can you please suggest me a way using which i can update it automatically from the files that can be available online.
Thanks.
Windows Installer has features supporting Patching and Upgrades. Using those techniques you can create various levels of "upgrade" packages.
Your application would need a separate "update" utility that is spawned when the user approves updating, perhaps in response to a prompt your program raises after checking for new versions.
This updater would check the current version and the remote site's catalog of updates to pick the appropriate package, download it to a temporary location, start Windows Installer to process the package (or packages, sometimes you might need to run several Installer runs), and clean up the temp location. Then you might offer to restrt the updated application or on some occasions need to reboot.
This updater would be a fancy form of the common "installation bootstrapper." As you can tell it needs some "smarts" in order to tell what package or packages to download and install in what sequence, when it needs to request rebooting, etc. This would probably be based on a downloaded "rules script" it obtains as part of selecting a valid update option.
After all, sometimes you can just apply a minor upgrade or patch upgrade, sometimes you need a more complete install or entire reinstall.
If your needs are extremely simple (just an EXE and maybe a few DLLs and OCXs - preferably using reg-free COM) you may not need to go to these lengths. However when you start adding in other considerations like multiple programs, data directory creation and security settings, possibly running a settings file conversion or even database conversion, DCOM, firewall, etc. configuration, database drivers or providers, etc. things get complicated quickly. Too complicated for simple snatch and grab updating.
And admin rights/UAC issues are a factor so you'll probably have to deal with privilege elevation.
None of this is trivial stuff. There are people who do little more than construct and test such deployment systems as their entire job.
If you use soemthing like Inno setup to install the application then an update is simple a matter of running that periodically.
You can either detect there is a new version available by checking a web site/local server, or just prompt to run the update after X days.