my application needs SQL Compact SP1 and SP2 installed (Entity Framework), but there is nothing on MSDN where I can determine silent install parameters for those two files (SSCERuntime-ENU-x86.msi for SP1 and SSCERuntime-ENU.exe for SP2). And on top of that, 64bit SP1 needs to be installed like this: install x86 file and then install x64 file on 64bit machine. Any thoughts appreciated.
OK, I've figured that out myself - all you need is to take these install files, run CMD and run them with wrong parameter, for example: C:\SSCERuntime-ENU-x86.msi -myAwesomeFlag. Because of course given parameter will not be found, install process displays MessageBox with a list of all possible parameters and their options. This works for both servicepacks and .NET 4 installation package.
Generally speaking .msi install parameters are normalised compared to .exe (which can be anything the developper choose). I recommend using this command with those parameters for silent install: msiexec /i SSCERuntime_x86-ENU.msi /qn /norestart
q is for quiet
n is for No UI
norestart ensure that the computer doesn't reboot right now, this is useful if you deploy software with tools like SCCM, Chocolatey, etc. Otherwise if the software needs a reboot it will reboot the computer and if a user is working on it he will not be really happy ;)
Related
I am trying to install a piece of software that when done manually has configuration options you can choose from when going through the process. I am trying to figure out a way to automate this using powershell but am stuck as to how I can set those configuration options. I believe I would need to run the start-process command on the installer .exe but I don't know where to go from there. Can I use the parameters on the start-process command to pass in the configurations I want?
UPDATE: Several links towards the bottom with information on how to handle installation, configuration and file extraction for setup.exe files.
UPDATE: See Windows Installer PowerShell Module on github.com (scroll down for description, use releases tab for download). I haven't really tested it much, but it is from Heath Stewart - Microsoft Senior Software Engineer (github).
I had a quick look for that installer, but didn't find it easily. Essentially the installer is either a Windows Installer database (MSI) or something else - generally a setup.exe of some kind. An MSI database can also be wrapped in a setup.exe.
You should be aware that for legacy style installers a common practice for large scale deployment is to capture the legacy install with an application repackager tool, and then compile an MSI file to use for installation (effectively converting an installer from an old format to modern MSI format). This is a specialist task requiring good understanding of Windows and setups. It is generally done in large corporations for very large software distributions. If you are in a large company there might be a team dedicated to packaging software like the one you mention. Maybe check with your management. If the setup is an MSI the same team can also modify that for you according to your specifications.
With regards to your installer EXE. Try to run setup.exe /a from the command line and see if you get an option to extract files to a "network install point" (administrative install). Then you are dealing with an MSI file wrapped in a setup.exe. If that doesn't work you can try setup.exe /x or setup.exe /extract as well.
Windows Installer has built-in features to allow you to customize the install via PUBLIC properties (uppercase) set at the command line or applied via a transform (Windows Installer's mechanism to apply substantial changes to the vendor file - it is a partial database that gets applied to the installation database from the vendor at runtime).
Non-MSI, legacy installer technologies generally have fewer reliable ways to customize the installation settings, and they tend to be rather ad hoc when they are there. In particular the silent running and uninstall may be features that are missing or poorly executed. These installs are generally all wrapped in EXE format, and there are many tools used to generate them - each with their own quirks and features.
In other words, it all depends on what the installer is implemented as. Give that setup.exe /a a go, and update your answer with new information for us (don't add too many comments - we will check back).
With regards to using PowerShell. I haven't used PowerShell for deployment so far to be perfectly honest. Here is a basic description of how to install using PowerShell: https://kevinmarquette.github.io/2016-10-21-powershell-installing-msi-files/
You can also invoke automation for MSI files from PowerShell, I don't think this is relevant for what you asked, but here is a quick link for modifying a transform file: http://www.itninja.com/question/ps-how-to-edit-a-mst-file.
The normal way to install MSI files is via Window's built-in msiexec.exe command line. The basic msiexec.exe command line to install software is:
msiexec.exe /I "C:\Your.msi" /QN /L*V "C:\msilog.log" TRANSFORMS="C:\1031.mst;C:\My.mst"
Quick Parameter Explanation:
/I = run install sequence
/QN = run completely silently
/L*V "C:\msilog.log" = verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst (see below).
What is a transform? Explained here: How to make better use of MSI files.
Advanced Installer has a general page on msiexec.exe command lines. And here is Microsoft's msiexec.exe documentation on MSDN.
Some links:
Perhaps see Michael Urman's answer here: Programmatically extract contents of InstallShield setup.exe. This is for Installshield packaged EXE files only.
Installshield setup.exe commands (general reference with some sample command lines - towards the end of the document it looks like the command lines are not correct, but the first ones look ok. The later ones are pretty obscure anyway - just thought I'd let you know since I link to it). Here is the official Installshield help documentation.
Wise setup.exe commands - Wise is no longer available, but if the setup is older it can still be packaged with Wise.
Advanced Installer standard command line. For this tool setups can apparently be extracted with setup.exe /x or setup.exe /extract. See the link for full list.
There was also a "silent switch finder" tool used to find hidden switches in exe files (for deployment), but it failed a virustotal.com scan so I won't link to it. Maybe it is using something exotic, such as scanning a file's header at a bit level or something weird that is flagged as malware by mistake? Either way, not a tool I would use.
And finally: http://unattended.sourceforge.net/installers.php. This link isn't bad, it presents some of the tools above and a few others - and the most common switches used. Untested by me, but looks ok.
And there are other deployment tools that have their own way of packaging and delivering EXE files - it can be a jungle. I can provide a list of such tools with more links, but maybe that's just confusing. Please try what is provided above first.
Here is a generic answer that might be helpful as well: Extract MSI from EXE
As some of you have seen, I'm a newbie with Chef, and there seems just so much to learn that it's hurting my head :(...
One of the things I ran into earlier testing was that some example recipes I found would fail because I am using Win2K8 as the NODE and that has Powershell V2 rather than Powershell V3.
So, as a kind of learning exercise, I would like to try to make a Chef cookbook to deploy PS V3 to Win2K8 R2. I think that I'll also need to get .NET Framework 4.5.x in order to install the PS V3 .msu (Windows6.1-KB2506143-x64.msu).
So, how do I make such a cookbook?
i've been looking around and found a dotnetframework cookbook and I've added that to my WORKSTATION.
I've also found this:
http://thinkofdata.blogspot.com/2014/07/installing-microsoft-net-framework.html
which seems like a different approach than using the dotnetframework cookbook?
I guess I'm confused about all of this? Are both of these approaches (using the dotnetframework cookbook vs. the one from the link above) "ok"?
Also, if I want to do the former, how do I actually do that? What do I need to put into my recipes/default.rb?
Finally, for now at least, what about executing the .msu after that, to do the PS V3 upgrade? How do I do that?
Sorry for all the questions (and hopefully I won't get flamed too much for them). I'll continue to bang away but hopefully you all can help point the way!
Thanks in advance,
Jim
You could use the windows_package command to be able to do this slightly differently (and not have to rely on a file download to determine whether or not something was installed on a box), but then you would have a dependency on the windows cookbook. This will work after downloading the Chef Development Kit and just using:
chef-apply install_powershell_4_0.rb
This also installs powershell 4.0 via the Windows Management Framework 4.0 installer rather than powershell 3.0 (which is why .NET framework 4.5 needs to be installed prior to installing WMF 4.0 because otherwise powershell isn't updated and stays at 2.0).
The server will reboot 3 times between each install, so you will have to run the chef-apply command to continue (or actually install chef client).
Here is the install_powershell_4_0.rb file:
#Create installs directory to house downloads
directory 'c:/installs' do
end
#Install Windows 7 and Windows Server 2008 R2 Service Pack 1 (KB976932)
remote_file "c:/installs/windows6.1-KB976932-X64.exe" do
source "http://download.microsoft.com/download/0/A/F/0AFB5316-3062-494A-AB78-7FB0D4461357/windows6.1-KB976932-X64.exe"
end
execute "c:/installs/windows6.1-KB976932-X64.exe /quiet" do
action :nothing
subscribes :run, resources(:remote_file => "c:/installs/windows6.1-KB976932-X64.exe")
end
#Install .NET 4.5
remote_file "c:/installs/dotNetFx45_Full_setup.exe" do
source "http://download.microsoft.com/download/B/A/4/BA4A7E71-2906-4B2D-A0E1-80CF16844F5F/dotNetFx45_Full_setup.exe"
end
execute "c:/installs/dotNetFx45_Full_setup.exe /quiet" do
action :nothing
subscribes :run, resources(:remote_file => "c:/installs/dotNetFx45_Full_setup.exe")
end
#Install Windows Management Framework 4.0
remote_file "c:/installs/Windows6.1-KB2819745-x64-MultiPkg.msu" do
source "http://download.microsoft.com/download/3/D/6/3D61D262-8549-4769-A660-230B67E15B25/Windows6.1-KB2819745-x64-MultiPkg.msu"
end
execute "c:/installs/Windows6.1-KB2819745-x64-MultiPkg.msu /quiet" do
action :nothing
subscribes :run, resources(:remote_file => "c:/installs/Windows6.1-KB2819745-x64-MultiPkg.msu")
end
You then should be able to open a powershell command prompt and see 4.0 as the PSVersion via running:
$psversiontable
I use WiX 3.7 to write an installer, and I will install a c# system service will try to reinstall the software, using msiexec -x {product_code} -quiet. My OS is Win8
I first install the software through UI, and after a while, the service will create a new process and start to call msiexec, but it failed.
Could you help me on this? I have been struggling for a long time!
Thanks very much!
I have logs as follows:
MSI (s) (7C:80) [00:22:01:708]: Warning: The package code in the cached package 'C:\windows\Installer\134f7d5.msi' does not match the registered package code. Cached
MSI (s) (7C:80) [00:22:01:724]: SOURCEMGMT: Source is invalid due to client source out of sync (product code is the same).
What account is the service and thus the new process running under? Default accounts (e.g. LocalSystem) might not have rights to access the msi information.
That message means that a package is installed with the same ProductCode (set via the Product/#Id attribute) but is not the same package. This usually happens if you install a package, rebuild it (so the new package gets a new "package code") then try to uninstall with the rebuilt package. It can also happen if something is causing source resolution during uninstall and the Windows Installer finds the newly rebuilt package in the place where it expects the old package.
To get unstuck, try re-cache/reinstalling with the newer package then uninstalling:
msiexec /fv path\to\your.msi /l*v install.txt /qb
msiexec /x path\to\your.msi /l*v uninstall.txt /qb
After that, test your scenarios again without changing the MSI in between the updates. You'll slowly be able to track down what is changing in your system that is getting the Windows Installer confused and unhappy.
Good luck!
I'm trying to setup a large number of build agents and so far i can install all the dependencies silently (using powershell, nuget and chocolatey).
However i cannot install the tool IlMerge without the damn GUI popping up.
Ive tried all the usual msiexec switches and they are just ignored. does anyone know of a way of getting this tool on a box in an unattended way?
Or should i just repack the thing in zip/msi?
This is on windows server 2008 R2
If i run
Invoke-Expression "msiexec $installerPath\ilmerge.msi /passive"
I still get a security dialog.
Currently i'm just thinking ill do this:
Copy-Item x:\installs\ilmerge.exe "C:\Program Files (x86)\ILMerge"
seeing as its only one file.
Below worked for me, no security dialogs.
cp ILMerge.msi \\Server\admin$
winrs -r:Server ILMerge.msi /passive
dir "\\Server\C$\Program Files (x86)\Microsoft\ILMerge"
With chocolatey you would have just needed to specify -ia '/quiet' as the package was not silent by default. This was specified by the tag notSilent and it was also in the description (http://chocolatey.org/packages/ilmerge/2.11.1103.1).
The latest package is just the executable, so you can just install it. http://chocolatey.org/packages/ilmerge
I have always wondered about this. So many application setups have a zip file that you unzip, and in it are a bunch of files, among other things an exe and an msi. What is the difference? They are often even about the same size. I am never really sure which one to execute, sometimes I do the exe and sometimes the msi, and it usually works with either one. But does one of them do anything that the other doesn't do? And if not, isn't it kind of a waste having two files that does the same thing? Especially when thinking about download size, etc...
Not sure if this should be here or on ServerFault, or maybe neither, but I figured since developers usually are the ones creating setup files, then developers might know why this is like it is =)
In the case where you have both exe and the msi the exe is just a loader for the msi. If you have an installation supporting multiple languages then the exe applies a language transform (mst) on the msi before installing.
You can consider the exe as a wrapper around the msi. The msi file may or may not be given separately. The reason why people give the msi file too is to facilitate a group policy installation (in a Windows Active Directory infrastructure) as you can only push down installations of msi files and not exes.
The setup.exe is a wrapper for the MSI, but it is not only a wrapper.
The setup.exe can rely on a setup.ini to define parameters
The setup.exe checks for the Windows Installer (a MSI cannot be installed otherwise)
The setup.exe can check for frameworks, like the .NET framework. The developer can pick one of those defined in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages (for Visual Studio 2008). If it is lacking, it will try to download it from http://www.microsoft.com/
The setup.exe can be reconfigured with msistuff.exe
The actual installation is done in the MSI. As Prashast said, the exe is just a wrapper, but the reason for having the exe, is that an exe is allways possible to run. If the user do not have MS Installer installed on the computer, or his version of MS Installer is older than the version required by your installation, then the MSI file is not possible to run.
The exe provides automatic installation of MS Installer (including some question to the user if he/she wants to do this) before running the MSI file. In most cases, the install packages needed for Microsoft Installer is included inside the setup.exe, or sometimes it is just the prerequisites check with a link to download the installation from Microsoft.
In very basic words,
you can deliver just the .msi file and it will install. but .exe will not work without the .msi