S
S
StifleR
2.10
Search
K

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”