I am trying to install an MSI and it is failing the detection method. Is there a way I can install this MSI thru SCCM without a detection method?
The script is very simple to install the MSI is basic:
msiexec /i "\jbocleit\SoftwareInstalls\Worksmart\FrontEnd.msi" /q
I tried to just create a script and run that and that did not do anything. Any thoughts would be great.
There really is no way to do an application without a detection method since that's what triggers an installation.
What are you using for you detection method? If you are using the standard Windows Installer detection make sure you have the proper GUID information
If you REALLY don't want to use a detection method than create a Package instead. You can make it show up in Software Center if you want and in the deployment you can set the set package to only rerun if the installation failed (based on the exit code).
If your MSI deployment is failing on the detection method then I strongly suspect something else is at play. Can you confirm the GUID of the MSI is the same in the Registry and in the MSI Property table?
As Paul G has already mentioned, you could use a package instead if you 'just want it installed'. But since it's an MSI and this functionality is inbuilt into SCCM to handl MSIs, personally, I would resolve the issue.
I hope that helps.
MSI thru SCCM without a detection method?
Deployments without detection method are not possible. But we can make the installation successful, even if the detection failed, by adding the 0x87D00324 code as a success return code to deployment, as in the picture below.
Related
I'm having troubles with some could I would like to execute when the service will be uninstalled. I've added the code to both the System.ServiceProcess.ServiceProcessInstaller BeforeUninstall event, and
to the override method OnBeforeUninstall, but that did not work too.
When using my InstallShield msi to uninstall the service this code does not get executed.
How can I force the service to launch some code during uninstall? Do I need to use a different event in my C# service? Do I need to change something in my MSI?
Note:
My problem is identical to the following
https://community.flexerasoftware.com/showthread.php?149176-MSI-Uninstall-NET-Service-does-not-launch-BeforeUninstall-event
Thanks,
sagar
You'll need to be more explicit about everything you've done. For example there is no automatic calling of installer class methods unless they are explicitly added to your setup as custom actions (in your case an uninstall custom action). You should also explain exactly how the service was installed.
Note that installer classes were invented by Visual Studio setups, and there is typically no need to use them because tools like InstallShield usually support the standard ServiceInstall and ServiceControl functionality in Windows Installer. Installer classes are unnecessary. Also, those events are Visual Studio specials, and it's not clear to me if InstallShield supports them. If you are using an Uninstall method to uninstall a service then just add your "before" code to before the Base.Uninstall() call.
If you want code to run when the service is uninstalled, the more usual way is to have a custom action that calls your code, and condition the call on REMOVE="ALL" (for an uninstall) or other conditions depending on your exact requirement. For example, if you do an upgrade MSI to upgrade your existing product do you still want to run that uninstall code?
.NET Installer Class: PhilDW has already said it all, but I just want to add a couple of things. I assume you are using System.Configuration.Install.Installer and the ServiceProcessInstaller Class (there is a sample in the Installshield help file). There used to be (and I think there still is) a flag for each Installshield component called .NET Installer Class. You can set this flag to Yes, and then I believe Installshield itself will take care of running your installer class methods (Install, Commit, Rollback, Uninstall - whichever one is implemented I think, but I have never tested all scenarios. I don't use this feature).
InstallUtil.exe: Running InstallUtil.exe would indeed call these methods. I am not sure how Installshield calls the methods under the hood (during setup execution) - they may actually be calling InstallUtil.exe for all I know, or some more low-level API call.
Conclusion: Just go to the components view and click on the component containing your service.exe file - and set the flag mentioned above. The exe must be a key-file for the component in question - and it must be a .NET assembly. Like PhilDW wrote, I wouldn't use these methods since they are intended to be used during service development only - not during deployment. For one thing you could run into runtime errors when the methods try to run faulting your whole setup (and often unnecessarily so), and there are also likely issues with rollback and potentially other problems. Can we ask what the methods are actually doing? Perhaps you are just deleting some log files? There are other ways to do that - most significantly using the RemoveFile table.
I have created my application's setup in installshield - basic MSI project...
Now when i am installing it, it allows me to run .exe multiple times simultanious...
Please let me know, how can i stop it.....
There is already a safe guard automatically built-into Windows Installer. If two or more of your installs actually try to install only the first one will install. The others will throw a message saying another install is already in progress. This is enforced by the _msiexecute mutex.
If you want to gate the situation earlier, you'll have to write your own custom actions to create your own custom mutex, tear it down when the install is complete and check for it when starting the install. However, I'd mark this problem as Functions as Designed and move on.
I have asked this exact question on the Flexara forum, but got no response up to today, so I want to ask it here.
We currently have a InstallScript project which runs fine. The resulting setup can be made unattended/silent fine.
In this setup we have some features and invoke a number of third-party installations (that are a prerequisite for running our software).
However, we have customers that want an MSI file and therefore we resorted to the Basic MSI project type.
The setup is made without too much hassle (I'm fairly new to InstallShield) and I can generate a .exe and .msi from this project.
However the only issue I have left is invoking one of the third-party installers.
That third-party installer (made with NSIS) on its turn invokes another installer which is MSI based.
This results in having error 1500 - the fact that you cannot run a msi type installation while another is running.
I've tried scheduling the CA (that are used to invoke the third-party installers) as the first action and as last, but no success.
Before resorting on the more unorthodox scenarios (like creating a task on Windows Task manager that runs after our installer finishes, or at the next reboot and forcing a reboot - which our customers don't like) or a scenario that we don't bundle the 'faulting' installer (we really like to be able to hand over a single intaller and not multiple), I'd thought I ask your input.
I've tried searching for solutions everywhere on the internet, but either I'm failing due to wrong keywords or I just didn't stumble on the right post yet.
Are there any options left for us to create a single MSI installer that is able to invoke this third-party installer (which invokes a msi installer on its turn)?
Since an EXE bootstrapper is not acceptable, there is only one solution:
store the prerequisite installers in Binary table of your MSI
create some custom actions which extract them from this table and launch them
schedule them in InstallUISequence, for example right before Progress dialog
use searches to detect if the prerequisites are installed or not
condition your custom actions with the search results
Basically, you need to launch them during the installation UI. It won't work if you launch them during InstallExecuteSequence.
I don't think the basic MSI project supports this, but it may be supported by more advanced project types. Other setup authoring tools offer direct support for this.
You can try InstallShield's "Chained .msi Package" feature.
Our product has several products that customer can install created as separate installation packages (MSI).
We have a requirement to have single package for the installation that will:
Show one UI with progress
Allow user to choose which features/packages to install
Have ability to constrain one feature to another (e.g removing or adding effect other)
Support single elevation (UAC)
nice to have ability to auto update (not must)
support command line + silent installation
the package should be built out of the isolated installations (chain them)
raise error / messages for missing prerequisites
Support patches over time and major upgrades
Today we do almost all of the above using MSI with nested installations which is bad practice and we face too many issues in our solution.
i know that there are several bootstrappers out there (m$ generic bootstrapper which i think is not good, BURN is the WIX version which is not mature enough)
Do you know of other? that work and tested already ?
What is the best method to do (without unification of the MSI into a single MSI)
dotNetInstaller looks promising. I was experimenting with it to install java as a prerequisite. It comes with a GUI editor so you don't have to sort out the xml to create a project. The config file is in xml, and the InstallerLinker can be run from the command line. It could be integrated with a build server, though some msbuild tasks would be nice.
project home:
http://dotnetinstaller.codeplex.com/
tutorial:
http://www.codeproject.com/KB/install/dotNetInstaller.aspx
Create an InstallShield InstallScript package. Use the InstallScript package kick off the .MSIs with "-qn" one by one. I do this and am successful with it. I believe it meets your all the requirements you listed.
Until Wix's Burn is ready we really don't have much of a choice when it comes to bootstrappers.
If you are using InstallShield as your msi designer, one thing you could try is making an InstallScript project that contains all the different msi packages. You could then silently install only the desired packages. InstallShield is pretty expensive though, so if you don't already have it, you'll probably have to end up rolling your own bootstrapper.
Much searching has lead me to find several descriptions of how to create a bootstrapping msi, but these solutions all assume the msi is local or a standard Windows component. Is there a way to make an msi that downloads an installer (which is also an msi) with normal MSI or Wix code rather than by having the bootstrapper execute some non-native program to do so?
My experience with msi's has been it's not possible to run 2 at the same time. (could be wrong though)
What I ended up doing was to instead make an installer exe using Inno Setup (http://www.jrsoftware.org) and ISTool (http://www.istool.org) which downloads and installs the various msi's. With ISTool it's very easy to do.
I know it's not as chic or sexy as Wix, but it worked for me very well.
I would create a custom action that runs in the InstallUISequence. This would download the MSI if necessary (to the source folder), and then try to launch it as a nested installation.
Windows prevents two installs from being in the InstallExecuteSequence at the same time, so if you're looking for a silent install solution with a bootstrapper, you're SOL.
However you can start another install from the UI sequence, which is probably an OK solution as long as you advise your customers that certain other dependencies must be installed first if they're going to deploy via group policy or some other 'silent' method.
If it helps, I'm pretty sure you can also call MSIEXEC with a URL, eg. msiexec.exe /i http://some.domain/blah.msi /passive
I would suggest that you write a native app and have it run the first msi and then run the seccons msi. I wrote a blog on how to do this. Here is a link (http://blog.foldertrack.com/?p=45)