none
MS-WSMV: Running multiple Commands in the context of a single Shell RRS feed

  • Question

  • Hello,

    I'm using MS-WSMV Create operations to create remote shells, and I am the using the Command operation to start a process inside of a shell.  I then use Send and Receive operations to interact with the individual commands.  Once I receive a message indicating that the command has exited, I then proceed to start the next, and so forth.

    This all works beautifully, until I try and start a 16th command.  I get a WS Fault message:

    "The WS-Management service cannot process the request. This user is allowed a maximum number of 15 concurrent operations, which has been exceeded. Close existing operations for this user, or raise the quota for this user."

    So, apparently when these commands exit, they don't simply evaporate.  So, am I supposed to delete commands after they've exited somehow, and if so, using what WS operation?  Is it necessary to send a Signal operation, even though the command has already completed?  Or must I delete the shell original and open a new one?

    Thanks!

    Friday, September 7, 2012 6:11 PM

Answers

  •  Hi David

    The default value of MaxConcurrentOperationsPerUser is set to 15, http://msdn.microsoft.com/en-us/library/f8ba005a-8271-45ec-92cd-43524d39c80f(v=prot.10)#id20, on Win2kR2 server and as you are hitting this threshold; Server is returning fault message.

    Regarding your query “Is it necessary to send a Signal operation, even though the command has already completed?  Or must I delete the shell original and open a new one?” -- Signal command is supposed to release the command state and decrement this MaxConcurrentOperationsPerUser value, which it is not doing for cmd-plugin. Workaround is to either disconnect or create new shell once you receive the done status OR invoke (MaxConcurrentOperationsPerUser-1) commands on the same shell, delete the shell and create a new one to execute subsequent batch. Unfortunately, any session state (environment. variables) will be lost with these approaches.

    Regarding your query “So, am I supposed to delete commands after they've exited somehow, and if so, using what WS operation?” -- WS-Transfer Delete message as specified in section 3.1.4.4 of MS-WSMV specification, http://msdn.microsoft.com/en-us/library/ee878477(v=PROT.10).aspx, should be used to delete command shell.

    Thanks


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Tuesday, September 18, 2012 5:13 PM
  • DerekPierre:

    In reviewing both [MS-WSMV] 3.1.4.15 (which you cited) and 3.1.4.1.31.1, you are correct regarding only CustomRemoteShells can call Disconnect.  A wsman:InternalError fault should result if called by a Text-based shell.

    The purpose of this forum is to support the protocol specifications.  We don’t have a comment regarding if this will be changed in future releases.  The proper avenue to pursue this inquiry would be to open a professional (MSDN or otherwise) support incident and work with a developer support engineer.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, November 15, 2012 9:56 PM
    Moderator

