Author Posts

February 7, 2016 at 9:37 am

I have created a function with a parameter name 'computername'. I want to accept value from pipeline, so I enabled ValueFromPipelineByPropertyName. Since I may be accepting pipeline info from get-adcomputer I set an alias to be 'Name".

When I run either of these commands it works as expected:
get-adcomputer -filter 'name -like "dc"' select name | my-function
get-adcomputer -Filter 'name -like "trn_br1_w12"' | select @{n="ComputerName";e={$_.name}} | My-Function

If I run this command it doesn't produce any output
get-adcomputer -filter 'name -like "dc"' | my-function

If I change the parameter name to 'Name' and the alias to 'ComputerName' the command works as expected and gives me the results.
get-adcomputer -filter 'name -like "dc"' | my-function

Shouldn't it work the same way for an alias as it does for the parameter?

function My-Function
{
	[CmdletBinding()]
	param
	(
		[Parameter(ValueFromPipeline = $true,
				   ValueFromPipelineByPropertyName = $true)]
		[Alias('Name')]
		[string[]]$ComputerName,
		[string]$LogName = '.\Deadfile.csv'
	)

February 7, 2016 at 10:09 am

That's an annoying quirk of how the objects that the AD cmdlets output behave. An easy workaround is to pipe to "Select *" first:

Get-ADComputer @adComputerParams | Select * | My-Function

There's nothing else you can do about it, unfortunately. The AD module is very, very weird.

February 10, 2016 at 6:19 pm

Interesting, I think the difference between within and without "Select" is the membertype is changed from property to noteproperty though the object type is still ADComputer.

Does it mean why we pipebypropertyname, we should always make sure it's noteproperty?

February 10, 2016 at 6:40 pm

Nope, most of the time there's no need to worry about that. The AD objects are just weird.