Skip to main content

The PowerShell Pipeline at the Surface: ByValue

This is post 3 of 7 in this series.

In reality, we are not actually passing objects to the cmdlet on the right, rather we are passing objects to the parameters of the cmdlet on the right. There are two ways that parameter passing can be achieved; ByValue and ByPropertyName.

In ByValue parameter passing, we actually look at the value of the object.  For example, if we pass a string object to a cmdlet that can receive the object ByValue, it looks that what the string says.  In other words, if the string says “Hello World”, the cmdlet will use “Hello World”. To determine how parameter passing will work, or even if it will, we need to perform two tasks. 

Task number 1 is to discover the TypeName of the object the was created from the cmdlet on the left.  This can be accomplished in a couple of ways.  The first way is to pipe the object to the cmdlet Get-Member.

PS C:\> "Bits" | Get-Member


   TypeName: System.String

Name             MemberType            Definition                                            
----             ----------            ----------                                           
Clone            Method                System.Object Clone(), System.Object ICloneable.Clo...
CompareTo        Method                int CompareTo(System.Object value), int CompareTo(s...
Contains         Method                bool Contains(string value)              

When you do, take a look at the TypeName.  In this case, the TypeName is System.String.  We will just say that it is a string object for short.

Another way to get the TypeName is to use the GetType() method.

PS C:\> ("Bits").GetType()

IsPublic IsSerial Name                                     BaseType                       
-------- -------- ----                                     --------                        
True     True     String                                   System.Object    

Next, we need to take a look at the full help file for the cmdlet we are sending this string object to.  In our scenario, we are going to pass our string “Bits” to Get-Service.  Let’s look at the Parameter section of the help file for Get-Service.

PS C:\> Get-help Get-Service -Parameter *

-ComputerName []
    Gets the services running on the specified computers. The default is the local
    computer.
   
    Type the NetBIOS name, an IP address, or a fully qualified domain name (FQDN) of a
    remote computer. To specify the local computer, type the computer name, a dot (.), or
    localhost.
   
    This parameter does not rely on Windows PowerShell remoting. You can use the
    ComputerName parameter of Get-Service even if your computer is not configured to run
    remote commands.
   
    Required?                    false
    Position?                    named
    Default value                none
    Accept pipeline input?       true (ByPropertyName)
    Accept wildcard characters?  false
   

-DependentServices []
    Indicates that this cmdlet gets only the services that depend upon the specified
    service.
   
    By default, this cmdlet gets all services.
   
    Required?                    false
    Position?                    named
    Default value                none
    Accept pipeline input?       false
    Accept wildcard characters?  false
   

-DisplayName
    Specifies, as a string array, the display names of services to be retrieved. Wildcards
    are permitted. By default, this cmdlet gets all services on the computer.
   
    Required?                    true
    Position?                    named
    Default value                none
    Accept pipeline input?       false
    Accept wildcard characters?  false
   

-Exclude []
    Specifies, as a string array, a service or services that this cmdlet excludes from the
    operation. The value of this parameter qualifies the Name parameter. Enter a name
    element or pattern, such as "s*". Wildcards are permitted.
   
    Required?                    false
    Position?                    named
    Default value                none
    Accept pipeline input?       false
    Accept wildcard characters?  false
   

-Include []
    Specifies, as a string array, a service or services that this cmdlet includes in the
    operation. The value of this parameter qualifies the Name parameter. Enter a name
    element or pattern, such as "s*". Wildcards are permitted.
   
    Required?                    false
    Position?                    named
    Default value                none
    Accept pipeline input?       false
    Accept wildcard characters?  false
   

-InputObject []
    Specifies ServiceController objects representing the services to be retrieved. Enter a
    variable that contains the objects, or type a command or expression that gets the
    objects. You can also pipe a service object to this cmdlet.
   
    Required?                    false
    Position?                    named
    Default value                none
    Accept pipeline input?       true (ByValue)
    Accept wildcard characters?  false
   

-Name []
    Specifies the service names of services to be retrieved. Wildcards are permitted. By
    default, this cmdlet gets all of the services on the computer.
   
    Required?                    false
    Position?                    1
    Default value                none
    Accept pipeline input?       true(ByValue,ByPropertyName)
    Accept wildcard characters?  false
   

-RequiredServices []
    Indicates that this cmdlet gets only the services that this service requires.
   
    This parameter gets the value of the ServicesDependedOn property of the service. By
    default, this cmdlet gets all services.
   
    Required?                    false
    Position?                    named
    Default value                none
    Accept pipeline input?       false
    Accept wildcard characters?  false
    

In the above help file, look at the Accept pipeline input attribute on each parameter.  Do any of them have a value of True? Two of them do.  –Name and –ComputerName both accept pipeline input.  Does one of these accept pipeline input ByValue?  Only the –Name parameter does.  As a matter of fact, it accepts input both ByValue and ByPropertyName.  When you are faced with this scenario, ByValue is always tried first.

Next, we need to look at the data type of the –Name parameter.

PS C:\> Get-Help Get-Service -Parameter Name

-Name []
    Specifies the service names of services to be retrieved. Wildcards are permitted. By
    default, this cmdlet gets all of the services on the computer.
   
    Required?                    false
    Position?                    1
    Default value                none
    Accept pipeline input?       true(ByValue,ByPropertyName)
    Accept wildcard characters?  false

Right after the parameters name, you will see the data type []. In other words, the –Name parameter of Get-Service will accepts a string object’s value if passed to it from the PowerShell pipeline.  Let’s give it a try.

PS C:\> "Bits" | Get-Service

Status   Name               DisplayName                          
------   ----               -----------                          
Running  Bits               Background Intelligent Transfer Ser...

As you can see, it works!  This is what it looks like without using the pipeline.

PS C:\> Get-Service -Name "Bits"

Status   Name               DisplayName                          
------   ----               -----------                          
Running  Bits               Background Intelligent Transfer Ser...

Here is a summary of the steps that we took to determine if an object will be accepted ByValue by another cmdlet.

  1. Take the object in the pipeline from the cmdlet on the left and discover its TypeName with Get-Member
  2. Open the full help file of the receiving cmdlet on the right and see if any of its parameters accept input from the PowerShell pipeline ByValue.
  3. If they do accept pipeline input ByValue, do they accept the same object type that you are passing to it? If so, the passing ByValue will work.


1

Comments

Popular posts from this blog

Sticky Key problem between Windows Server 2012 and LogMeIn

This week I instructed my first class using Windows Server 2012 accessed via LogMeIn and discovered a Sticky Key problem every time you press the Shift key. Here is my solution to resolve this.  First off, in the Preferences of LogMeIn for the connection to the Windows Server, click General . Change the Keyboard and mouse priority to Host side user and click Apply at the bottom. On the Windows 2012 server, open the Control Panel – Ease of Access – Change how your keyboard works . Uncheck Turn on Sticky Keys . Click Set up Sticky Keys . Uncheck Turn on Sticky Keys when SHIFT is pressed five times . Click OK twice. If you are using Windows Server 2012 as a Hyper-V host, you will need to redo the Easy of Use settings on each guest operating system in order to avoid the Sticky Key Problem. Updated Information: March 20, 2013 If you continue to have problems, Uncheck Turn on Filter Keys .

Where did a User’s Account Get Locked Out?

Updated: May 15, 2015 When this article was originally published, two extra carriage returns were add causing the code to malfunction.  The code below is correct.   My client for this week’s PowerShell class had a really interesting question. They needed to know where an account is being locked out at. OK, interesting. Apparently users hop around clients and forget to log off, leading to eventual lock out of their accounts. The accounts can be unlocked, but are then relocked after Active Directory replication. This problem is solved in two parts. The first one is to modify the event auditing on the network. The second part is resolved with PowerShell. The first part involves creating a group policy that will encompass your Domain Controllers. In this GPO, make these changes. Expand Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy Configuration \ Audit Policies \ Account Management Double click User Account Management C...

Backup and Restore AD LDS with DSDBUTIL.exe

Active Directory Lightweight Directory Services allow you to create a directory service that allows applications to have access to user accounts, groups, and authentication similar to Active Directory Domain Services.  The big advantage here is that the schema of the directory service will not be bound by the rules of an Active Directory database.  Exchange 2007/2010, for example, use an instance of AD LDS on the Edge Transport Server to provide for user authentication from the internet.  Because your Active Directory database is not exposed to the internet, this is more secure. Applications will handle most of the dirty work should they require AD LDS.  You may want to make sure the database is being backed up and also have a restore plan in place.  Should the database become corrupt, the application that uses that database will fail.  This document will walk you through backing up and restoring an instance of AD LDS using the dsdbutil.exe command. Fi...