Share via

3.2.4.2.3 Executing WMI Operations with PowerShell Semantics

  • Article

The WS-Management Protocol can be used to execute operations on CIM resources that support certain PowerShell semantics. These semantics are associated with PowerShell Remoting Protocol messages, as given in the following table, and are documented in [MS-PSRP].

PowerShell Semantic

Associated Message

Verbose

VERBOSE_RECORD

Debug

DEBUG_RECORD

WarningAction

WARNING_RECORD

ErrorAction

ERROR_RECORD

Confirm

PIPELINE_HOST_CALL

Progress

PROGRESS_RECORD

CIM resources can support one or more PowerShell semantics. Further, these extended semantics are grouped into categories according to their effect on input, output, and server-side processing.

Category

Semantics

Options that create additional server output

  • Verbose

  • Debug

  • WarningAction (Continue)

  • ErrorAction (Continue)

  • Progress

Options that modify execution on the server but do not require additional input

  • WarningAction (Stop)

  • ErrorAction (Stop)

Options that require additional input from the client.

  • WarningAction (Inquire)

  • ErrorAction (Inquire)

  • Confirm

For options that only create additional server output, the message flow is as follows. Although the Verbose option triggers the largest amount of additional output, the overall pattern of messages is the same for all options that only create additional server output. In the following diagram, "[C1]" indicates that the messages are transmitted on the primary HTTP connection.

Message sequence for options that create additional server output

Figure 9: Message sequence for options that create additional server output

  1. The client sends the CIM Operation Request message with the Verbose option specified.

  2. The server returns the verbose output in SOAP Response messages, as output is generated by the CIM operation.

  3. The server sends the CIM Operation Response message as it normally would in the absence of the Verbose option.

For operations that modify server execution but do not require additional client input, the pattern is as follows.

  1. The client sends the CIM Operation Request message, with the appropriate option specified, on the primary HTTP connection.

  2. The server returns any generated output in SOAP Response messages, as output is generated by the CIM operation, on the primary HTTP connection.

  3. The server returns the CIM Operation Response message that is the response to the original CIM Operation Request message.

For operations that require additional client input, the message sequence is as follows. The optional Confirm option triggers the exchange of a pair of Confirm Request and Confirm Response messages, but otherwise, the pattern of messages is the same for all options in this category. In the following diagram, [C1] and [C2] indicate that messages are transmitted on the primary and secondary HTTP connections, respectively.

Message sequence for options that require additional client input

Figure 10: Message sequence for options that require additional client input

  1. The client sends the CIM Operation Request message, with the Confirm option specified.

  2. The server returns the Confirm request in SOAP Response message.

  3. The client sends an acknowledgment of the Confirm request on a secondary connection. Any additional input to this operation from the client will also be transmitted over the secondary connection.

  4. The server returns the CIM Operation Response message that is the response to the original CIM Operation Request message.