What is the purpose of administrative installation initiated using msiexec /a?
Asked Answered
E

4

29

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?

Executive answered 6/4, 2011 at 10:7 Comment(0)
E
24

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.

Epicalyx answered 6/4, 2011 at 11:31 Comment(8)
+1. On the basis of what you mentioned - How about getting rid of relevant tables (pertaining to administrative and advertise) from the MSI? Do you see any consequences?Executive
I've seen many MSI's ( even from Microsoft ) that have references to Advt removed. The only consequence to me is I can't (easily) do my extract. Although there are ways to build it back up and do it anyways.Epicalyx
Admin installs are important for corporate large scale deployment usage and patch creation among other things. I have added a longer answer to this thread.Clupeoid
I seem to recall that MSFT reccomended not patching admin installs. I know at Continental Airlines we had SMS and I would routinely push full installs to 8000 machines at once. We had very little use for an Admin Install.Epicalyx
Nobody patches admin installs unless they have very special requirements - but it is possible in theory, though rarely working properly in practice.Clupeoid
"Nobody patches..." Well we do...it is a real PITA but Adobe products (way too) often require patching when they release just the .msp file not the whole install. Admin installs are then used to incorporate the patch into a new msi as described in the next answer by Stein AsmulSadden
I take it you don't work for Adobe. We have an automated process that uses a program called Ketarin to look for updates for all kinds of products including Adobe products. We then package them in SCCM as applications and deployment them out as upgrades. No one is manually patching administrative installation points.Epicalyx
Quick extraction to verify content and structure of the MSI without executing any custom actions is exactly what we are using it in many of our pipelines.Occam
R
42

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".

Rugging answered 22/4, 2011 at 3:24 Comment(9)
Sorry, I just can't agree. I work at a Fortune 35 company these days with 300,000 clients in the forest ( 80,000 pc's in the "stores" alone ) and we don't use advertised installs for anything. We don't use AD GPO Deployment either. We use SCCM to do literally millions of deployments and Advertised Installs have no role in this.Epicalyx
We also don't use patching unless forced. It's harder to hand off to operations a series of installs vs one install. Also if you patch an administrative installation, the machines that installed from it have to uninstall and reinstall. It just doesn't buy you anything.Epicalyx
Advertised installs are uncommon, yes - administrative installs are not. Patching is junk, no argument here - but may be needed to patch products with errors in the uninstall sequence prior to their proper removal (minor upgrade patch to avoid triggering uninstall sequence when patching). Or be used for very large packages with very small updates - often just a single file.Clupeoid
Can you walk me through a real world use case? I really never see admin installs being used. Your section "Use of Administrative Installs" talks of using SCCM to install from administrative installation points with the added value of finding source files. I've never seen this done. We always put full MSI's on distribution points and install directly from that. The SCCM client has an agent / action ( Windows Installer Source List Update ) that manages this relationship to give you the benefit you mentioned without needing to do an admin install first.Epicalyx
Admin images allow the download of single files for repair (and self-repair) operations to the client, thus avoiding the need to download huge MSI files for simple repair operations. CAB files can be enormous – and if you have tried updating thousands of machines in a major deployment operation you wouldn’t ask whether this is important for the network :-). And don't get me started on CAB files and anti-virus... Admin images are also crucial for the creation of patches.Clupeoid
Sorry, still not believing it. I could show you our deployment dashboard.... we deploy software of all shapes and sizes to hundreds of thousands of machines and network isn't a problem for us. Admin installs have no value for us in the real world.Epicalyx
Here is a new summary of the same issue: admin install and its uses.Clupeoid
With the changed caching behavior of Windows 7 and upwards (caching full size MSI files to prevent breaking digital signatures), I would strongly recommend using admin installs to install in corporate scenarios to avoid the massive caching requirements for full size MSI packages (an MSI extracted via admin install will have its internal cab files deleted). It is then crucial to have a proper network share location where all packages are installed from.Clupeoid
Just one more note on using admin images to extract the base MSI stripped of cabs. I believe the extracted MSI will lack any digital signatures that the downloaded MSI might have. At a minimum this could trigger more UAC prompts. I am not sure what other side effects could occur.Clupeoid
E
24

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.

Epicalyx answered 6/4, 2011 at 11:31 Comment(8)
+1. On the basis of what you mentioned - How about getting rid of relevant tables (pertaining to administrative and advertise) from the MSI? Do you see any consequences?Executive
I've seen many MSI's ( even from Microsoft ) that have references to Advt removed. The only consequence to me is I can't (easily) do my extract. Although there are ways to build it back up and do it anyways.Epicalyx
Admin installs are important for corporate large scale deployment usage and patch creation among other things. I have added a longer answer to this thread.Clupeoid
I seem to recall that MSFT reccomended not patching admin installs. I know at Continental Airlines we had SMS and I would routinely push full installs to 8000 machines at once. We had very little use for an Admin Install.Epicalyx
Nobody patches admin installs unless they have very special requirements - but it is possible in theory, though rarely working properly in practice.Clupeoid
"Nobody patches..." Well we do...it is a real PITA but Adobe products (way too) often require patching when they release just the .msp file not the whole install. Admin installs are then used to incorporate the patch into a new msi as described in the next answer by Stein AsmulSadden
I take it you don't work for Adobe. We have an automated process that uses a program called Ketarin to look for updates for all kinds of products including Adobe products. We then package them in SCCM as applications and deployment them out as upgrades. No one is manually patching administrative installation points.Epicalyx
Quick extraction to verify content and structure of the MSI without executing any custom actions is exactly what we are using it in many of our pipelines.Occam
C
1

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.

Cryoscopy answered 6/4, 2011 at 18:26 Comment(2)
What if the installer had some registry changes? I noticed (using ORCA) that during administrative install very limited actions are invoked. To my knowledge it does not execute actions for doing registry entries during admin install. How that can be handled in the scenario that you have mentioned in your response?Executive
The administrative install isn't installing the product. It's creating an uncompressed installable image. Basically it's expanding the cab files in the existing installer. When you run that installer, it can then do all the things installers typically do, including the creation of registry entries.Cryoscopy
E
0

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.

Eliathan answered 9/12, 2019 at 15:19 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.