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?


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.

  • 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. – SturdyErde May 21 '15 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 '15 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 '15 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 '15 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." – SturdyErde Jun 8 '15 at 12:20

Try this:

Set-ADServerSettings -ViewEntireForest $true -WarningAction SilentlyContinue

Then run the command set.

  • What does this parameter do? – SturdyErde May 21 '15 at 11:42
  • This param: FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-MailboxStatistics lends itself to a forest view issue – Matthew Dartez May 21 '15 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! – SturdyErde Jun 8 '15 at 12:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.