Revisiting Test-Port using a PowerShell workflow

I’ve been using the Test-Port code provided by Boe Prox that you can find in the script gallery on this page: http://gallery.technet.microsoft.com/scriptcenter/97119ed6-6fb2-446d-98d8-32d823867131

Instead of testing first if a computer replies to an ICMP request and then testing with the built-in cmdlet Test-WSMan if the powershell remoting is working, I prefer to kill two birds with one stone. Before showing how, let me mention a few interesting links on this topic:

I prefer to test if the TCP port 5985 (default PS remoting port) is opened because you can actually reduce the timeout when it fails.
And, as I previously said, when it succeeds, it also means that a remote computer is present on the network and that its firewall configuration allows you to reach its WinRM (Windows Remote Management) service.

Workflow Test-TCPPort {            
 param(            
    [parameter(mandatory)]            
    [string[]]$ComputerName,            
            
    [parameter()]            
    [ValidateRange(1,65535)]            
    [int]$Timeout=1000,            
            
    [parameter()]            
    [ValidateRange(1,65535)]            
    [int]$Port=5985            
)            
    ForEach -parallel ($Computer in $ComputerName){            
        Sequence {            
            $obj = Inlinescript {            
            
                #Reset             
                $Open = $false            
            
                #Create object for connecting to port on computer              
                $tcpobject = New-Object -TypeName System.Net.Sockets.TcpClient              
                                
                #Connect to remote machine's port                            
                $connect = $tcpobject.BeginConnect($using:Computer,$using:Port,$null,$null)              
            
                #Configure a timeout before quitting              
                $wait = $connect.AsyncWaitHandle.WaitOne($using:Timeout,$false)              
                                
                #If timeout              
                If(!$wait)            
                {              
                    $tcpobject.Close()              
                    $Result = "Timed Out"              
                } Else {              
                    try {            
                        $tcpobject.EndConnect($connect) | out-Null              
                        $Open = $true            
                        $Result = 'Success'            
                    } catch {            
                        $Result = "Error"            
                    }            
                    $tcpobject.Close()              
                }            
                New-Object -TypeName PSObject -Property @{            
                    Computer = $using:Computer            
                    Port = $using:Port            
                    Opened = $Open            
                    Result = $Result            
                }            
            }            
            $obj            
        }            
    }            
} # end of workflow

NB: the timeout value represents milliseconds. I don’t remember why I’ve set an upper limit. Anyway 65585 milliseconds equals to 65.585 seconds which should be enough in most use cases of this workflow.
PS: Powershell workflows have been introduced in Powershell Version 3.0 -> Get the ‘Windows Management Framework 3.0’

Advertisements

2 thoughts on “Revisiting Test-Port using a PowerShell workflow

  1. Hi Karl,

    You’re right, if you haven’t changed the default workflow session limits. Powershell.exe is executed if the workflow was launched locally. If you execute the same workflow on remote computers, the hosting process is wsmprovhost.exe (PSComputerName parameter of the workflow).

    Default configuration can be viewed like this:
    Get-PSSessionConfiguration Microsoft.Powershell.Workflow | fl *

    Workflow design and testing are also important. In my environment each parallel powershell.exe process used by the workflow consumes about 50MB of RAM. It’s not a problem as it runs on VM where dynamic memory has been configured.

    If I broaden the scope of your comment, it actually raises the question about choosing the right balance between workflow options and the hardware resources it will consume. It has to been well designed and tested before going into production.

    I’d recommend reading at least the following pages about workflow session options:
    New-PSWorkflowExecutionOption http://technet.microsoft.com/library/hh849862.aspx
    http://blogs.msdn.com/b/powershell/archive/2012/06/15/high-level-architecture-of-windows-powershell-workflow-part-1.aspx
    http://blogs.msdn.com/b/powershell/archive/2012/06/19/high-level-architecture-of-windows-powershell-workflow-part-2.aspx

    For this particular case of testing ports, I’d also say that it shouldn’t be too aggressive, as other parts on the network may not support it. I mean some security related feature of network routers, an intrusion detection system (IDS), a super network aware client host antivirus,..

    /Emin

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s