I would like to override the default powershell scripts that come with win_chocolatey module of Ansible. How do I do that?
In my case, I am trying to override the ChocolateyInstall.ps1 that comes with MsSqlServerManagementStudio2014Express. I would like to pass a few more parameters such as system administrator password and instance names during the silent installation of MsSQLServer.
I have tried giving these additional parameters with "install_args" and "params" options in win_chocolatey module call in my ansible playbook. But there are no handlers written in MsSqlServerManagementStudio2014Express's powershell scripts to include them during silent installation.
Package Parameters vs Install Arguments
Install Arguments (--install-arguments option for choco.exe) are completely invisible to the packaging, and they are appended to the current set of silent arguments in the package. One can also override them completely with --override-arguments. In the commercial editions of Chocolatey, you can also pass --install-arguments-sensitive to keep secrets out of logs.
Package Parameters (--package-parameters|--params) are different, can be used with anything related to packaging (not just for the installer), but must also be present in the packaging itself. For commercial editions and secrets, you also have --package-parameters-sensitive.
Option 1: Community Repository Packages
You would need to ensure that the package is using Install-ChocolateyPackage, Install-ChocolateyInstallPackage, or other built-in methods to know that install arguments can be used with the package. If you need parameters, you will need to work with the maintainers of the package to get those implemented.
Option 2: Use Your Own Packages
If you are using Chocolatey in an organization, you will want to use your own package you store somewhere internally. That guarantees much more reliability and repeatability, something that is instrumental to organizational use of anything.
Plus you can bake installers directly into the package as you are not subject to distribution rights internally, providing an even more reliable experience.
It is especially helpful to read over and understand this when planning for Chocolatey in an organization: https://chocolatey.org/docs/community-packages-disclaimer
Related
I am trying to install DB2 ibm data server client(version 11.1), silent install in my windows server. i am using response file for the installation. I gave the path in response file to install in D drive, but still it is installing in C drive only. the command i was using is: msiexec /i "MSI path" /q /l*v "log file path" RSP_FILE_PATH="response file path".
Check the following:
Installing Db2 products and features using a response
Some notes on MSI customization in general below.
And a link to the most commonly used library of packaging tips contributed by packagers:
https://www.itninja.com/software-library/company/ibm
Different Designs: The exact mechanism used to redirect a folder like that depends on the design of the application and the setup from the vendor, they often do something very non-standard so reverse engineering their solution fully or slightly is usually neccessary.
Itninja.com: Maybe have a look if you can find the software here in the itninja.com "software tips" section: https://www.itninja.com/software-library/company/ibm - this is a collection of comments people have made who have packaged and deployed the software in question - either unsuccessfully or successfully. I can't really tell what the exact product name is, please check.
Download: If you have a download link that is publicly accessible I can have a quick look at the MSI to determine how it is set up. Please be aware that it is much better to install an MSI directly via normal configuration mechanisms (setting public properties and / or creating a transform - sample here) than to run a setup.exe with response file (which sometimes is the only possibility depending on the overall deployment design).
How to make better use of MSI files
A couple of quick overviews:
How to parameterize msi file from electron builder
MSI Repackaging - free tool
And some further links for reference:
Change the value of a MSI property loaded from a DLL using a MSI transform
How to run an installation in /silent mode with adjusted settings
I have a large win32 program consisting of a mixture of native and managed code.
I would like to put it into a single .Appx file for simple installation on Windows 10. I don't want to put it in the Windows Store - I simply want to replace the old installer with an .Appx file.
Using the DesktopAppConverter I have converted the program to an .Appx.
My problem is that the DesktopAppConverter adds a dependency on 'Microsoft.VCLibs.140.00.UWPDesktop' which means that I have to distribute both my .appx and Microsoft.VCLibs.x64.14.00.Desktop.appx. So the user can no longer just click my .appx file but has to run this from PowerShell:
Add-AppxPackage .\MyApp.appx -DependencyPath .\Microsoft.VCLibs.x64.14.00.Desktop.appx
Is there a way that I can "merge" the dependency into a single .appx that the user can just double click to install?
Microsoft documents support for appx bundles, you could try that.
Another option, more risky, would be to assume that such a dependency is already present on the machine (it is quite common so it might be installed by other packages from the store). In this case you can edit your appx package and remove the dependency from it.
Advanced Installer can import appx packages and provide an easy to use GUI to edit their content, with just a few clicks you can remove/add your dependencies.
Advanced Installer UWP support - dedicated GUI editor for package contents, convert from old MSI/EXE to UWP, create UWP and WSA packages...
Disclaimer: I am part of the team building Advanced Installer over the last 14 years.
Ok, I'm out of my element but here goes anyway.
I need to do a silent install of a vendor supplied windows program. The vendor supplied an MSI file to use with the install. I created a bat file to run msiexec that contains the following line:
msiexec /i "C:\archibussilent\afm\ARCHIBUS 19.msi" /L*V C:\archibussilent\log\msi_SETUP.log
When I execute the bat file an error dialog pops up that says:
"This installation cannot be run by directly launching the MSI package. You must run setup.exe"
and the msiexe error log says:
MSI (c) (80:B0) [15:48:02:588]: Note: 1: 1729
MSI (c) (80:B0) [15:48:02:589]: Product: ARCHIBUS 19 -- Configuration failed.
MSI (c) (80:B0) [15:48:02:590]: Windows Installer reconfigured the product. Product Name: ARCHIBUS 19. Product Version: 19.3.30032.003. Product Language: 1033. Manufacturer: ARCHIBUS, Inc.. Reconfiguration success or error status: 1603.
The error # is 1603 which implies a permissions problem but I've checked the access privileges and don't see any problem.
Is it true that I can't run msiexe without running Setup.exe?
Any help is appreciated - Thanks.
The "you must run setup.exe" is a vendor authored requirement not specific to MSI in general. They may have had a good reason for it or they may have just authored it as a gate check to not have to test other scenarios.
You'll have to edit the MSI with ORCA and look at the LaunchCondition and InstallExecuteSequence tables to figure out how they implemented. Then you can create a transform to bypass the check or possible pass a property in such as SETUPEXEDRIVEN=1 to simulate being called from setup.exe. (One particularly large and well known installer development product passes this into their MSI when you create a setup.exe with it.)
The setup.exe may be serving a purpose. For example it might be authored with a manifest requiring elevation or it might be downloading and installing prerequisites or possible making sure the MSI is cached in a given location for future installation transactions.
Also I assume you want to add a /QB or /QN to make the install go silent. You'll like also need to have already elevated the cmd session prior to calling since MSI doesn't support UAC prompts when installing silently.
This is most likely an Installscript MSI file made using Installshield. This is a non-standard MSI file featuring more advanced GUI and a few other advantages. In my opinion this is a particularly problematic type of setup due to a few serious bugs without suitable workarounds. I consistently recommend this project type to never be used. It is especially problematic for corporate deployment.
These setups feature a number of command line parameters for the setup.exe file. As Chris states you can probably run it via a transform and set the property SETUPEXEDRIVEN=1 and you may try to use setup.exe /a to run an admin install (More info: purpose of an admin install). This will extract all cab files (if any) from the MSI and put the files on a "network installation location" for use in corporate networks - essentially a smaller MSI with the setup files next to it. I have seen setups that then will allow to be run directly from the MSI - just give that a shot too.
As to the reason why these setups require setup.exe to launch:
In prior editions of Installshield the Installscript language runtime had to be installed prior to launching an Installscript based MSI. This appears to no longer be the case since Installscript is now run without a runtime.
The setup.exe is there to install any updates to the Windows Installer Engine (msiexec.exe), and for that to be possible a setup.exe launcher is needed. Such an update is rarely required, and should today be done via Windows Update.
A number of legacy features, such as being able to access the Internet (!) via the setup.exe (highly undesirable for corporate use), download runtimes and components and extract temporary files are also done via the setup.exe.
And there are other features too, most of which are undesirable for corporate deployment.
Here is a previous answer from me on a similar issue featuring a link to a PDF with actual sample command lines.
For Linux packages, specifically RPMs with stored checksums, we always can check two things: the contents of package is ok and the installation from this package is ok. When someone modifies parts of the installation he shouldn't, we can see it by running rpm -Vp my-precious-package. In our busyness it is not only recommended, but obligatory to provide our packages with tools for this purpose and for Linux these are just simple bash scripts.
Now I have to do something similar for Windows. Basically what I want is to provide some batch file by running which one can get assured, the installation is the same as it meant to be in the package. I'm using InstallShield for packaging, and yet it has some great visual tools, I still haven't found a way to verify package checksums in the command line.
Is it even possible, or should I reinvent the wheel writing my own checking utils?
Take a look at MakeCat and SignTool from Microsoft, both in SDK
http://msdn.microsoft.com/en-us/library/windows/desktop/aa386967%28v=vs.85%29.aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa387764%28v=vs.85%29.aspx
Windows Installer has a feature called resiliency that supports auto repair of products and there are ways to call it for self checks only. (This is assuming by InstallShield you mean Windows Installer based projects.)
Here's a couple links to read to get you started:
INFO: Description of Resiliency in Windows Installer
Resiliency
Application Resiliency: Unlock the Hidden Features of Windows Installer
MsiProvideComponent function (See dwInstallMode flags)
This also assumes all files are key files. Companion files are not managed by the installer. Also changes performed by custom actions outside of the installer aren't managed.
If I add the RX-main package to a WPF application I get the following dependent packages installed:
Rx-Interfaces
Rx-Core
Rx-Linq
Rx-PlatformServices
Rx-Main
After adding Rx-main there are two additional packages related to WPF that can be installed
Rx-XAML
Rx-WPF
Rx-Xaml is dependent on Rx-Main, and Rx-WPF is dependent on Rx-Xaml. However both of these packages add a reference to System.Reactive.Windows.Threading. What if anything is the difference between them, and why are there two separate packages that add a reference to the same assembly?
Also, do I need to add either or both to be able to use RX in WPF?
I actually know the answer to this, as the former owner of the Rx-Xaml package. It used to be that there were only Rx-Silverlight and Rx-WPF. This made it difficult to create packages like ReactiveUI, since they had a dependency on one or the other depending on which platform you're using.
So, I created Rx-Xaml, which was literally just a merging of Rx-Silverlight and Rx-WPF. However, the Rx team realized that having separate packages was silly, and asked me if they could take over the name for themselves. I gladly obliged, and now Rx-Xaml is the package you should be using. Rx-Xaml since 2.0 is owned by Microsoft.
tl;dr: Use Rx-Xaml, ignore Rx-WPF and Rx-Silverlight, they're old and busted.
From what I see using NuGet Package Explorer, neither Rx-WPF not Rx-Silverlight include any DLL of their own (or any other file, as a matter of fact) in their respective nupkg files. Therefore they seem to function only as a container for Rx-Xaml. My guess is that you should still point to Rx-WPF since the Rx team might start adding specific logic to it which would not be contained in the base Rx-Xaml package.