On Windows, when a program installed via MSI is run through an advertised shortcut, it checks that all the installed features exist and runs self-healing/auto-repair to replace missing ones.
Is it possible to set a file's ACL as a feature on install that will be self-healed if the ACL is wrong? If it matters, the file in question
is not installed by our MSI
may not exist (not existing is OK, so long as it has the proper permission if it exists)
I'm currently using WiX to build my installers.
No; ACLs aren't resources that MSI uses to validate health. Even if they were, it would likely be tied to a file anyway.
If it's that important, you should check the ACL when your app starts.
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).
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.
i have already an installer for our application. but it is exe-file. it was created many years ago.. application of course was updated. we used a bat-file to register new dll-files and to install our service(windows). but we want to do all this by installer not a bat-file. we chosen a wix techology. i read about <Patch> node, but to use it i need an msi from previous version.. i think to do a simple installer, that will stop service,copy and register dll in the installed application's directory, install service. but i don't know will it overwrite the files without any problems?
You can only create an MSP (Patch) for an MSI (Installer). Also, you're going to run into component ref counting problems if you install your components into the same directory as the original install. The problem is MSI will go to see a file is already there, make it as a shared resource and increment the usage counters. Then on uninstall it will decrement, see that it's not 0 and remove to uninstall the files.
I'd suggest installing to a new directory and then using the RemoveFile table to get rid of the old files. Also I'd suggest following good CM / Versioning practices so that you don't have to worry about hacks such as Version Lying.
If all your application just needs to xcopy files, setup a directory and maybe even a ShortCut, it should be a piece of cake.
Versioned files like executables will automatically be overwritten if the version of the file number is lower.
See also Copy if not exist in WiX.
I've developed a Wix installer for an internal project however entirely by accident I've found that I'm unable to uninstall the installer on my development machine as I get the following error message:
The feature you are trying to use is on a network resource that is unavailable
with a dialog pointing to the path of the .msi that I installed from feature from. (The .msi is there, however is has been rebuilt and so has changed since I installed it)
I'm concerned by this dialog as I had believed that Windows Installer kept track of installed .MSI files, however this dialog seems to suggest that I can break my uninstaller by deleting, moving or changing the installer.
Is this the case?
What do I need to do to make sure that I don't break my uninstaller in this way? (Do we need to keep copies of all versions of the installer ever installed on a machine?)
The easiest way to get out of this situation is to do a recache/reinstall. Build a new version of your MSI that isn't "broken" (in whatever way it is broken, in this case, it might not really be broken at all, you just need a new source). Then you use a command line like:
msiexec /fv path\to\your.msi /l*v i.txt
That will copy your.msi over the MSI that is cached and do a repair. Then you'll be in a better place.
One of the first painful lessons of writing installs is to never run your install on your own box. Certainly not until it reaches a point of maturity and has gone through several QA cycles. This is what we have integration labs and virtual machines for. (There is a saying about things you shouldn't do in your own back yard.)
That said, normally an MSI uninstall doesn't require the MSI but there are situations where it could be required. For example if one was to call the ResolveSource action during an uninstall, MSI would then look for the .MSI.
Now there are several ways out of this pickle:
Take an MSI you do have and edit it with ORCA to match to file name, UpgradeCode, ProductCode and PackageCode of the MSI that you installed. You should be able to get all of this information from looking at the stripped cached MSI that exists in %WINDIR%\Installer. CD to that directory and do a findstr -i -m SOMESTRING *.msi where SOMESTRING is something unique like your ProductName property. Once you know the name of the cached MSI, open it in Orca to get the required attributes. Then put these attributes in a copy of the MSI you have available and try to do an uninstall. No, it's not the exact MSI that you installed but usually it's close enough.
or
Use the front end windows installer cleanup utility (if you still have it) and/or the backend MSIZAP utility to wipe all knowledge of the application from MSI and Add/RemovePrograms. Note, this doesn't actually uninstall the program so you'll have to also write a script or otherwise manually uninstall all traces of the program.
or
Reimage your workstation
If you know exactly what is wrong (which is often the case during development), I prefer to open the MSI file that Windows will use for uninstallation and edit it directly with a tool like Orca to fix or remove the part that causes the failure.
For example:
Locate the MSI file in %WINDIR%\Installer. The MSI should be the last edited MSI file in that folder right after you did the failed uninstallation.
Open the msi file with Orca.
Remove the failing part - for example the InstallExecuteSequence action that fails which is atypical scenario.
Save the msi and close Orca to release the lock on the msi file.
1 - Have you experimented with "run from source" during installation?
This is an option in the feature tree which allows you to run some files from their installation source. This is generally combined with an admin image on the network. See image below. I haven't tried it, but I assume this could cause: "The feature you are trying to use is on a network resource that is unavailable" if the network is down and you are trying to uninstall. Just a theory, there are other ways this could happen.
2 - Are you running script custom actions? If so, do you extract to the tmp folder or run from installed files or the binary table? If so, is the custom action conditioned to run only on install?
3 - Are you perhaps running an EXE custom action that is pointing to an installed file? If so this file may be unreachable on the network.
4 - Are any of your userprofile folders redirected to a network share?
5 - Are you installing anything directly to a folder on the network?
There are plenty of other possibilities.
My installer places a file into /Library/Application Support/AppName. As a final step of the install process in a custom installer plugin (Objective-C code) I check for a more recent version of that file. If it exists, I download it and then attempt to overwrite the one created by the installer. The issue is that I apparently don't have permission to overwrite. Shouldn't the installer plugin that is part of the installer have permission to overwrite that file since the user was prompted for an admin password already?
Any ideas on how I can write to the /Library/Application Support/AppName directory from my installer plugin?
I believe that Installer actually uses a privileged helper tool to do the installation. The Installer app itself doesn't get admin privileges, which is why your plug-in doesn't have admin privileges.
The Apple docs explain one way to handle a privileged installation, although the BetterAuthorizationSample code is the "best" way to do it.
Unfortunately, handling privileged operations is quite tricky and you should study and understand the sample code and the Authorization Services documentation before implementing anything.