1

I am building a report of certain mailbox attributes from Exchange Server 2010 using PowerShell. The following code worked perfectly from my management workstation using a remote session.

$Mailboxes = Get-mailbox -ResultSize Unlimited 
foreach ($Mailbox in $Mailboxes)
{
$Mailbox | Add-Member -MemberType "NoteProperty" -Name "MailboxSizeMB" -Value (Get-MailboxStatistics $Mailbox).TotalItemSize
}

However, when I added the .Value.ToMb() method to the TotalItemSize attribute, the script failed with the following error:

$Mailboxes = Get-mailbox -ResultSize Unlimited 
foreach ($Mailbox in $Mailboxes)
{
$Mailbox | Add-Member -MemberType "NoteProperty" -Name "MailboxSizeMB" -Value ((Get-MailboxStatistics $Mailbox).TotalItemSize.Value.ToMb())
}

You cannot call a method on a null-valued expression. At line:6 char:6 + $Mailbox | Add-Member -MemberType "NoteProperty" -Name "MailboxSizeMB" -Val ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : InvokeMethodOnNull

Cannot process argument transformation on parameter 'Identity'. Cannot convert the "[Mailbox Name Redacted]" value of type "Deserialized.Microsoft.Exchange.Data.Directory.Management.Mailbox" to type "Microsoft.Exchange.Configuration.Tasks.GeneralMailboxOrMailUserIdParameter". + CategoryInfo : InvalidData: (:) [Get-MailboxStatistics], ParameterBindin...mationException + FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-MailboxStatistics

And yet...the second block of code (converting the TotalItemSize value to MB) works perfectly when I run it locally on the Exchange server. Can anyone explain why this only fails remotely?

2 Answers 2

2

This happens when you're missing the .Net types Exchange uses. PowerShell remoting perfomrs some serialization that makes some objects end up as "PsObject" instead of the full strongy typed object. The solution is to install the Exchange Management Console on your client computer, this will include the .Net types you need.

8
  • Thanks, that makes sense. Unfortunately our Exchange Server is in a resource forest and my management workstation is not. I've yet to find a way to install the exchange management tools on a machine that is not in the Exchange resource forest.
    – Sam Erde
    May 21, 2015 at 11:41
  • Gotcha. Although I haven't tried it yet, the EWS Managed api installer might give you the same .net classes locally. No guarantees, tho. (microsoft.com/en-us/download/details.aspx?id=42951)
    – Trondh
    May 21, 2015 at 14:58
  • You don't need custom types or classes just to convert bytes to megabytes or whatnot... Just $foo / 1mb
    – Ryan Ries
    May 21, 2015 at 15:59
  • 1
    That's not correct @RyanRies. Exchange uses it's own custom types, not regular ints. Believe me, I've tried :-)
    – Trondh
    May 21, 2015 at 18:59
  • Note, the EWS Managed API appears to require a 64-bit machine. I ran it first from my workstation and got a Windows Installer error stating that "This installation package is not suported by this processory type. Contact your product vendor."
    – Sam Erde
    Jun 8, 2015 at 12:20
1

Try this:

Set-ADServerSettings -ViewEntireForest $true -WarningAction SilentlyContinue

Then run the command set.

3
  • What does this parameter do?
    – Sam Erde
    May 21, 2015 at 11:42
  • This param: FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-MailboxStatistics lends itself to a forest view issue May 21, 2015 at 14:32
  • That is a factor, but I don't think the actual problem. As noted in the answer/comments from Trondh, I am unable to install the required management tools because the management machine in question is not in the Exchange forest. In this case, the Set-ADServerSettings -ViewEntireForest command does not help. Thanks, though!
    – Sam Erde
    Jun 8, 2015 at 12:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .