How to Use WMIC to Install Software Remotely

WMI tools are installed by default and include the following components:

• Wmimgmt.msc is an MMC snap-in that allows you to manage the WMI system on a selected computer.
• Winmgmt.exe is a WMI management console tool. Performs similar actions as the MMC wmimgmt.msc console. In addition, Windows 2000 is an executable WMI service file on the system. To start from the console it is used with the /exe option (winmgmt.exe /exe). Starting with Windows XP, the WMI executable is the wmisvc.dll library, which is loaded using the svchost.exe host controller (Generic Host Process for Win32 Services). In Windows 7-10, winmgmt.exe allows you to configure the WMI service for both the SVChost group under the name netsvcs and for a separate group called Winmgmt. In Windows 10, the grouping of services launched using svchost.exe is practically not used — most services have their own svchost.exe process.
• Wbemtest.exe is a graphical utility for interactive work with WMI. Convenient for testing classes and methods, viewing properties, etc.
• Wmic.exe — a console utility for calling WMI objects and methods (WMI Console) — is present only in Windows XP and later versions of Windows.
• Mofcomp.exe is a compiler of MOF files. It is used to expand the WMI repository and fine operations with the WMI class library, as well as to detect and fix repository data errors.

The main WMI data directory for a standard Windows installation is C: \ Windows \ System32 \ wbem.

Although WMIC instructions can be provided with appropriate credentials before starting work, it is usually recommended avoiding clear-text typing the password(who looks over his shoulder;)). We will execute the runas command as follows:

runas /user:DomainAdminAccount@DOMAIN cmd
that will ask us for the credentials of our DomainAdminAccount. In the case of successful authentication, we will get a shell running on behalf of the administrator.

One of the nice advantages of WMIC is that it can work from any machine. With our admin shell, we’re going to type wmic and then push Enter button. (Note: we could go to WMIC directly from the runas command … it just breaks the steps).

The main problem is that individual MSI packages will have different “options”. To simplify our example, we perform an installation with MSI, which does not require any options. We will enter the setup call as shown below. We’ll enter the installation call like the following:

> /node:exampleremotemachine product call install true,“” , “c:\PathToYour\File.msi”

If we do not enter a wmic invalid node, we will be asked to confirm in the following format:

Execute (Win32_Product)⇨Install() (Y/N)?

To which we must answer yes (y) to confirm. If your WMI compliant MSI package was successfully installed, you should see something like the following:

Method execution successful.

Out Parameters:

instance of __PARAMETERS

{

ReturnValue = 0;
}

We will use the WMIC feature to process the flat text file as input to the nodes to perform this installation on the list of machines (in our example, stored on the local administrator’s hard disk in C: \ computers.txt) by running the following command:

> /node::@“c:\computers.txt” product call install true,“” , “c:\PathToYour\File.msi

Which will iterate through the list in computers.txt… skipping over invalid nodes (eg: the machine is turned off), and asking for installation confirmation for each machine.

Although there is an opinion about the rather scant wmic documentation, most of the users are sufficient instructions on the official Microsoft site to deploy software or to create wmic list installed software.