what is the difference between /q and /quiet in the case of install params?
example what does the following statement mean.
InstallParams = "/q /norestart"
In theroy, /quiet specifies quiet mode, which means there's no user interaction as you can see in microsoft documentation. Then, /q is used with another letter like /qn or /qb, as you can also see in the documentation.
But at the end /quiet and /q are technically the same. Use /qn if you really want ensure that the user doesn't see anything during installation
/norestart ensures that the MSI doesn't restart the computer automatically at the end of installation, even if it is designed to do so. In that case, you or the user should restart the computer before using whatever component / application was installed.
Equivalence: There are 2 different kinds of command line switches for msiexec.exe. You should be able to mix and match both formats - as long as they don't contradict with their commands.
Legacy Switches: Windows Installer 3.0 and earlier versions contained the msiexec.exe single letter switches such as /x, /i, /qn etc... These switches are still available and working in later versions of the Windows Installer Engine. I still use these switches.
Standard Switches: The Standard Installer Command-Line Options became available in Windows Installer version 3.0 and onwards. Before that time only the old-style command line switches were available. These are the more verbose switches: /quiet, /passive, /norestart, etc...
Your concrete question:
What does this mean: "/q /norestart" -
/norestart here is a more convenient way to suppress reboot after installation. Using the old msiexec.exe command line this would be equivalent to setting the REBOOT property to "ReallySuppress" - which makes for a pretty long and complicated command line, but crucially also a bit more "cryptic" than the more verbose switches:
msiexec.exe /I "MySetup.msi" /L* "D:\msilog.log" REBOOT=ReallySuppress
Rationale: The rational explanation for these 2 different sets of switches is that the original msiexec.exe command line switches are very complex and "complete" - you can do a lot of different things with them and there is very fine-grained control. The Standard Switches - that came later - are simper and takes care of more basic and mundane tasks in a simpler and easier to remember format. Some will find them more convenient and expressive (easier to see what a command line will do). You still need the full, old-style switch repertoire to do more complex configuration.
Old msiexec.exe Tools: There used to be some tools available to help construct complicated msiexec.exe command lines. Most of them are no longer available. Here is a screenshot of one of them (it is no longer available).
Related
Hi, I create a Setup with Installshield 2015. my setup has a prerequisites for reporting viewer so i want to install CR_Runtime13.0.17.msi silently. for this situation we want a command to start the cr_runtime setup silent, after many searches on the net i found this command.
msiexec /i IsSetupPrerequisites\CR_Runtime13\CR_Runtime13.0.17.msi /qb /norestart
when i use this command on Cmd it works well and setup is begins silently with progress bar but when i use this command on installshield, it show me an error and a help every time.
please help me to create a command for installshield to install cr_runtime13.0.17 silently.
at the end i Attached installshield command page and my help to this Question.
Many Thanks to all
The Specify the command line for the application value is really just the arguments. From Specifying Command-Line Parameters for an InstallShield Prerequisite:
Type any valid parameters for the file that is selected in the Specify the application you wish to launch list. Do not include the name of the file in this box.
Remove your inclusion of msiexec and an attempted relative path to the msi, leaving you with just /qb /norestart, and you should avoid the msiexec error. If that one still gives you problems, consider replacing /norestart with REBOOT=ReallySuppress.
I had to create a prerequisite for .net 4.6.1 and it worked silently when I had only /q /norestart in the command line and command line for silent mode.(instead of /qb /norestart)
I am writing a powershell script to uninstall and install a product. Uninstallation and installation process is just clicking on several next buttons with default values populated.
Could you please suggest how to install the MSI file without prompting user for clicking on several next buttons and complete the installation process very quietly.
If I wanted provide customized values during the installation, what could be the process to find out the property names and how to run it silently. Please refer to any references to explore further.
I am using powershell 2.0 and please let me know if further information is needed. Thanks in advance.
Regards,
Kumar
To install a .msi file silently, you should be able to use the /quiet switch with msiexec.
If you need to customize anything, you can set property values like this: PROPERTY=Value
Altogether:
msiexec /i C:\Path\To\File.msi /quiet PROPERTY=Value
To see all the options, just run msiexec without any parameters.
This question is also very similar to yours.
You can do this only if the MSI helps you :). For example, if a property called SERVERNAME is set to FRED in a dialog, then you could say SERVERNAME=FRED on the command line. This assumes that the InstallExecuteSequence that does the work of the install uses just the value FRED. Problems occur when the UI sequence does extra things that won't happen in silent mode because the UI sequence doesn't run in a silent install. If the UI sequence dialogs change SERVERNAME by (for example) adding \ to the front and \MyShare at the end and \FRED\MyShare is used in the execute sequence then you need to know set the command line to SERVERNAME="\FRED\MyShare" because that's what the execute sequence expects. If you don't know all the potential relevant property values you could run the install in UI mode with a verbose log and see them. So in the absence of documentation for silent install you need to reverse engineer it a bit.
If you want to specify what features are to be installed then use ADDLOCAL=comma separated list of feature names.
The basic command line for running silently is (paths truncated):
msiexec.exe /I "C:\WiX.msi" /QN /L*V "C:\msilog.log" MYPROPERTY=1
You can also apply a transform (see explanation below):
msiexec.exe /I "C:\WiX.msi" /QN /L*V "C:\msilog.log" TRANSFORMS="C:\Wix.mst"
/QN: run silently, no GUI during or after the install
/L*V: write verbose log file with all information
MYPROPERTY: set a property at the command line. You can set multiple.
The way an MSI file is supposed to be modified for corporate use is to use a transform file (*.mst).
This is a little "database snippet" that can change the MSI file (which is a database) once applied to it during runtime.
A transform can literally change anything in the MSI, but most often it is used to adjust small things such as removing shortcuts, eliminating undesired runtimes, etc...
A transform is applied to an MSI on the msiexec.exe command line by adding the keyword TRANSFORMS followed by the path to the *.mst file.
You can also uninstall MSI files in a variety of other ways (besides the msiexec.exe command line). Here is a rough guide for how to uninstall MSI files. It includes information on how to uninstall with PowerShell, WMI, VBScript Automation, etc... And there is another post on serverfault.com on the issue of avoiding the use of msiexec.exe to prevent unwanted dialog boxes from popping up during automated runs.
I'm trying to install a driver with a remote framework that lets me run shell commands spawned as children of the remoting/monitoring app on the remote machine, run as cmd /c "command". But the driver refuses to install due to a security feature which thinks the driver may be unsafe.
The driver also has quotes(spaces in path) so its something like
Dim command: command = "\\\\server\\driver\\folder\\Autorun.exe" /passive /norestart";
Set retVal = remote.Shell(command)
which runs
cmd /c " "\\server\driver\folder\Autorun.exe" /passive /norestart"
on the remote machine
I've tried and have had trouble using setx SEE_MASK_NOZONECHECKS 1 /m in a previous statement, I'm guessing that the subprocess don't see new global enviromental variables that weren't around when it's parent started, and won't work without a restart. I'd like to avoid a restart.
I tried running
cmd /c " set SEE_MASK_NOZONECHECKS=1 & "\\server\driver\folder\Autorun.exe" /passive /norestart"
but it doesn't seem to work. Any ideas?
You got a bit lost on the way SEE_MASK_NOZONECHECKS is used. It is not an environment variable and cannot be tinkered with from the command prompt, it is an option for ShellExecuteEx(). A winapi function that you indeed use to start programs. It isn't very clear what programming tools you have access to, using it in a batch file or VBScript isn't going to work. You'd need at least, say, VB.NET and pinvoke the function. You can get the required declarations from the pinvoke.net web site.
Let's talk about what's really going on, you might find a simpler solution. When you download a file from an Internet web site, Windows adds an extra stream to the file that indicates where the file came from. Which basically states "this file did not come from a safe place" and makes the driver installer balky. Which is rather an important feature if you think about it, your user is going to install software that can do a lot, you pretty much have free reign of the machine if you can get a driver installed.
If you right-click the file in Explorer and click Properties then you'll see this at the bottom of the window:
All that's needed is to click that Unblock button. So this is a simple way for your user to solve the problem. You could document the extra step in the install instructions. Also with the advantage that it is now the user that took responsibility of allowing potentially unsafe code to be installed.
Other ways to get the file unblocked is with PowerShell's Unblock-File command and the SysInterals' streams utility, -d option.
And you probably ought to consider the option of writing your own installer. Which will keep the driver packaged in the setup file so it won't be tinkered with by Windows. And the user gets the warning when he starts the installer instead. And it can be signed so the user has some confidence in where the file came from and that it didn't get messed with on its way to his machine. There are many utilities that help you write an installer, like InstallAware, InstallShield, NSIS, etcetera.
I beg to differ to Hans' answer:
Of course, SEE_MASK_NOZONECHECKS is as well a predefined environment variable. Changing it in a process and then starting a child process (e.g. msiexec.exe) which by defaults inherits the environment, has just the same result as using ShellExecuteEx() and providing SEE_MASK_NOZONECHECKS as a parameter to the SHELLEXECUTEINFO structure. The first method is preferred by admins or quick hacks, e.g. if you work with batch or script files which set the environment variable- or when the final call to the .msi file lying on the unsafe network drive is not done by your own code.
For example:
#echo off
set SEE_MASK_NOZONECHECKS=1
call msiexec.exe /i "\\MY_UNC_DRIVE\installs\mysetup.msi /qb /L*v "c:\logs\mysetup.log"
call "\\MY_UNC_DRIVE\installs\Just_another_setup.exe"
If you already use a ShellExecuteEx() in your code, then of course, go with the parameter as Hans mentioned, because this implementation it is more closed. (If you use CreateProcess(), think about using ShellExecuteEx() instead.
Getting back to the environment variable(s). Generally you cannot influence the environment of already started processes. You can set the default environment used by NEW processes by the "setx" command used in the question. But with "setx" you don't change the environment for your current process.This was the problem in question. For this you have to use "set" as shown. So either use both commands after each other or don't use setx at all because for running a setup on foreign machines, it is not clean to make permanent security changes without asking.
For more details on permanent changes/admin point of view, see:
https://superuser.com/questions/595211/removing-the-open-file-security-warning-in-windows-8/934283#934283
Important: As mentioned, there is no general way in Windows to influence processes which already run (only own-defined inter-process-communication maybe), so it is important to set the environment variable before starting the setup to be influenced.
One more thing: Some people think, one must use "SETLOCAL" in a batch file. Normally this is not necessary. Environment changes with "set" are not permanent, and do not incluence "other" processes- they are only inherited to subprocesses and, partly, to superprocesses. But, when the caller on first level ends, the environment is reverted to original state again.
I ended up setting "Launch applications and unsafe files" to enabled for Internet zone in Internet Explorer options under security(custom level) and then exporting the changes from HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3 to a registry file and adding it with regedit /s.
After that I can run the installer of the shared drive.
One of these days I'll pare the registry file down to the minimum I guess.
P.S. I believe this causes IE to default to a warning page on startup.
I believe you need to put everything within the same quotation:
cmd /c "set SEE_MASK_NOZONECHECKS=1 & \\server\driver\folder\Autorun.exe /passive /norestart"
You can try these and see the difference in the output:
cmd /c "echo foo & echo bar"
cmd /c "echo foo" & "echo bar"
When running the InstallShield X debugger I can't find a way to tell it to run silently in order to debug a silent install.
The debugger seems to run the equivalent of a "setup.exe" command line which displays the GUI, but I want "setup.exe /s" which takes input from setup.iss.
Is there a way to specify command line parameters for debugging?
There are multiple ways to start the InstallScript debugger. You can start it from the InstallShield IDE, which is what I expect you're doing. Or you can start it from the command line of your setup with /d. Mix the /s and /d together, and you should be able to debug the silent case. Or if this is an InstallScript MSI, you may also want to set certain MSI properties to enable debugging of custom actions.
See Setup.exe and Update.exe Command-Line Parameters for details, looking at the Debugging section which describes both /d and /v"ISSCRIPTDEBUG=1 ISSCRIPTDEBUGPATH=\"path-to-Setup.dbg\""
To do an unattended installation of any MSI package, one can simply use the following command:
msiexec /qn /i package.msi
However, this triggers an asynchronous installation: if you happen to chain 2 dependent installations, you will have to wait somehow for the 1st installation to complete.
Is there a way to do this from the command line ?
I've had luck with this:
start /wait msiexec /i MyInstaller.msi ...
Found in this blog post from 2005. Hope you found it way back in '08.
We'd run into this a number of times with various products and I'd ended up using a small outer program that launches each msi and waits until it finishes to start the next one. You can probably do this in something as lightweight as a vbscript, but at the time we wanted a bit more gui so we had a larger outer program.