Comment on page
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.
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.
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=TestThere 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”
Last modified 3mo ago