Remoting breaks on enumeration of IIS pools

This topic contains 5 replies, has 2 voices, and was last updated by  Richard Siddaway 4 years ago.

  • Author
  • #10202



    I have very simple 3 line script which works fine on server console but would fail midstream remotely. Script is below which works fine on console

    Import-Module WebAdministration
    $pools = gci IIS:\\apppools
    PS C:\Windows\system32> $pools | where {$_.workerprocesses.Collection.Count -gt 0} | %{$_.workerprocesses.Collection[0].GetRequests().Collection.Count}



    This script executed remotely throws error below. Same server, same script but it fails seems to be on second iteration which completes fine on console.

    []: PS c:\> $pools | where {$_.workerprocesses.Collection.Count -gt 0} | % {$_.workerProcesses.Collection[0].GetRequests().Collection.Count}
    The connection terminated or is in a bogus state and cannot be used any more. Other connections are still valid.
    (Exception from HRESULT: 0x80010006 (RPC_E_CONNECTION_TERMINATED))
    At line:1 char:65
    + $pools | where {$_.workerprocesses.Collection.Count -gt 0} | % {$_.workerProcess ...
    + ~~~~~~~~~~~~~~~~
    + CategoryInfo : OperationStopped: (:) [], COMException
    + FullyQualifiedErrorId : System.Runtime.InteropServices.COMException

    P.S. Also why RPC is part of this? This is all done via WinRM which I assume HTTP based.

  • #10204

    Richard Siddaway

    A lot of the IIS functionality uses WMI under the covers which is why I think you get the RPC error.

    As to fixing the problem. My initial reaction would be fall back onto the underlying WMI classes and use -Authentication 6 in the Get-WMIObject call

    Unfortunately, the IIS cmdlets don't have a -ComputerName parameter. Have you tried creating a PSSession and using invoke-command rather than interactive remoting?

  • #10206


    Interesting, it does work in PSsession but not in interactive prompt.
    Is there a good explanation how remoting work when winRM is in place? I assume since I rely on WinRM there will be no more dependencies on RPC (WMI) and this will traverse firewalls fine but this seems to be not the case.

  • #10207

    Richard Siddaway

    You are confusing the transport/connectivity mechanism – WinRM
    with work that's being done – possibly WMI in this case

    WinRM provides an HTTP based mechanism for passing data & commands between 2 machines. It doesn't do any work for you. if the commands you are running need WMI, COM or whatever they will still need them even though you are working remotely. Remember that the commands run on the remote machine.

  • #10208


    So when I issue Get-ChildItem IIS:\\ from my prompt on remote machine via WinRM remoting. My machine in fact will make WMI call to remote machine in addition to already established WinRM over HTTP connection? I fully assumed that every command I sent to remote machine via remoting is evaluated and executed on remote machine directly (like if you telnetted into it). It's not the case?

  • #10211

    Richard Siddaway

    When you issue a remote command either interactively, through invoke-command or through a remote session it runs on the remote machine. if its WMI is still needs COM etc.

    Your machine isn't making a WMI call to the remote machine. Its passing the command across WinRM to the remote machine where PowerShell runs it.

    Theres a free ebook on remoting available from the Resources section of this site – I'd recommend reading it to get the full details of how remoting works

You must be logged in to reply to this topic.