StifleR WMI Provider

Windows Management Instrumentation (WMI) is a Command and Control (C&C) infrastructure that is integrated within Windows. It provides three primary capabilities:

• Exposing state information regarding a configurable entity

• Invoking control methods on a configurable entity

• Publishing events from a configurable entity

These facilities are a complete instrumentation solution for any Windows application, and multiple system components expose information through the use of WMI providers. This information can be consumed from a multitude of languages and technologies by WMI consumers, using a standard query language (WQL).

The StifleR server interface for automation is a WMI Provider In practical terms this means the administrator uses a WMI interface to communicate and control the StifleR server component.

The primary advantage to using WMI in favour of other communication technologies that abound is that WMI is a standardized C&C mechanism which can be consumed by numerous existing C&C frameworks. Most Windows components expose C&C information using WMI, and it is preferable that a single C&C framework is used instead of reinventing a C&C framework for each individual component. This makes a single C&C tool suitable for a variety of configurable and controllable entities.

Most automation of StifleR is done through the StifleR WMI Provider. This is present under the \\ROOT\StifleR WMI namespace on the StifleR server itself.

Updating Values

StifleR is a multithreaded asynchronous service, which means that the changes done through WMI cannot be guaranteed. A change might return the original value and not the changed value, so keep this in mind when scripting against StifleR. If the returned value does not match the value that you are attempting to write it has not been successful and will have to be retried.

After creating or making configuration changes, you should check to ensure that the value you to set has been changed to what is actually running. Some values are checked as part of the function to ensure that the change was successful and will return a failure if not. But some simple value changes have to be verified, as the underlying code runs asynchronously and on multiple threads in order to maximize performance.

The reason StifleR has been designed to work this way is because the internal workings are running on multiple threads asynchronously which may or may not have write access to the internal data structures at any given time. Rather than waiting for a lock to be lifted, using precious resources, the data is flushed to free resources. This allows StifleR to support an extreme large number of simultaneous connections.

For example, if you are trying to set the TargetBandwidth for a Location, make sure that there is a check for the running value after the Set command and make sure that the value has in fact been updated.

Listing Method and Instance Parameters

Using WMI with the CALL and GET /? parameters will give the following outputs:
C:\>wmic /namespace:\\root\stifler path StifleREngine CALL /?
Method execution operations.
USAGE:
CALL <method name> [<actual paramlist>]
NOTE: <actual paramlist> ::= <actual param> | <actual param>,  <actual paramlist> 
The following verb(s)/method(s) are available:

Call	[ In/Out ]Params&type	Status
GetErrorDescription	[IN ]errorcode(uint32) [OUT]ReturnValue(string)	Implemented
GetErrorDescriptionFromString	[IN ]hexcode(string) [OUT]ReturnValue(string)	Implemented
ModifyJobs	[IN ]action(string) [IN ]force(boolean) [IN ]jobName(string) [IN ]StifleRTypeName(string) [IN ]Target(string) [OUT]ReturnValue(string)	Implemented
Notify	[IN ]messageLine1(string) [IN ]messageLine2(string) [IN ]messageLine3(string) [IN ]picturePath(string) [IN ]Target(string) [OUT]ReturnValue(string)	Implemented
RunCmdLine	[IN ]arguments(string) [IN ]fileName(string) [IN ]Target(string) [OUT]ReturnValue(string)	Implemented
RunPowerShellScript	[IN ]script(string) [IN ]Target(string) [OUT]ReturnValue(string)	Implemented
TestFunction	[OUT]ReturnValue(string)	Implemented
UpdateRules	[IN ]fileUrl(string) [IN ]Target(string) [IN ]useBits(boolean) [OUT]ReturnValue(string)	Implemented
UpdateServerList	[IN ]reconnect(boolean) [IN ]ServerList(string) [IN ]Target(string) [OUT]ReturnValue(string)	Implemented
WOL	[IN ]MAC(string) [IN ]Target(string) [OUT]ReturnValue(string)	Implemented

C:\Windows\system32>wmic /namespace:\root\stifler path StifleREngine GET /?
 Property get operations. 
USAGE: 
GET [<property list>] [<get switches>]
NOTE: <property list> ::= <property name> | <property name>,  <property list> 
The following properties are available:

Property	Type	Operation
ActiveBlueLeaders	sint32	Read
ActiveNetworks	sint32	Read
ActiveRedLeaders	sint32	Read
ClientInfoCompleted	sint64	Read
ClientInfoInitiated	sint64	Read
Clients	sint32	Read
Company	string	Read
ConnectedUser	string	Read
Contact	string
DataEngineThreadState	string	Read
ExpiryDate	datetime	Read
HubConnectionCompleted	sint64	Read
HubConnectionInitiated	sint64	Read
Id	sint32	Read
JobReporDeltatInitiated	sint64	Read
JobReportCompleted	sint64	Read
JobReportDeltaCompleted	sint64	Read
JobReportInitiated	sint64	Read
LicensedVersion	string	Read
Licensee	string	Read
ListAccess	array of string	Read
Nodes	uint64	Read
NumberOfClients	sint32	Read
RedLeaderRunInfo	string	Read
RedLeaderSelectionThread	string	Read
Type	string	Read
ValidFor	string	Read
Version	string	Read

Some properties will be listed as Operation “Write” which means you can use the SET verb to write to them. To find all items that allows Write, replace GET /? with SET /?.

An example how to use the SET operator

wmic /namespace:\\root\stifler path Subnets.SubnetID="192.168.90.44" SET Description=Test

Further Reading

There used to be a large section in this document devoted to WMI with screen shots and tables explaining each setting in detail. The good news is that this information still exists on the 2Pint Support KB site which you can view if you search for ”StifleR WMIC Command Line Tool”