Splatting to a cmdlet casts input

This topic contains 9 replies, has 3 voices, and was last updated by  Ritmo2k 3 years, 5 months ago.

  • Author
    Posts
  • #14749

    Ritmo2k
    Participant

    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!

  • #14750

    Don Jones
    Keymaster

    Do you have the exchange cmdlets installed locally?

  • #14751

    Ritmo2k
    Participant

    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.

  • #14752

    Dave Wyatt
    Moderator

    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
    
  • #14753

    Don Jones
    Keymaster

    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.

  • #14754

    Ritmo2k
    Participant

    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.

  • #14755

    Don Jones
    Keymaster

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

  • #14757

    Dave Wyatt
    Moderator

    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.

  • #14758

    Ritmo2k
    Participant

    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.

  • #14756

    Ritmo2k
    Participant

    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

You must be logged in to reply to this topic.