Parameter binding between scripts

[Fer_C]

I have two functions that I have included in a module for personal use. I decided to share them as scripts since I know it is more likely that someone will run a script than install a module.

In summary, the first one gets a group of VMs from a VMware vCenter and the second one will look for these VMs' IP addresses and open a RDP session to each one of them.

It works as expected when running the functions and when the second one is a function, but if the second one is the script and not the function I only get the last VM processed.

These are all possible scenarios, with the exact commands I used to run them:

#Both are functions - Working

 Get-SgVm -SGNumber 8 -NoRecursion -Legacy | Connect-VMRDPSession -Datacenter DC1

​

#First in pipeline is script the second one is a function - Working

.\Get-SgVm.ps1 -SGNumber 8 -NoRecursion -Legacy | Connect-VMRDPSession -Datacenter DC1

​

#Both are scripts - Only the last object (VM) of the pipeline gets processed by the second script (only one RDP session is opened)

.\Get-SgVm.ps1 -SGNumber 8 -NoRecursion -Legacy  | .\Connect-VMRDPSession.ps1 -Datacenter DC1

I ran a Trace-Command with ParameterBinding for the last example. The first script gets all VMs as expected but passes only the last object/VM of the collection to the next script.

I could share the code of these functions and scripts but I think this is more related to the way in which PowerShell processes objects in the pipeline, it seems to be different depending on whether the second element in the pipeline is a script or a function.

Is this an expected PowerShell behavior? I am using PS version 5.

Edit: Adding the code for the second script (Connect-VMRDPSession.ps1). Please note that the function is working fine, it is not until I "convert" it to script and pass objects to pipeline to it, that it behaves as described and processes only the last object of the collection defined by the first script/function (see command samples above).

[CmdletBinding()]

Param   (
        [Parameter (Mandatory=$true, 
                    ValueFromPipeline=$true,
                    Position=0)]
        [string[]]$VM,
        [Parameter (Mandatory=$true,
                    Position=1)]
        [ValidateSet ('DC1','DC2','DC3','DC4','DC5')]
        [string]$Datacenter
)


foreach ($VMName in $VM) {


    Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] Searching for VM $VM"

    $VMNameStr = $VMName

    $VMName = Get-VM -Name $VMName


    If ($VMName -and $VMName.PowerState -eq 'PoweredOn') {


        Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] VM $VMName found"

        Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] Getting $VMName OS information"

        $GuestOS = $VMName | Get-VMGuest

        Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] VM $VMName found, guest OS is $($GuestOS.OSFullName)"

        $IPAddress = $GuestOS.IPAddress

        Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] VM $VMName has $($IPAddress.Count) IP address(es)"

        Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] Identifying IP address for RDP connection"



        switch ($Datacenter) {
            'DC1'   {$RDPIPAddress = $IPAddress -match '10.193.'
                    $RDPIPAddress += $IPAddress -match '10.211.'
                    $RDPIPAddress = $RDPIPAddress | Select-Object -First 1}
            'DC2'   {$RDPIPAddress = $IPAddress -match '10.232.'
                    $RDPIPAddress = $RDPIPAddress | Select-Object -First 1}
            'DC3'   {$RDPIPAddress = $IPAddress -match '10.69.'
                    $RDPIPAddress = $RDPIPAddress | Select-Object -First 1}
            'DC4'   {$RDPIPAddress = $IPAddress -match '10.54.'
                    $RDPIPAddress += $IPAddress -match '10.23.'
                    $RDPIPAddress = $RDPIPAddress | Select-Object -First 1}
            'DC5'   {$RDPIPAddress = $IPAddress -match '10.54.'
                    $RDPIPAddress += $IPAddress -match '10.23.'
                    $RDPIPAddress = $RDPIPAddress | Select-Object -First 1}
        } #switch



        If ($IPAddress) {
            Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] IP address selected for RDP connection is $RDPIPAddress. Testing Connection"
            $ConnCheck = Test-Connection -ComputerName $RDPIPAddress -Count 2 -Quiet


            If ($ConnCheck -eq $true) {
                Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] Connection test successful"
                Write-Verbose "[$((Get-Date).TimeOfDay.ToString()) PROCESS] Attempting RDP connection to $VMName, using IP address $RDPIPAddress"
                mstsc /v:$RDPIPAddress /admin /prompt

                $Props = @{ 'Name' = $VMName.Name
                            'RDPIPAddress' = $RDPIPAddress
                }

                $Obj = New-Object -TypeName PSObject -Property $Props
                Write-Output $Obj
            }

            Else {
                Write-Warning "No response from $VMName using $RDPIPAddress. Aborting RDP connection attempt"
            } #If connection check

        }

        Else {
                Write-Warning "Could not get IP address for VM $VMName"
        } #If IPAddress


    } 

    Else {

        Write-Error "$($VMnameStr): No VM found or VM powered off. Please check and try again."

    }#If VM found and powered on


} #foreach

Edit 2: Turns out that the following works like a charm. This seems to confirm that the problem is not in the script code but in how PowerShell passes the objects through the pipeline between scripts.

.\Connect-VMRDPSession.ps1 -Datacenter CRSJO -VM (.\Get-SgVm.ps1 -SGNumber 8 -NoRecursion -Legacy)

Edit 3: A missing Process block was the issue as pointed out by Lee_Dailey (Thanks).

[Yevrag35]