All replies

  • Hi Dave,

    Thank you for your question.  An engineer from the Protocols team will contact you soon.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Saturday, September 8, 2012 4:57 AM
    Moderator
  • Hi Dave

    Thanks for contacting Microsoft Support. I will be assisting you with this inquiry. Can you please send the network trace for analysis to dochelp at microsoft dot com, Attention : Tarun. As you are executing commands synchronously, I feel , you should not hit this error provided you are getting CommandState/Done in response.

    Thanks.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Saturday, September 8, 2012 10:05 AM
  • Alas, I am indeed executing these commands synchronously, and I am getting the exit codes for all of them.  Here's an example of the response SOAP body with the CommandState you're talking about:

    <ns4:ReceiveResponse xmlns:ns2="http://schemas.microsoft.com/wbem/wsman/1/config" xmlns:ns3="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" xmlns:ns4="http://schemas.microsoft.com/wbem/wsman/1/windows/shell" xmlns:ns5="http://www.w3.org/2003/05/soap-envelope" xmlns:ns6="http://schemas.dmtf.org/wbem/wscim/1/common" xmlns:ns7="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" xmlns:ns8="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:ns9="http://schemas.dmtf.org/wbem/wsman/1/cimbinding.xsd" xmlns:ns10="http://www.w3.org/2005/08/addressing" xmlns:ns11="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:ns12="http://schemas.xmlsoap.org/ws/2004/08/eventing" xmlns:ns13="http://schemas.xmlsoap.org/ws/2004/09/transfer">
        <ns4:Stream Name="stdout" CommandId="B8509E99-66FE-4D2A-95BB-40462EB8D2A2">U2VTZWN1cml0eVByaXZpbGVnZQ0KU2VCYWNrdXBQcml2aWxlZ2UNClNlUmVzdG9yZVByaXZpbGVnZQ0KU2VTeXN0ZW10aW1lUHJpdmlsZWdlDQpTZVNodXRkb3duUHJpdmlsZWdlDQpTZVJlbW90ZVNodXRkb3duUHJpdmlsZWdlDQpTZVRha2VPd25lcnNoaXBQcml2aWxlZ2UNClNlRGVidWdQcml2aWxlZ2UNClNlU3lzdGVtRW52aXJvbm1lbnRQcml2aWxlZ2UNClNlU3lzdGVtUHJvZmlsZVByaXZpbGVnZQ0KU2VQcm9maWxlU2luZ2xlUHJvY2Vzc1ByaXZpbGVnZQ0KU2VJbmNyZWFzZUJhc2VQcmlvcml0eVByaXZpbGVnZQ0KU2VMb2FkRHJpdmVyUHJpdmlsZWdlDQpTZUNyZWF0ZVBhZ2VmaWxlUHJpdmlsZWdlDQpTZUluY3JlYXNlUXVvdGFQcml2aWxlZ2UNClNlQ2hhbmdlTm90aWZ5UHJpdmlsZWdlDQpTZVVuZG9ja1ByaXZpbGVnZQ0KU2VNYW5hZ2VWb2x1bWVQcml2aWxlZ2UNClNlSW1wZXJzb25hdGVQcml2aWxlZ2UNClNlQ3JlYXRlR2xvYmFsUHJpdmlsZWdlDQpTZVRpbWVab25lUHJpdmlsZWdlDQpTZUNyZWF0ZVN5bWJvbGljTGlua1ByaXZpbGVnZQ0KU2VJbnRlcmFjdGl2ZUxvZ29uUmlnaHQNClNlTmV0d29ya0xvZ29uUmlnaHQNClNlQmF0Y2hMb2dvblJpZ2h0DQpTZVJlbW90ZUludGVyYWN0aXZlTG9nb25SaWdodA0K</ns4:Stream>
        <ns4:Stream Name="stdout" CommandId="B8509E99-66FE-4D2A-95BB-40462EB8D2A2" End="true"></ns4:Stream>
        <ns4:CommandState CommandId="B8509E99-66FE-4D2A-95BB-40462EB8D2A2" State="http://schemas.microsoft.com/wbem/wsman/1/windows/shell/CommandState/Done">
            <ns4:ExitCode>0</ns4:ExitCode>
        </ns4:CommandState>
    </ns4:ReceiveResponse>

    I'll send you a complete trace illustrating the problem...

    Saturday, September 8, 2012 7:15 PM
  •  Hi David

    The default value of MaxConcurrentOperationsPerUser is set to 15, http://msdn.microsoft.com/en-us/library/f8ba005a-8271-45ec-92cd-43524d39c80f(v=prot.10)#id20, on Win2kR2 server and as you are hitting this threshold; Server is returning fault message.

    Regarding your query “Is it necessary to send a Signal operation, even though the command has already completed?  Or must I delete the shell original and open a new one?” -- Signal command is supposed to release the command state and decrement this MaxConcurrentOperationsPerUser value, which it is not doing for cmd-plugin. Workaround is to either disconnect or create new shell once you receive the done status OR invoke (MaxConcurrentOperationsPerUser-1) commands on the same shell, delete the shell and create a new one to execute subsequent batch. Unfortunately, any session state (environment. variables) will be lost with these approaches.

    Regarding your query “So, am I supposed to delete commands after they've exited somehow, and if so, using what WS operation?” -- WS-Transfer Delete message as specified in section 3.1.4.4 of MS-WSMV specification, http://msdn.microsoft.com/en-us/library/ee878477(v=PROT.10).aspx, should be used to delete command shell.

    Thanks


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Tuesday, September 18, 2012 5:13 PM
  • I am encountering this same issue.

    So as I understand it, since only custom remote shells and not text-based remote cmd shells support the disconnect command, http://msdn.microsoft.com/en-us/library/hh553729%28prot.20%29.aspx, remote cmd shells cannot be reused for subsequent commands without eventually exceeding the MaxConcurrentOperationsPerUser value.

    Is this issue going to be fixed in future releases? Is there a bug number that can be used for tracking this issue?

    Thanks.

    Thursday, November 15, 2012 9:08 PM
  • DerekPierre:

    In reviewing both [MS-WSMV] 3.1.4.15 (which you cited) and 3.1.4.1.31.1, you are correct regarding only CustomRemoteShells can call Disconnect.  A wsman:InternalError fault should result if called by a Text-based shell.

    The purpose of this forum is to support the protocol specifications.  We don’t have a comment regarding if this will be changed in future releases.  The proper avenue to pursue this inquiry would be to open a professional (MSDN or otherwise) support incident and work with a developer support engineer.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Thursday, November 15, 2012 9:56 PM
    Moderator