Author Posts

April 23, 2014 at 5:18 pm

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?

Thanks!

April 23, 2014 at 5:25 pm

Do you have the exchange cmdlets installed locally?

April 23, 2014 at 5:29 pm

Hi,

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?

Thanks.

April 23, 2014 at 5:30 pm

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
{
    [CmdletBinding()]
    param (
        $Parameter
    )

    $Parameter.GetType().FullName
}

$hash = @{
    Parameter = $collection
}

Test-Function @hash

April 23, 2014 at 5:30 pm

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.

April 23, 2014 at 5:36 pm

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.

April 23, 2014 at 5:39 pm

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

April 23, 2014 at 5:54 pm

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.

https://connect.microsoft.com/PowerShell/feedback/details/859880/microsoft-exchange-data-proxyaddresscollection-fails-to-deserialize-through-a-pssession

April 23, 2014 at 5:58 pm

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.

April 23, 2014 at 6:05 pm

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.

Thanks.