Splatting to a cmdlet casts input

I have been battling this for a couple days now and would be grateful for any insight.

I have to build a hash of some unknown number of parameters for which some have various collection data types. When the hash is splatted to the cmdlet, any collections such as Microsoft.Exchange.Data.ProxyAddressCollection get cast to an simple array? This makes the cmdlet fail.

This is under the content of a pssession to an exchange 2013 server. Anyone have any ideas?


Do you have the exchange cmdlets installed locally?


I do have the management tools installed however I am still creating a pssession and importing that into my runspace.

Have you ever seen this behaviour before?


Please post the code that’s giving you problems.

I did a quick test with another class and couldn’t reproduce the issue, but Exchange throws implicit remoting into the mix, which may have different behavior somehow. Either way, we need to see how you’re building your hashtable and which cmdlets you’re calling to troubleshoot.

Here’s the test that I ran:

Import-Module ActiveDirectory

$collection = New-Object Microsoft.ActiveDirectory.Management.ADPropertyValueCollection
$collection.AddRange(('One', 'Two', 'Three'))

function Test-Function
    param (


$hash = @{
    Parameter = $collection

Test-Function @hash

Yeah. It’s Remoting not serializing and deserializing the object. Which actually the object does itself, so it’s likely that class either doesn’t implement the protocol or isn’t doing it right. You should raise it as a bug in Connect if nothing else.

Nice:( Can you think of a workaround? As the parameters being called vary at runtime as to which attributes are being set, I need to construct the input to the cmdlets dynamically which is why splatting was so attractive. What’s silly as Set-MailUser will accept multiple values at the cli for EmailAddresses but if you pass a collection, it must be the right type.

Thanks Don and Dave.

Take Remoting out of it. Get the entire thing running on the server if that’s possible.

Right, maybe send the data in the string format it originates as and simply use invoke-command with a script block and session…

I should have paid more attention to the stack trace, it certainly confirms what you suspect given the data type the cmdlet receives.


What error messages are you getting? ProxyAddressCollection has a constructor that takes an ICollection, so you should be able to pass in basically any array for that parameter and have it work (so long as all the elements of the array can be cast to a ProxyAddress object). A simple string array should be fine (which is what happens when you type the addresses at the command line.)

Unfortunately, I don’t have an Exchange server up at the moment to test it myself, but I’ll spin up a quick Azure VM in a bit.

The link to the bug report was malformed, it has the stack trace.

I’ll check in the morning myself but that constructor should have worked if the input was an array but it ended getting deserialized into System.Management.Automation.PSObject.