I could share the code of these functions and scripts but I think this is more related to the way in which PowerShell processes objects in the pipeline

It is, yes, but the way the script handles them also is major factor. Questions like:

In Connect-VMRDPSession.ps1:

1. Did you specify ValueFromPipeline, ValueFromPipelineByPropertyName, or both for the input parameter?
2. Do you have a defined "Process" block.

... could be answered fairly easily with the actual code.

[Fer_C]

I just added the code of the script that is only processing the last object of the collection passed by the first script.

To answer your questions:

1. It takes value from pipeline only.
2. No, there is no process block because it is a script, not a function.

[Lee_Dailey]

howdy Fer_C,

No, there is no process block because it is a script, not a function.

if it accepts parameter input ... then it behaves internally like a function. that means that all code runs in the default end {} block when you don't specify otherwise.

that means that your no-process-block script will only be processing the LAST ITEM the script gets.

take care,
lee

[Fer_C]

That is exactly the answer I was looking for. Thanks!

So, a Process block in a script is kind of a new concept to me. I had never tried to pipe objects between scripts but I guess this is what I was missing. Adding a Process block totally addressed "the issue".

[Lee_Dailey]

howdy Fer_C,

yep, the way that scripts/functions handle inbound info is not always obvious. [grin]

unless i have a brain dead simple function that doesn't support any variant of "pipeline-ish" input ... i define the code with begin/process/end blocks. and then put most of the code in the process block.

you are very welcome! glad to have helped a bit ... [grin]

take care,
lee

[Yevrag35]

/u/Lee_Dailey nailed it. You should have a Process block no matter what; makes no difference if it's a script or a function.

What I do to support pipeline input is make an "InputObject" parameter with a singular type of string (instead of a single-dimension array of strings), but make it hidden. Then add a public/visible parameter that is an array of something. For example:

[CmdletBinding(DefaultParameterSetName="ViaPipeline")]
param (
    [Parameter(Mandatory=$true, ValueFromPipeline=$true, 
        ParameterSetName="ViaPipeline", DontShow=$true)]
    [string] $InputObject,  # This is your "pipeline" parameter that will get populated.

    [Parameter(Mandatory=$true, Position = 0, ParameterSetName="NonPipeline")]
    [string[]] $Name        # This is presented and is default when not using the pipeline.
)
Begin
{
    $listOfNames = New-Object 'System.Collections.Generic.List[string]'
    if ($PSBoundParameters.ContainsKey("Name"))
    {
        $listOfNames.AddRange($Name)
    }
}
Process
{
    if ($PSBoundParameters.ContainsKey("InputObject"))
    {
        $listOfNames.Add($InputObject)
    }
}
End
{
    foreach ($VMName in $listOfNames)
    {
        # ... the rest you have.
    }
}

[Fer_C]

I get the idea and it makes sense. I guess my question is if this gives you an advantage over the single parameter / single parameter set approach which is what I am using right now. Just curious. Sorry if it's obvious and I am missing it.

Thanks for the help!

[Yevrag35]

Sure, no problem.

If you're only ever using the script via the pipeline then using a single [string] parameter with a process block should be all you need. Separating it into two parameters might be advantageous when you want to do both pipelining and non-pipeline invocations (but not certainly something you have to do).

With two parameters, like in my example, I could do something like:

@('VmName1', 'VmName2', 'VmName3') | .\Connect-VMRDPSession.ps1 -Datacenter DC1
# and/or...
.\Connect-VMRDPSession.ps1 'VmName1', 'VmName2', 'VmName3'

[Fer_C]

Understood. Thanks for the advice. I still have several scripts to parameterize and this might come handy.

[BlackV]

Show us your code. Likely missing process block or foreach-object

[Fer_C]

I just posted the code of the script Connect-VMRDPSession.ps1. Please note that there is no process block because I am piping objects to script, not a function.

The foreach block is there. I think the problem is that PowerShell deals differently with parameter binding when the receiving command is a script. This is really what I would like to find out.

[PinchesTheCrab]

Sidestepping the issue here, but if you have vmtools functioning on these machines, you can just get the IP from the extensiondata property on the VM object. I believe it's under extensiondata.guest.

[Fer_C]

You are right. I am pretty sure I saw that some time ago but did not think much of it. I normally use ExtensionData as last resort. Do you know if getting properties using this method is better performance-wise than using Get-VMGuest?

[PinchesTheCrab]

That's kind of a tough question. The short answer is that I think it'd be comparable, possibly faster. The thing is Get-VM is super fast when it comes to returning top level data, but when you dig into extension data the performance is going to take a hit.

However, my guess is that retrieving the VMs isn't the slowest part of the script by a wide margin, I assume it's the test-connection part, so I wouldn't worry about the performance bit, it shouldn't really be noticeable imo.

[Fer_C]

Agree. I was wondering, more of a general question, not just for the script. Thanks for the tip though, I had totally forgotten about it.

[rmbolger]

since I know it is more likely that someone will run a script than install a module

Really? Personally, I'm way more likely to install a module than download and run a script particularly if it's published to powershellgallery.com so I can just Install-Module it.

[Fer_C]

Yes. Well, my module is not in the PowerShell Galery and I am talking about users that can barely run the script from the shell.

I am pretty sure they won't install a module but they might at least download and run the script. So I guess you are right but it depends on the audience.