Windows Installer technology supports administrative installation. The command line for initiating administrative installation is: 'msiexec /a setup.msi'. I want to understand the purpose of this type of installation and in what scenarios are they helpful?
Administrative Installation: Adding some practical examples.
1) Silent running extraction (no GUI):
msiexec.exe /A MySetup.msi TARGETDIR=D:\Extract\ /QN /L*V D:\Extract.log
2) Interactive extraction (setup GUI for extract):
msiexec.exe /A MySetup.msi
Quick parameter explanation:
- /A - run administrative installation sequence.
- /QN - run completely silently (alternatively: /QB! for semi-silent).
- /L*V "Extract.log" - create verbose log file.
- TARGETDIR - destination path for file extraction (top level folder).
3) Some setup.exe files can run administrative installation via
setup.exe /a
Setup.exe Command Line Samples: Extract MSI from EXE
Setup.exe and Update.exe Command-Line Parameters
Setup file extraction, alternative
msiexec.exe command line:
Msiexec (command-line options) - MSDN overview.
Here is the Technet version.
Purpose of Administrative Installs
Administrative installs are generally most useful in large scale deployment scenarios where software is installed on many computers at once, for example in a large bank with thousands of workstations. In fact it is quite critical for such deployment scenarios. As an application packager the first thing you tend to do is to do an admin install to inspect the MSI file content and structure.
Operations in an Administrative Install
The admin install itself simply extracts the files from internal cab files and adjusts the media layout of the MSI file to use the extracted files for installation instead of the internal cab files. The end result is a neat folder hierarchy showing where files will go on the target system, and a smaller MSI file than the original now stripped of internal cab files. The operation makes no changes to the target system apart from this extraction unless the MSI is custom-designed to do so which is a serious design error in almost all cases. Exceptions, off the top of my head, may include setting up licensing files, or post processing files for deployment in some fashion. I have never seen such constructs in real life, but it is possible to add custom actions to admin installs.
Use of Administrative Installs
After the admin install the extracted files can be put on a network share accessible from thousands of workstations and it can be installed from there. Typically this is done via specialized deployment software such as SCCM (previously Microsoft SMS) or similar. However the install can also be triggered manually by the user on a workstation in some cases. The critical benefit of this network share install is that self-repair operations and subsequent patch and upgrade installs to the workstations have access to the original source files so the installs complete successfully. You may have experienced that Microsoft Office would suddenly ask you to insert the installation CDs in order to reinstall a few files. This would happen to workstations too unless the sources were available online. This source requirement may change in the future as Microsoft caches more and more installer content on each local machine (Windows 7 onwards, UPDATE Jan 2018: See this answer for more details on this caching: Why does MSI require the original .msi file to proceed with an uninstall?). I should add that you can also put the unextracted MSI file in such a location without extracting it via an admin image, but using admin install allows any file to be downloaded separately (no huge cab download). For huge MSI files this is important, and I prefer admin images as installation source to make patching more reliable - this is a subjective preference, but it is due to real-life experience.
Administrative Installs & Patching
Finally the creation of MSI patches typically requires an admin install to be run for the original setup and also for the new setup. The Windows Installer patch file is then created based on the differences between the new and old installer folders. As such admin installs are critical for the subsequent creation of patch files. This is the case for Wise for Windows Installer - the only product I have found to create really reliable patches in real life experience (this product is now off market, some details here: What installation product to use? InstallShield, WiX, Wise, Advanced Installer, etc). Again a subjective observation based on extensive real-world testing.
It is also possible to patch an admin install if you get an MSI and an MSP (path file) from a vendor. You extract the MSI and patch the admin image with the MSP. The target folder will then contain a newer MSI and any new files (provided the admin patch works, which it generally doesn't in my experience).
"Run From Source"
Chris mentions "Run From Source", and this is indeed a rather useless and obsolete concept where some files in the install can be left on the network share and accessed straight from there. I honestly haven't tried this feature in years.
This feature is seldom used, but I guess it could be beneficial in scenarios where a common set of resource files should be accessed by all workstations and you want to avoid mass-duplication. Fixes to the resource files could then be deployed by an "admin install patch" as described above without reinstalling anything onto the workstations (how well it works is unclear - the lack of use of this feature may be a clue).
A large software suite with many and dissimilar modules where only a few are used by different people could speed up installation and usage significantly by only installing a few of the required features and leave the rest to run from source or install on first use. It would speed up installation and subsequent patch installations and could leave potentially unsafe and unnecessary binaries off the system. This last point can be important in locked-down environments. However, in real-life I have seen patches change advertised features to be locally installed after patching which is very strange and undesired behavior, but very common to experience. In practice I find "run from source" or advertised features of very limited use. It is generally better to split a setup into two with one for client and one for server installation.
UPDATE:
Here is a new summary of the same issue: admin install and its uses (file extraction and beyond). Please also read the comment below on the "changed caching behavior of MSI in Windows 7 onwards".
In the real world, it doesn't have all that much value at all. MSI was designed back in a day when a computer typically had a 2-20gb hard drive. They came up with all these "run from source" advertisement scenarios which seemed really cool back then but never really caught on in the real world.
Today, what /a does for me, a setup developer, is give me an easy way to "extract" an MSI and verify its contents. That's about it.
Say that you need to install product X on some number of machines, and that you will need to apply some patches for X as well. Rather than applying a series of patches on each machine, you can do this:
Create an administrative image for X
Apply the patches to the administrative image
Install X on each machine using the patched image
It can save some time and effort, and you'll know that all your machines are certain to be at the same patch level.
If you have a per-user setup and a system that disallows user installations through e.g. group policy then the user will be able to install from the msi created in the target folder by the administrative install.
Its a way of authorising software to be installed.
Related
Inside our .NET Framework 4.6.2 solution; we have a WiX project responsible for generating the .msi installer package for our WPF application.
The generated .msi installs fine on my machine, but not on colleague's computer.
After investigating for a couple of hours, we concluded that it was because of the nature of the D:\ drive on my colleague's computer.
The .msi was being run from an alias hard drive. He created the alias by following instructions here. So an alias drive is just a regular folder on C:\ but you turn that into an alias hard drive.
When the .msi is run from outside the aliased drive, the program installs without any problems, otherwise he gets these errors:
Clicking Retry doesn't do anything, but clicking cancel gives the following:
On my machine, I don't have any alias hard drives set up, and things just work, in other words, the program installs without any issues.
How do we get the installer to work with alias drives too?
This isn't supported by Windows Installer. The alias created by Subst only exists in the user profile that created it. MSI runs as SYSTEM and can't see it.
Subst Considered Harmlessly Useless: Yes, as Chris states we have both seen this before. MSI is an old girl, and newer Windows features or old ones that are weird cause such problems.
Workaround: In the realm of workarounds, maybe check features and / or transforms:
Optional Features: what is this D:\ drive? Is it his personal data storage? Are you installing files into "My Documents" or something like that? It you make a separate feature for the components going into the D:\ drive and then unselect that feature from installation, does it then install? (albeit with a few missing files). Screen shot of feature selection.
Transforms: There are also other ways to achieve the suppression of features and files from installing. You can use transforms - little database fragments - to apply runtime changes to a running MSI installer. More on transforms here. Shorter version here. And just one more.
Administrative Installation: You can (also) get hold of the missing files from another computer, or maybe by running an administrative installation of the MSI: What is the purpose of administrative installation initiated using msiexec /a? (glorified file extraction).
Disclaimer: I've still never gotten beyond the most basic WiX tutorial, because every time I try to understand the concepts, my head starts spinning.
I've been reading Is it feasible/sensible to wrap an InnoSetup installer inside an MSI for easier distribution via AD? :
There is a tool (look for exemsi MSI wrapper) today that can wrap a script/exe based installer, like InnoSetup, and provide install, upgrade and uninstall.
From my experience, that's what users expect: Can install product, newer setups can upgrade it, uninstalling will remove product.
Yet quite a few answers on that question state that only a "true" MSI can reliably provide "all"(?) required(?) features.
So, given that what I always thought an installer was supposed to do is:
Install product with as little hassle as possible
Allow repairing a product (possibly by simply running the setup again)
Allow upgrading of product via a newer setup
eventually uninstall the product, leaving as little trace as possible.
The question is, given that it is proven that, given the right tool, the points above are possible by simply wrapping an exe in an MSI, what additional advantages do "real" MSI packages offer?
To be clear here: An MSI package does (seem to) offer additional benefits for enterprise / AD / GPO distribution, that you don't have if you have a bare .exe installer - I don't question that. What I'm interested in is what - actually used - features are only possible through a "real" MSI package?
MSI supports installing additional features on demand. A shortcut (.lnk) created by MSI contains special metadata recognized by Windows and can automatically repair and/or install missing features.
Another advantage is that non-administrators can install patches without UAC elevation if the package is signed.
Some disadvantages of MSI are:
Cannot create a single .msi for 32-bit and 64-bit targets.
Single user/non-elevated installers can be problematic because the support for this has changed over time and new MSI properties have been added.
Depending on your minimum supported Windows version you might have several major versions of MSI to test/deal with.
Bloats your system drive by storing the full .msi in %windir%\Installer on recent versions of Windows.
Bloats the registry by storing the path and other information about every single file it installs.
Installation or removal operations are by Feature (of a Product). This is not as relevant as it used to be because of the trend toward smaller installers with fewer questions being asked of users. For large installers, for example Visual Studio and SQL Server, questions are asked via bootstrappers--the opposite of what you are considering.
Installation, repair and removal are by Component (across all Product and Version). Reference counting is under the control of Windows Installer and is less likely to become corrupted than the pre-Windows Installer technique. Shared components are now less common because of different application technologies such as .NET and registration-free COM. Large systems might share components but again they might be divided into separate installers so that no Component is needed by more than one Product.
Whether these are advantages depends on the needs of your installation architecture.
MSI supports advertisement of the available application without installing them (more details in this MSDN post). It's handy in a corporate environment as it allows deploying only the most essential applications and 1) saves physical space on user machines; 2) reduce expenses for apps with per-user licensing (only those who really need that app will actually install it and activate the license).
Background
I'm currently triaging migrating an existing non-MSI setup to a Windows Installer based solution. The current solution is written in InnoSetup and I very much like it, however, customer IT departments start to require MSI, and where they do so, it is often the case, that many/some of the prerequisites and scripts we include in our setup.exe are not needed for their automated tasks (but, then, some are).
Therefore it seems a pure MSI wrapper doesn't make too much sense here, so I'm looking at (multiple?) MSI files plus a boostrapper.
Prior knowledge
I'm good an InnoSetup, but I'm just starting to read into the Windows Installer technology.
Question
As far as I can tell, for any multistep / "complicated" setup requirements including prerequisites and stuff, using just a bare MSI file is a no-go. (As evidenced by the existence of all the different boostrappers, including the one bundled with WiX, Burn)
Therefore, I would need to split our existing monolithic setup into several steps, some of which (mostly those that install our files) bundled into MSI databases and some of the steps just "scripted" in the bootstrapper.
And here is where I really could use some prior experience regarding setup packages: What parts of a (chained) setup go into the MSI package(s) and what part goes into the bootstrapper?
Should all the (normally visible) UI reside in the bootstrapper or do you put some of it into the MSI files?
How "dumb" should each MSI file ultimately be? That is, if using a bootstrapper and multiple MSI files anyway, should any individual MSI file contain any optional parts, or should all the options be factored out into separate MSI files (that just check for the existence of their respective prerequisites, but contain no logic to install them)?
Basically, the application (suite) needs to support a click-through average user scenario where the setup handles everything and for corporate clients needs to be able to be split up into MSI files that only contain our stuff minus dependencies like the .NET runtime, SQL Server, ... that'll be handled by the client's corporate IT and our software MSIs will be deployed by the client IT automagically.
So, should all the glue and dependency scripting go into the bootstrapper and only use very simple MSI files? Or should some "logic" go into (some) MSI files?
Short-ish answer:
When there are multiple MSI files it is normal for the UI to be handled by the Burn bootstrapper because you do want to see combined progress, not all the separate MSI UIs. You also should set up appropriate rollbacks of more than one MSI in the event of a failure of one if you are really packaging several MSIs as a product, so if one fails they all need backing out.
The bootstrapper contains detection logic that determines what needs installing, and can install prerequisites like SQL, NET etc, but must not otherwise change the system.
The MSI files contain all the files, service installation, COM registration and so on that is appropriate for the files being installed. Any custom action code you use that alters the system must be in the execute sequence, deferred, and have a corresponding rollback CA to undo whatever it does. The MSI should be capable of being run independently to install its content - I've found that to be a useful guideline. The MSI files will be installed without their UI, so ensure that they can be installed silently with parameters passed as property values on the command line, including install location.
Hard to answer this in brief. Do use Burn or a similar bootstrapper, and leave runtimes with their own deployment solution as a separate file to run - and run in silent mode by default.
For home users you should install everything without too many questions to avoid confusion.
For corporate deployment you should deploy only what is needed and make it clear what each included deployment file is for:
Write a one page PDF with deployment instructions describing what every file does and what runtime it relates to. Call it "DEPLOYMENT README.TXT" or similar. This is the best way to get your application approved for corporate deployment. It can be tiresome to analyze this.
Application packagers in the corporate environment will analyze the prerequisites and determine if your application will work well with their standard framework packages. These standard packages will be set as a prerequisite in the distribution system.
Document in particular what .NET framework version is needed and other runtime requirements in detail.
Don't install windows hotfixes, msiexec engine updates or .NET framework runtimes automatically. Document them as prerequisites in your text file. These runtimes are tightly controlled in corporate settings and they are deployed by customized corporate packages.
You can include merge modules of simple runtimes in your MSI, they can be easily removed by the application packaging team in the corporate setting.
This answer didn't get terribly good, but I am out of time. Perhaps check this answer as well:
MSI Reference Counting: Two products install the same MSIs
I have a small application that is designed to run under currently logged on, non-administrative workstation user. Application can be installed manually but I also made sure that it is compatible with Group Policy Objects (GPO) software distribution method - I have .msi files for old systems (XP/Vista): separate files for per machine and per user installations as well as .msi file that takes advantage of Windows 7 (and newer) compatibility with WIX Allusers=2 option to allow automatic registry and folder path redirection depending on the installation context.
All is good there, but I am just wondering, is there anything special I need to do to make my installer suitable for installation using Microsoft System Center Configuration Manager? I do not really have resources to just test such a scenario myself and would like to find out about theoretical requirements for installer files for SCCM.
At my day job I'm the Deployment Architect for a Fortune 50 company with an SCCM 2007 environment ( currently migrating to SCCM 2012 ) that has over 300,000 clients. Here's a few tips.
1) We don't do Per-User installs. They are impossible to manage and report on. If an installer must have Per-User resources and we can't get the application (typically vendor provided) we do this using an Active Setup technique where the first time each user logs on the MSI does a repair and populates the Per-User resources. Just realize you'll never get it off... it's essentially forever.
2) SCCM can handle non MSI deployment types but well written MSI's work the best.
3) Use snapshotted VM's to test your install in the SYSTEM context. (PSExec is your friend)
4) Test your install, uninstall, reinstall, upgrade, repair, change. Make sure everything is bulletproof.
5) Don't wrap up prereqs into a setup.exe bootstrapper. Decompose it and allow SCCM to package each of these items. You can then use package chains, task sequences or application model to allow SCCM to manage the chaining. You get better status, reporting and efficient use of the system.
Just a couple of thoughts if I remember these things correctly - the MSI should be capable of silent install, and among other things that means no custom actions exclusively in the UI sequence, because they will not be run at deployment time because you will probably suppress the UI. The execute sequence shouldn't have custom actions that might explicitly display messageboxes requiring acknowledgement unless they are based on calls to the Win32 MsiProcessMessage() API or equivalent.
How can I log only the changes causing a MSI file made by Installshield 2008 to reinstall via "self-repair"?
What is the reason behind self-repair?
How do I disable self-repairing of MSI using Installshield 2008?
Self-Repair, Simple & Short Explanation: Why does the MSI installer reconfigure if I delete a file?
Alternative Answer Available
UPDATE:
There is a shorter, more "solution focused" answer available, perhaps try it first. This answer focuses on "understanding self-repair" rather than explaining the steps to take to eliminate the problem. You might want to read the first section of this answer as well.
Unexpected Windows Installer self-repair issues - Quick Fix?
This "article" has gotten large and somewhat unreadable. Here is a newly written preamble - the short "workaround version" for fixing unexpected self-repair (often found in VB6, Visual Studio, MS Office, MS Outlook, AutoCAD, etc...)
If you experience unexpected self-repair, the first thing you can try is to manually create a desktop shortcut directly to the application executable you are launching when the problem occurs. This bypasses the most common trigger of self-repair, "the advertised shortcut". If this works your problem is "solved" (or avoided). Here is a quick, fleshed-out explanation
If the problem still occurs, or your problem is related to the loading of an MS Office, MS Outlook add-in or similar (that you can't launch via a shortcut), then you most likely have a COM registration conflict on your system, and the fix is much more involved. The easiest to try is to disable any addins you don't need in the addins dialog of the application in question and see if this makes the problem go away
If you still see problems, then you most often need to debug a genuine COM registration conflict (or conflicting file/MIME associations, or command verbs). This normally involves (at least) two conflicting applications on your system that "fight it out" updating the registry on each launch after the other application has run (always launching one of the apps will not trigger the self-repair - the conflict surfaces when you alternate between applications). It is also possible that permission problems cause the same application to fail to update the system and it keeps trying endlessly by repeatedly running self-repair. And there are further possibilities, more details below
The "real fix" is to contact both application vendors and ask them for a fix for the problem (since a fix often requires a fix of both vendor MSIs), but in my experience this is rarely successful. Do try it out though - since this is the way to help everyone with a long-standing annoyance! I have personally provided a setup with fixes for a bank deployment and was very happy to have the problem solved in my package
To debug yourself, you need to get hold of a tool to open cached MSI files on the system and you need to "hack" the database - a very involved task requiring expert skills, you would be advised to seek an installation expert for help if the problem is very serious for your desktop environment. It can work, but don't expect miracles.
Please see the section below called "Finding the trigger or culprit for the self-repair" for more details on obtaining a tool to view and modify MSI files
The rest of the "article" describes self-repair problems in depth. There are many other potential causes of self-repair than what is described in this "short" section.
Overall Problem: Developer debugging and self-repair
Windows Installer is a deployment technology, its job is to install the specified files and registry settings and keep them in the specified install locations and to ensure they are the right versions - self-repair or resiliency is a mechanism to that end. Its operation conflicts with a developers need to exchange files on the fly for debugging, development and testing.
Accordingly, many self-repairs (resiliency) are triggered simply by developers trying to debug their installed application and hot-swapping files on the fly. See section 2 in "Some typical self-repair problem scenarios" below for how to handle this. In other cases there are genuine design errors in the MSI that must be corrected or system administration pitfalls that lead into self-repair - and at times the error source can be hard to find.
I have written about the issue of self-repair in an answer on serverfault.com. Slightly different words intended for system administrators, and reading it now it might be a more accessible explanation than this long one (intended for developers). There is also another, shorter answer here on stackoverflow: Why does the MSI installer reconfigure if I delete a file? (this is probably the shortest one and easiest to understand). And finally I found a very nice article on self-repair by Vadim Rapp: How to fix Windows Installer Efforts to Self-Repair. This article is well worth a read.
No self-repair will occur if Windows Installer determines that the product being launched is properly installed. When self-repair occurs something needs to be changed on the system for the application to run properly.
The Primary Causes of Self-Repair
The details are presented below in the section "Some typical self-repair problem scenarios", but as a quick, foreshadowing list - the primary causes are:
1. Badly packaged corporate MSI files or MSI design flaws from the vendor (the MSI package itself is badly designed and triggers self-repair unexpectedly for a variety of reasons)
Excessive or erroneous use of per-user files or per-user registry keys often with erroneous key paths set into the user profile (instead of HKCU). See section 5 below for more details (and a color illustration of such a situation)
Package interference from erroneous COM server registration (particularly VB6 COM files or VBA files and libraries from products such as AutoCAD from Autodesk, and similar products).
Two MSI packages register the same COM file (ActiveX/OCX) from two different locations and "self-repair fight" on each application launch to keep their version correctly registered.
The last application to launch puts the registry right for itself, and it lasts until the other application is launched and does the same. Once you alternate between applications the problem occurs. See section 7 below for a lot more VB / COM self-repair detail
A component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair)
ACL lockdown permission problems (logged on user can not access key file and Windows Installer triggers repair repeatedly). This can also be caused by ACL changes done externally, but is often done by the MSI itself
Here is a serverfault.com work-in-progress describing common MSI design flaws
2. Files or registry keys are deleted by interference from external causes ranging from (logon) scripts to standard OS features, viruses, security software, etc...
Temporary files are deleted automatically by Windows after being erroneously installed to the temp folder by an MSI package
Interference from bad logon- and trigger happy cleanup scripts and cleanup applications
Antivirus applications blocking or deleting files or registry keys so that Windows Installer can no longer detect or access them
Computer viruses changing or deleting files and registry settings
Overactive computer tinkerers and users delete files and settings they don't understand
3. Windows design changes, flaws or restrictions that causes flawed or problematic deployment
An AD-advertised MSI package fails to install (might be cancelled since it takes too long to install) and keeps bugging people. This is strictly speaking not self-repair but an advertised install that is aborted, but the result is the same: endless reinstall
Terminal server complications. Self-repair is generally disabled altogether on terminal servers. This does not normally cause self-repair problems, but application installs without the required per-user files or registry keys that can be added via benign use of self-repair (read below). The user files and user registry keys are then just missing and problems result
UAC interference, certificate validation failure and other problems resulting from Windows design changes. For every version of Windows security features like these are added and normally end up adding new obstacles for reliable deployment
Even certain Windows Updates (updates, security updates, hotfixes, etc...) can make drastic changes to how security is enforced for MSI packages, and hence cause extremely problematic behavior
Though this relates to MSI creation, and not primarily their end-user use, the Windows Update KB3004394 which updates the way Windows checks for revoked root certificates, breaks older version of Installshield's command line build (for setups that were digitally signed). Largely a resolved issue by now, but an illustration of how Microsoft keeps changing core MSI functionality
In a similar manner Installshield crashed for many users after installing Microsoft update MS14-037 “Security update for Internet Explorer versions 6, 7, 8, 9, 10, and 11” (KB2962872)
An extremely problematic change in Windows Installer base functionality occurred after installing kb2918614 (Vista). Suddenly administrator credentials were required for a simple MSI repair operation. This defeated a core benefit of MSI altogether: the ability of regular users to run approved installs with temporary admin rights. There were also other reported MSI problems after installing that fix. It appears another Windows update fixed the issues: kb3008627 (later replaced by kb3072630)
About Self-Repair
Windows Installer is designed to install your application's binaries, settings- and data files and keep them installed and ensure they are the right versions. Self-repair is a mechanism to that end. The overall concept is called resiliency - i.e. a broken installation triggers a self-repair before the application is launched.
Resiliency, or self-repair, is a built-in primary concept of Windows Installer and can not be turned off in any way that is safe. People do the most incredible things sometimes, such as disabling the whole Windows Installer engine to stop their self-repair. This must obviously never be done. The cause of the repair must be identified, and the problem resolved rather than creating new ones, or hacking the system.
Every time you launch an advertised shortcut (essentially a special shortcut that points to a Windows Installer feature and not directly to a file), Windows Installer will verify the installation by checking the "component key paths" for your product. If a discrepancy is found, a repair is triggered to correct the incomplete installation. The "component key paths" are the "key files" specified for the components inside your MSI - there is one per component. Self-repair can also be initiated by someone instantiating a COM server (or attempting to), someone activating a file via its file extension or MIME registration, and a few other ways. Here is a comprehensive article from Symantec on the subject of "self-repair entry points": Initiating Self-Repair and Advertising Features with Entry Point.
If files are deleted, moved or simply overwritten (manually by a user or somehow automatically), self-repair may result (if the file or registry setting isn't set as a key path self-repair is not triggered).
Finding the trigger or culprit for the self-repair
The trigger for the self-repair is generally possible to find in your event viewer on the system where the self-repair took place. Follow these steps to open the event viewer:
Right click "My Computer"
Click Manage
Click continue if you get an UAC prompt
Go to the Event Viewer section, and check the Windows Logs
Alternatively you can do: Start => Run... => eventvwr.exe for just the event viewer. If you don't see run in the start menu, press WINKEY + R.
Look in the "Application section" of the event log and you should find warnings from the event source "MsiInstaller" with IDs 1001 and 1004
In the sample screen shot above the product code is shown inside the red box
In order to determine what product the product code is for, you can look up the product name via the procedure explained here: How can I find the product GUID of an installed MSI setup?
If you actually want to go in deep and check the actual content of the MSI file, you must get hold of a tool capable of viewing a MSI file (such as Orca, Installshield, Advanced Installer or similar). You then open the package listed in the "LocalPackage" path listing as illustrated in the screen shot found in the answer linked to in the previous bullet point.
The actual modification of the system-cached MSI file and/or the registry to remove advertised entry points such as (advertised) shortcuts, COM registration, file associations, MIME associations or command verbs is a specialists job. It is very involved and not good practice, but it is the only "last resort" that I know about.
Finally it is possible for an application to explicitly call Windows Installer itself to trigger self-repair for shared components - for example a spell checker. I believe a few versions of Microsoft Access did this, and this behavior can not be changed or worked around as far as I know.
MSI-expert and MVP Stefan Krüger has an article about the same self-repair issue. And he crucially discusses the actual event log entries and what they mean. Please read about the actual debugging procedure there.
Some typical self-repair problem scenarios:
This is the "verbose explanation" of several self-repair problem scenarios already outlined in the overview above.
A component key path is set to an empty folder that Windows installer removes on self-repair (triggering an endless loop of removal and subsequent self-repair). This is solved by adding the folder to the CreateFolder table instead (Wix equivalent). In my experience this is the most common scenario for unwanted self-repair. Very common.
Many self-repair problems are actually caused by developers trying to debug their applications by replacing files on the fly, deleting files or renaming them. Or they may use cleanup registry scripts and / or batch scripts to unregister and register COM files, COM-Interop, GAC files, file associations, or other common developer debug and development tasks.
This hot-swapping can triggering self-repair when the application is launched via an advertised shortcut.
A top tip for developers struggling with self-repair during application debugging is to not launch the application from an advertised shortcut, but to launch the main EXE directly from Windows Explorer or from a manually created shortcut. This will bypass the most common "self-repair entry point" - the advertised shortcut. Self-repair may still result from broken COM data, advertised file associations and a few other special cases (read this Symantec article for entry point information).
Other applications or rather other MSI packages can break your installation and cause self-repair by interfering with registry data - typically COM settings, but also with other settings and files. These can be some of the hardest cases to solve, since the applications are basically fighting it out and the last one to run will update the registry each time. Typically both MSI files must be redesigned for the applications to operate on the same machine. Or, as is the order of the day, the whole application may be virtualized (for example: Microsoft App-V virtual packages) and run in its own sandbox which seems to be what is done more and more in companies these days. This error scenario is often seen with a suite of badly repackaged applications in a corporate environment. COM fragments from different packages overwrite the COM server's disk path from another package, and self-repair fighting ensues on each application launch via an advertised shortcut. The same file name with different file versions can also be registered from different file locations and share some registry settings that interfere. As far as I recall at least 7 variables or settings in the file system and registry must be in sync for a COM server to be properly instantiable. See section 7 below for a more specialized description of COM interference in the context of VB6 and VBA COM applications.
A component key path is pointing to a temporary file that has been deleted by the application or it will be deleted by the system eventually via some sort of cleanup mechanism (can also be a cleanup tool such as ccleaner). This is common for files in the temp folder itself. This is solved by not installing the temp file, or putting the file somewhere else and making it permanent. I have seen this error most often in the world of corporate application repackaging where a faulty cleanup of the captured image leads to the install of a temporary file that should not have been included in the package at all. Often they may be temporary files waiting for a reboot to be installed to their intended, perhaps protected location, and the reboot was never performed - a common application packaging error. To a lesser degree I have seen it in auto-generated packages coming out of automated build systems.
Permission problems: if a key file for a component is installed to a location that is not accessible for the user who invokes the application. Windows Installer might not "see" the installed file / key path, or be unable to add the file to the folder. These issues can be more exotic to debug, and may not happen that often. There are several variations on this issue:
An example of this is when you install a file to a %USERPROFILE% path and then forget to set a HKCU registry keypath, and instead set the keypath to point to the %USERPROFILE% folder/file. This generally yields an inaccessible hard coded key path that is user-specific: C:\Documents and settings\user1\Desktop. This path will not be found for another user logging on, and self-repair runs in circles. Here is a color illustration.
Another example is key paths set to folders that are not writeable for the System account. This may seem exotic but can result from the MSI's faulty modification of system ACL entries, or from a strange system administrator security setup, or any other non-standard ACL / Security Descriptor.
Another class of self-repair problems emerges in relation to terminal servers and Citrix. The whole windows installer service could be locked down so any self-repair invoked to add per user data could fail and consequently self-repair may fail or more likely not run at all. This is reason enough to not rely on self-repair as a way to add user data like some MSI files do, and such constructs must be replaced with application deployment of user files copied from per-machine locations or the less effective ActiveSetup feature from Microsoft that runs once per user.
VB6 applications and VBA applications, which are heavily COM based with massive potential for COM interference (COM settings overwriting each other and becoming inconsistent), have been known to trigger several mysterious self-repair problems, most of which have not been properly explained. This can also happen on launch of Visual Basic 6 (VB6) or Visual Studio (and many other applications). The common denominator is that some error in the current installation state triggered the self-repair, and you can track down the culprit product and component by following the steps outlined in the section above called "Finding the trigger or culprit for the self-repair". Be sure to report your findings here (I never use VB6 or VBA anymore - your detailed findings could help others with a long-standing annoyance).
Though I have never debugged such VB6 issues in great detail, it would seem that the problems result from applications that install common controls, VB6 COM files, templates and VBA files and libraries that conflict with existing files and registry settings and registrations on the box, or some per-user registry key or userprofile file may need to be added once per user (allow the self-repair to complete once and see if the problem goes away). In particular I have heard of these mysterious self-repair problems when launching AutoCAD (from Autodesk), Visual Basic 6, and several other products (often with VBA automation available in the tool).
Some applications even erroneously install bits and pieces from the VB6 runtime on their own causing these settings to be "ripped out" on uninstall of those applications. This can certainly cause self-repair to be triggered to fix the now (partially?) broken VB6 runtime. There are several variants of this problem, and the "catch all" solution is probably a complete uninstall and reinstall of the VB6 runtime. Here is a description of a very common "specific" problem involving a few COM registry keys. It nicely illustrates what happens in this scenario.
If you experience unexpected self-repair when launching VB6, AutoCAD, Visual Studio or other products, you can first try a workaround to prevent these unexpected self-repairs from happening in the first place (this doesn't solve the problem, but may bypass its symptoms): why does windows installer start up everytime i start up visual basic 6
See my comment to the question in this topic for one of the most typical VB6 style self-repairs: Why does my application triggers the Installer of another application? (ActiveX control registered twice from two different locations on disk).
In my opinion the "general fix" - that should always work - for VB-COM self-repair issues, is to get the vendor to update their project in question to use the latest official and properly installed and shared ActiveX control / OCX available, and not to rely on their own version installed redundantly and registered in the wrong location.
A special case of Windows Installer repair or self-repair that is worth mentioning for completeness, was the issue with Microsoft Office several years ago where a self-repair would be triggered, and you would be asked to insert the Microsoft Office installation media (in those days CD-ROMs or DVDs - today maybe thumb drives). As far as I recall this was related to an erroneous call to the built in Windows Installer standard action "ResolveSource" which unexpectedly (and unnecessarily) triggered the prompt for the installation media. A very common support call back in the day and mentioned here for completeness. It is important to note that this problem can still occur whenever MS Office is installed from any removable media (rather than the better option of a network share). This happens when MS Office detects that it needs to install further, optional (and usually shared) components of the product that were not installed originally. For example unusual spell-checkers, various templates or specific and rarely used tools. It is possible to install these components to "install on first use" (advertised features is the proper Windows Installer term).
There are many other possible scenarios. To mention a few:
a bad logon script may delete things on the system and trigger self-repair
an AD advertised package may fail to install and keep bugging people
two applications may start fighting for the same file associations
computer tinkerers and hackers can manually delete data that trigger self-repair
anti-virus can quarantine files and registry settings that trigger repair
a virus can change or delete things and trigger self-repair
a disk and registry cleanup tool such as ccleaner can delete files and trigger self-repair
and no doubt numerous other scenarios...
Benign uses for self-repair
Finally there are benign uses for self-repair that happen once and do not constitute errors. This is the legal and proper use of self-repair though it may be just as annoying as the design errors, and with user intervention they can pop up again and again:
Self-repair is sometimes used to add per-user data to HKCU and the user profile. This design mostly works, but gets worse for every version of Windows as new obstacles are put in place for deployment. For one thing self-repair typically does not work at all on terminal servers rendering the setup incomplete. Though it is besides the point for this discussion, it is better to have the application copy files to per-user locations. Another issue is UAC. Other problems show up with each new Windows version and even with some Windows Updates as described above (virtual folder redirects, certificate prompts, previously non-existing target path restrictions etc...).
When self-repair is needed to set up user data, it may take so long that the user aborts it and keeps doing so. This causes the self-repair to reappear all the time until it is allowed to finish. A common support call.
It is also possible to install a product with "advertised features" that are designed to be installed "on demand" triggered during application use. Few applications use this, but when it is used a lengthy "self-repair style" installer may run - pulling down the required files and settings. If this process is cancelled the installation of the feature is rolled back and it can be triggered again. This install can be slow for several reasons:
If the installer used large, compressed CAB files that are first downloaded and then extracted locally on a slow disk where the anti virus starts scanning the whole cab and then each extracted file the operation can take a long time.
The operation can also be slow if the network connection is wireless and there are lots of small files to download (high latency), and again the anti virus could slow down things.
If installed from removable media, you could get prompts to insert the source media to allow files to be copied. A very common support call if removable media is used in an office environment (it shouldn't be - use an admin install on a network share)
Etc...