为什么相同的脚本在 Exchange Management Shell 2010 中有效，但不能通过 C# 与 Powershell 和 Exchange Connection

Question

I have the following powershell script I use with Exchange 2010 to get the forwarding email adresses

$fwds = get-mailbox | Where-Object { $_.ForwardingAddress -ne $null } | select Name, ForwardingAddress

foreach ($fwd in $fwds) 
{
    $fwd | add-member -membertype noteproperty -name "ContactAddress" -value (Get-ADObject -Identity $(($fwd.ForwardingAddress).DistinguishedName) -Properties mail).mail
   

    if($fwd.ContactAddress)
    {
        #Maakt objecten aan die in C# uit te lezen zijn
        $properties = @{
            Name = $fwd.Name
            ContactAddress = $fwd.ContactAddress
        }   

        $o = New-Object psobject -Property $properties;

        # Dit zet het object bruikbaar als object in c#
        Write-Output $o
    }
}

When I run this in the Exchange Management Shell (2010) it works fine.. Yesterday I also were able to run this through Powershell in C#.

I use the following code for connecting after I open a runspace

                        PSCommand commandExchangePSSession = new PSCommand();
                        commandExchangePSSession.AddCommand("New-PSSession");
                        commandExchangePSSession.AddParameter("ConfigurationName", "Microsoft.Exchange");
                        commandExchangePSSession.AddParameter("ConnectionUri", argUri);
                        commandExchangePSSession.AddParameter("Credential", creds);
                        commandExchangePSSession.AddParameter("Authentication", "Kerberos");

                        PSSessionOption sessionOption = new PSSessionOption();
                        sessionOption.SkipCACheck = true;
                        sessionOption.SkipCNCheck = true;
                        sessionOption.SkipRevocationCheck = true;
                        commandExchangePSSession.AddParameter("SessionOption", sessionOption);

Then I use a Get-Session command, followed by a Import-Session . After that I use PowerShell.Create() to create a new PowerShell Object to add the script into with:

                                var powershellExecScript = PowerShell.Create();
                                powershellExecScript.Commands.AddScript(tempTotalScript); 

                                powershellExecScript.Runspace = runspace;

                                Collection<PSObject> results = powershellExecScript.Invoke();

Where tempTotalScript is the script stated above... Yet when I run it I get errors that Identity can't be NULL.

Exception: System.Management.Automation.ParameterBindingValidationException: Cannot validate argument on parameter 'Identity'. The argument is null. Provide a valid value for the argument, and then try running the command again. 

So I narrowed the problem down to $(($fwd.ForwardingAddress).DistinguishedName

The $fwd.ForwardingAddress works, it returns a valid value through C#. So this also means my powershell connection code is not invalid. But the DistinguishedName does not, it returns null. This is the reason I am getting errors running my code through C#.

When I try the same code in the Exchange Management Shell... the DistinguishedName property is not null and showing a proper distinguished name..

So my question is, why is the DistinguishedName property inside $fwd.ForwardingAddress not filled with a value when I run the code through C# Powershell?

Answer 1

This is because a remote session returns serialized (also called dehydrated or string-ified) objects. These do not maintain full fidelity to the original objects. Usually, this is described as the removal of methods, but it can go beyond that. Typically, complex objects are somewhat flattened. Using this case as an example, in an Exchange Management Shell console, where the management tools are installed and properly loaded, the ForwardingAddress property is of type [Microsoft.Exchange.Data.Directory.ADObjectId] .

However, in a remote session established with the below command:

$session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://<serverName>/powershell" -Authentication Kerberos
Import-PSSession -Session $session

Then the forwarding address will be a simple string formatted as a canonical name. This is usually the same as running the full fidelity object through the .ToString() method.

I haven't done any of this through C#, however, it is a big problem. We'll tend to develop in an environment that has our full tool-chain installed then deploy to an environment that doesn't. There are 2 ways I've dealt with the problem.

1. Make an exception and develop under the same environmental circumstances you plan to deploy to.
2. Build logic into your code to detect the object type and act differently, something like below:

---

If( $ForwardingAddress.GetType().Fullname -is [String] ) {
    # Do Something... 
} 
Else {
    # Do something different...
}

#1 is obviously more simple.

#2 is better for continued development because you can run and test locally. However, this can also get out of hand, as your program gets more complex and you have other objects to deal with, etc... Not to mention there's overhead to checking the objects even before accommodating them.

Answer 2

Edit: This is not the right answer.

Seems that Get-ADObject did not work in Exchange 2010. I had to use get-contact

#Exchange 2010 Script
$fwds = get-mailbox | Where-Object { $_.ForwardingAddress -ne $null } | select Name, ForwardingAddress, DeliverToMailboxAndForward

foreach ($fwd in $fwds) 
{

    $ErrorActionPreference = "SilentlyContinue"
    $fwd | add-member -membertype noteproperty -name "ContactAddress" -value (get-contact $fwd.ForwardingAddress).WindowsEmailAddress
    $ErrorActionPreference = "Continue"


    #Maakt objecten aan die in C# uit te lezen zijn

    if($fwd.ContactAddress)
    {
        $properties = @{
        Name = $fwd.Name
        ContactAddress = $fwd.ContactAddress
        DeliverToMailboxAndForward = $fwd.DeliverToMailboxAndForward
        }
        $o = New-Object psobject -Property $properties;

        # Dit zet het object bruikbaar als object in c#
        Write-Output $o
    }
}