-1

I want to push MSI installer with parameter using SCCM server. i.e.

msiexec.exe /i "setup.msi" INSTALLFOLDER="SpecifiedInstallationLocation" CONFIGFILE="FileName"

Can I use parameter name defined by me or I have to use specific parameter name in command line? Is any specific format to pass parameter? Can I able to pass parameter to MSI installer?

If I use same command in batch file then it will works properly.

Heikki
  • 2,150
  • 14
  • 27
Maulik
  • 25
  • 1
  • 5
  • Maulik, I added an entry on [**SecureCustomProperties**](https://msdn.microsoft.com/en-us/library/windows/desktop/aa371571(v=vs.85).aspx) that you should probably be aware of. Please see below. – Stein Åsmul Dec 13 '17 at 08:53
  • you go some pretty good answers here already but as you said it works in a batch file, I kinda figure you know about the parameters and are just confused why something that works is not working via sccm. In general parameters belong in the command line field of you program. If you want to use relative paths like in your example you will need to distribute your content to a distribution point that is available for wherever you want to deploy you program. Maybe something went wrong there? – Syberdoor Dec 14 '17 at 15:04
  • Another question is what context the install runs in? [User or system context](https://social.technet.microsoft.com/Forums/en-US/75b9dc8f-5fcb-43a6-8fe4-a812acef3e68/what-is-the-security-context-when-deploying-application-using-sccm-2012?forum=configmanagerapps)? – Stein Åsmul Dec 16 '17 at 12:27
  • @SteinÅsmul its a user context to install. – Maulik Dec 18 '17 at 06:04

3 Answers3

1

You can set two general types of properties on an msiexec.exe command line:

  1. The public properties listed here, public meaning uppercase. https://msdn.microsoft.com/en-us/library/windows/desktop/aa370905(v=vs.85).aspx

In reality there aren't all that many that can be usefully set.

  1. The public properties that the install was designed to accept when it was designed. For example, if the installer has a UI that accepts a textbox value property name SERVERTHING, then the install should be designed to accept SERVERTHING on the command line in a silent install. Depending on the directory names used, other popular choices are INSTALLFOLDER or TARGETDIR to set the default main application folder. So if that install was designed to expect CONFIGFILE to be set on the command line it should work, but it's the same as running a program and giving it a bunch of arguments: if the program isn't coded to deal with them then they have no effect.
PhilDW
  • 19,260
  • 1
  • 14
  • 23
0

In general questions about SCCM or corporate deployment tools may be better answered on the StackExchange system administrator site serverfault.com. Deployment is a crucial part of development.

However, please do try to make questions as clear and specific as possible in the future, and give serverfault.com a go for topics such as this.


In addition to Phil's advice: When pushing packages out via SCCM you are not just restricted to setting properties on the command line as you indicate, you can also use transforms to configure just about anything you want in the original MSI file. Transforms are just database fragments (change sets) applied to the original MSI at install time.

Setting command line parameters (uppercase PUBLIC properties) is the "light weight" way to configure the install of MSI files. You can only set the properties exposed and defined by the MSI file itself (you can't "invent" your own parameters as you ask). Transforms are the "heavy weight" way to configure MSI packages - you can basically change anything you want in the whole package (generally used for corporate deployment).

There is a longer description of setting properties and using transforms here: How to make better use of MSI files. Maybe have a quick skim, might be helpful. I think it is at least better than the above description.

The process of finding the configurable PUBLIC properties for each MSI generally involves opening the MSI and checking the Property table. Most of the time the property will be listed there, but it also happens that a property is defined only in the GUI dialogs (indicates a poorly designed MSI). You can inspect all of this using an MSI file viewer such as Orca (or another, third party tool). A vendor's web page may also contain instructions on how to deploy their MSI silently in a corporate environment. Shooting them an email and asking them for info is often a good idea. There may be configuration options you are not aware of. I used to provide a one page "Large Scale Deployment" guide in PDF format for my setups back in the day.

A particular road block is the fact that some MSI files are badly designed and don't work properly when run in silent mode (when the entire GUI is skipped - which is what SCCM does). Resolving these design errors in MSI files can be a huge headache. It is not impossible that this is the cause of the problems you are seeing. You can find some information on this issue here: Uninstall from Control Panel is different from Remove from .msi.

So in summary:

  • You can find configurable PUBLIC properties in the MSI in the Property table and sometimes in the setup GUI dialogs (properties set by GUI input or changes).
  • Only UPPERCASE PUBLIC PROPERTIES can be set at the msiexec.exe command line.
  • To further complicate things there is a special property which defines a list of public properties that are allowed to pass to deferred (silent) install mode in secure environments(managed installation with elevated privileges - an AD setting): SecureCustomProperties. As a rule of thumb, add any properties you set at the command line to this list of secure properties using a transform. This is particularly true if you see installation problems if you haven't done so (and your network is managed - a domain featuring elevated rights during installation).
  • You can not meaningfully define new parameters on your own and set them on the command line, but you can use transforms to change pretty much whatever you want in the original MSI if you know how to. Generally this requires expert MSI knowledge to do successfully (application repackagers / setup developers).
  • Contacting the application / setup vendor for information on silent deployment is always a good idea. They may have a single page document that will solve all your problems.
  • Some MSI files have design flaws that cause a faulty install when run silently. Typically this involves setups that perform installation tasks only in the setup GUI sequence (which is skipped when the setup is run silently - this is a very serious MSI design error, but all too common).

Verbose and a bit messy, but I hope this advice and Phil's advise will help you achieve what you want.

halfer
  • 18,701
  • 13
  • 79
  • 158
Stein Åsmul
  • 34,628
  • 23
  • 78
  • 140
0

Will be better if you used MST instead of parameters. But if you can't make this, then SCCM fully support for public property. Just put whole command inside "Installation Program" You have already there part of msiexec command, be default SCCM will add "/q" for quite installation. Only be aware to focus of quotation marks if your property value has spaces.

Adam
  • 52
  • 3