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
msiexec.exe command line:
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".
