Suppose you have an MSI that's trying to add or replace file Foo.bar, and that operation fails. If Foo.bar is marked as vital (with msidbFileAttributesVital) in the File table of the MSI, then the installation will roll back. If the file is not vital, then the user is prompted and allowed to decide if the error should be ignored or if the installation should be rolled back.
What if the operation fails and the installer is running in silent mode (/qn)? The user cannot be prompted.
It appears (from an MSI log I have) that the installation rolls back, even though the file is not vital. Is there some way to have a silent install proceed in this case?
From my knowledge silent installations always rollback if an error is encountered, no matter what flags and settings you use. This prevents broken installations (for example missing files).
In your case a solution is to use basic UI to prompt the user. Another solution is to use a non-MSI installer which can ignore installation errors.
Related
When a non-admin user tries to install setup.exe it should throw the below error message as per our Installshield condition.
"You did not log on as Administrator or have required permissions to install "
But recently when we tried to install setup as non-admin it didn't throw any error. When Setup.exe is executed, nothing happens.
Condition:
AdminUser AND Privileged : message -> You did not log on as Administrator or have required permissions to install
Initially we thought some windows update could have caused the issue. But when I created a sample setup.exe it throws the error. How to identify why my setup.exe stopped to throw the error message.
Note : No file generated in %temp% folder when running setup.exe. If we double click or, giving Run as Admin nothing happens. Also Requires Administrative Privileges is given Yes.
While the AdminUser and Privileged properties used to tell you what you're asking for, they were altered for the introduction of UAC. The theory is that in most cases a Windows Installer package would elevate in the InstallExecute phase, while its UI would be run as a limited user. Since this wasn't typically done before UAC (though it was possible with advertisement), Microsoft altered the behavior of these properties for better backwards compatibility.
There is a way to request the original meaning of these properties: set MSIUSEREALADMINDETECTION to 1.
However, if you rely on this to prevent installation, you're not doing things the way Microsoft expects you to do them. You should instead fix whatever's broken when your installation is not launched with full admin privileges, and then you can remove your check. If there's already nothing broken, then just remove the check. Windows Installer will only install as a limited user if you specifically enable it by your authoring. (See ALLUSERS, MSIINSTALLPERUSER, and the rest of Single Package Authoring for the more recent approach, or, before that, bit 3 of the Word Count Summary property, which when set to the typical 0 requires elevation.)
As far as logging goes, setup.exe and Windows Installer will only log if requested, either by command line, authoring, or policy. Use the command line (elevated or otherwise, depending on which scenario you want to test), and run something like this: setup.exe /debuglog /v"/l*v c:\users\me\desktop\setup.log"
I am trying to install a installer developed using InstallShield 2008. While installing after selecting the destination path i am aborting the installation.
When i try to install again by default it is taking the destination path as previously given path which was provided before aborting the installation.
And also it is not allowing me to install in different path.
For Example:
*Step1 : Installation starts
Step2: Destination path as C:\Installer
Step3: Click next and abort installation
Step4: Start the installation again
Step5: Provide Different destination path as C:\Installer1*
Here installation is failed. Because destination is still pointing to Step2
My question is from where Installer is taking the old path.?
Persisted Path: The technicalities appear to be relatively straightforward: the old path is read back either from the registry or from disk each time the setup is launched, and a custom action in the setup's GUI sequence must have persisted the path "somewhere" during the first run (this is erroneous design, see technical comment below). Reading back the value can be done by using AppSearch (built-in MSI feature) or by means of a custom action.
Registry / Disk: As to finding where the value is read from. The easiest would be to just search the registry first for the literal path. Just open regedit.exe and search for the path there. You can also look for the custom action that does the persisting (or the AppSearch or custom action that does the retrieval) and see if it is a script with code you can see - then you should be able to see where it has persisted the path. Use Orca or a similar tool to view the Custom Action table. The custom action can also be compiled and undecipherable. Do you have the setup source? The path can also be persisted to disk, but the registry is most commonly used. Remember to search both HKCU and HKLM.
Involved Debugging: I can't see why you would, but it is also possible to use ProcMon.exe to monitor what registry locations your MSI reads and / or writes to. This is involved debugging and should never be needed for something this simple. Just mentioning it as a technical option. Generally the last resort we have to figure out the strangest problems.
Technical Comment: MSI setups are not supposed to write anything to the registry or disk from the setup's user interface sequence (setup dialogs). All changes should be made from the installation sequence (InstallExecuteSequence) which also generally runs with elevated rights - the user interface normally runs with user rights. This InstallExecuteSequence sequence is kicked off from the last dialog in the GUI sequence, and runs the file copy and system change operations. Control then returns to the GUI sequence to show the setup complete dialogs. It is also possible to run the setup silently, in which case the InstallUISequence never runs and all custom actions inserted there fail to run. Accordingly custom actions should be present in the InstallExecuteSequence as well as the InstallUISequence if they are to run in silent mode. This potential design flaw is a very common silent deployment error which occurs when setups are not designed properly for silent running. Remember that all corporate deployment runs silently. Setup GUI is highly overrated (in my opinion - a "fact" that could change in the future).
It is still possible for an MSI setup to write to the registry or disk from the InstallUISequence by using a custom action to do so. Such a custom action would normally not have access to write to HKLM or to protected parts of the disk - unless the whole setup runs elevated because it was launched from an elevated command prompt (for example), or launched by an admin who elevates it via the UAC prompt.
In other words: this setup is badly designed, but I guess that is clear already.
Our application is deployed to the target machine with an msi file. All works nicely. Our tester has gone through his plan, and one of the tests requires deleting the application's configuration file. The application is designed to alert the user with a dialog on startup saying "missing config". However, what happens is that - somehow! - the software starts the installer again and retrieves the missing file from the msi! Which is nice, but not what we want. How do we disable that behaviour?
without going into much depth of the windows installer mechanics (if you interested in that there a plenty of articles about this), the shortcut of the software is probably advertised, which means the windows installer checks if everything is in its place before the software is started.
if you can edit the msi, make the shortcut non advertised.
if you can't, install it with DISABLEADVTSHORTCUTS
e.g. msiexec /i myMsi.msi DISABLEADVTSHORTCUTS=1
please note that this is only a quick (and dirty) workaround,
to fix this proper you need to understand the whole windows installer advertising (also called repair or self resiliency) mechanism.
but explaining all the causes and the mechanism of the repair is far beyond this answer and there are quite some articles and posts about that on the internet (and especially on MSDN and stackoverflow)
There is a more correct answer to this, and it is NOT DISABLEADVTSHORTCUTS. You set the component id to null in the MSI file to prevent repair of that individual file. See ComponentId comments here:
http://msdn.microsoft.com/en-us/library/aa368007(v=vs.85).aspx
Edit the MSI file with Orca to delete the Componenty ID, and write an uninstall custom action to delete the file at uninstall if it's there.
In addition, that's a redundant test. Windows will restore that file for you if it's missing, so the idea that you need a test to notify that it's missing is pointless. The true test should be that Windows will restore the file if it's lost, and your app needs to do potentially nothing about the missing file.
You don't mention what tool you are using to make your MSI but I'm going to go out on a limb and guess Visual Studio Deployment Projects (.VDRPOJ).
One of the (many) horrible things about this tool was that it fails to expose the foundational concept of components. Instead it makes every file a key file of it's own component and hides the existence of the component from you. I say 'was' because Microsoft killed this project type in VS. There are around 50k people complaining on UserVoice to bring this tool back and I'm guessing that 49,990 of them don't know what a key path is.
Windows Installer has a concept called the component rules and each component has a keypath. The keypath teaches MSI how to handle repair scenarios. But your tool has to allow you to be able to control this to make it work.
Windows Installer is functioning exactly the way it's supposed to function. You just aren't up to speed on what that is.
However, if you want to ignore Windows Installer best practices and continue using the tool you use today, the trick is to install the app.config file as a different file. Then have the application copy the file to the real file name on run. Windows Installer won't service what it didn't install.
Several answers have been provided that can work:
You can install the file with a blank guid. Then you need to remove it on uninstall using the RemoveFile feature. You will also run into issues if you want to replace it during an upgrade. Could be tricky at times.
You can disable the advertised shortcut(s), but this affects too much in my opinion.
Finally you can use my suggestion to install a separate non-advertised shortcut to use to launch the application. Such a shortcut bypasses the self-repair check. It may still be invoked by other means such as missing file associations, COM registration or similar, but those are exception states.
However, my preference is that an application can start without a config file present, if at all possible. I always suggest a good startup routine with "internal defaults" available. The startup routine should also degrade gracefully if faced with any file system access denied conditions.
Most importantly you should place this config file in the userprofile so you can generate the file on first launch for the user in question. It can even be copied from a read-only copy in the main installation directory.
When you generate a file from internal defaults and put it in a userprofile location, the file will have no interference with Windows Installer at all. The issues that results is how to clean up user data on uninstall. I discussed this with Stefan Kruger (MSI MVP) at one point, and I agree with his notion that user data is indeed user data and should not be automatically dealt with by your installer at all. Leave it installed, and clean it up via system administrator tools if necessary - for example logon scripts.
I created a MSI package with visual studio. It works fine for 80% of the users (some have errors with privileges and the like), but for two users the installation fails with the error message:
The feature you are trying to use is on a network resource that is unavailable
Which I find very odd because all the MSI does is set some registry values and put an OCX control into the system. Nothing with any network devices or anything else.
It also refers to a install[1].msi (when the actual MSI is called install.msi) which it supposedly can't find, which is obvious, because such a file never existed and is neither required for the installation nor even referenced in it in any way.
The package tries to locate this non-existent other package under C:\Documents and Settings\XYZ\Local Settings\Temporary Internet Files\Content.IE5\M84S9GA4\, even though I started the MSI out of the local drive D:.
How can I resolve this / get closer the underlying cause?
A verbose log file should show you the exact error causing the issue. If it doesn't happen consistently, you'll probably be best served turning on the logging policy to get a log file all the time and when it repros, grab the log file really quick.
Alternatively, if you have a repro situation you can get a log file immediately by doing:
msiexec /i path\to\your.msi /l*v install.txt
As for the root cause, the fact that that the name is install[1].msi makes it sound like the MSI was downloaded using a web browser and launched out of the browser cache. The Windows Installer is very particular about the name of the MSI, you can read about that in an old blog entry of mine. The end result is that shipping a 'naked' MSI on the internet is never a good idea. Maybe you're seeing these errors when shipping a newer MSI? If so, that would make a lot of sense.
A verbose log file will show you for sure.
When trying to remove our application in Add/Remove Programs, the following error pops up, and the application fails to uninstall:
Error
'mFileBagIDE.dll' is not a valid short file name.
The curious thing is that you only get this error if the original installation DVD is not in the drive. If the DVD is in the drive, the uninstall works perfectly.
Here's the real kicker: we did not catch this bug until after our application was already widely deployed, and our clients' situations are such that it is likely many of them no longer have their original DVD. This means that the next version's installer (doing a windows installer major upgrade) will fail because it is unable to first remove the previous version.
So, my question is twofold:
What did we do to create this problem so we can avoid it in future releases?
Is there a way to tell our next windows installer to ignore this error and go ahead and remove the previous version?
Our current installer (the one that is causing problems) was generated using InstallAware. We're likely moving to WiX. But solutions in any platform (InstallAware, WiX, raw MSI tables) are appreciated!
UPDATE: I have the following row in both the InstallExecuteSequence and InstallUISequence tables in my MSI, which may very well be relevant, but I have no idea what the SRCDIREX property is, or where it is being set.
| Action | Condition |
|---------------|--------------|
| ResolveSource | NOT SRCDIREX |
Probably one of the actions (either standard or custom) that references the original MSI was not conditioned to run on installation only (for example, ResolveSource should be conditioned as "Not INSTALLED"). You might be able to workaround this with a patch (an MSP file) that changes the condition on the relevant action.
I would start by determining which action is causing the error. Here's how I would do that:
Install your app from the dvd
copy the msi file to some local folder, let's say "c:\temp"
Remove the dvd
kick off the uninstall like this: "msiexec /x yourapp.msi /L*v c:\temp\uninst.log"
When the error comes up, the uninstall is effectively paused. You can then check the end of the log to see exactly where you are in the sequence. That should help you to debug.
If the answer really is ResolveSource, regular patching may not be an option.
Heath Stewart mentions this in his blog -
http://blogs.msdn.com/heaths/archive/2007/10/25/resolvesource-requires-source.aspx
"In general, do not schedule ResolveSource. If this runs when installing a patch, for example, the user will have to insert the original media whether they would otherwise need to or not."
If that's the position you find yourself in, you could create a transform that updates the condition on your ResolveSource action, and apply that to the cached copy of the msi file manually. It's a bit of a pain, but I'm pretty sure that would work.
have you tried to copy those files to %WinDir%/system32 folder?
EDIT: Make a setup to copy all the setup MSI package to the disk, and install it from the diskdrive.
Remove every files uneeded to uninstaller. Adobe, HP and many other companys are doing that.