🛠️ The Issue

If you’ve ever connected to Exchange via Remote PowerShell (New-PSSession or Exchange Online Management Shell) and noticed that some properties are missing from cmdlet output — you’re not imagining things.

For example:

• Get-MailboxDatabase might not show database size
• Get-ExchangeCertificate may omit service bindings

These differences can be confusing, especially when you’re comparing results from Exchange Management Shell (EMS) vs. a remote session.

📌 The Reason

Remote PowerShell sessions operate differently than EMS:

• When you connect via New-PSSession, you’re using implicit remoting — cmdlets are proxied over the session.
• Certain Exchange-specific types and assemblies, such as Microsoft.Exchange.Data.dll, are not loaded locally by default.
• This means that some properties relying on complex objects will either be missing or replaced with placeholder text like Deserialized.Microsoft.Exchange.Data.PropertyType.

✅ The Fix (If EMS Is Installed Locally)

If you’re running your script from a machine with EMS installed (e.g., an Exchange server or admin workstation), you can load the required assembly manually before creating the session.

$global:exbin = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup').MsiInstallPath + "bin\"

[System.Reflection.Assembly]::LoadFrom((Join-Path $global:exbin "Microsoft.Exchange.Data.dll")) | Out-Null

Now, when you connect and run Exchange cmdlets, you’ll see the full output, including previously missing fields.

💡 Note: This won’t work if EMS is not installed locally — the required DLL simply won’t exist on the system.

💬 Final Thoughts

This is a small but important detail for Exchange automation and reporting. If your scripts rely on fields like Services, DatabaseSize, or others based on internal types, make sure you understand where your session is running – and whether the necessary components are available locally.

End.