StifleR WMI Provider
Last updated
Last updated
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.
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
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”
