It appears after CU9, unless you have installed the CU9 management tools locally on the machine, Get-MailboxDatabase returns objects whose properties are mostly strings

Take the following commands

[1] (Get-MailboxDatabase)[0].ActivationPreference | gm
[2] (Get-MailboxDatabase)[0].ProhibitSendQuota | gm

On a machine with CU9 installed, the following is returned

[1]    TypeName: System.Collections.Generic.KeyValuePair`2[[Microsoft.Exchange.Data.Directory.ADObjectId,Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35],[System.Int32,mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]

[2]    TypeName: Microsoft.Exchange.Data.Unlimited`1[[Microsoft.Exchange.Data.ByteQuantifiedSize, Microsoft.Exchange.Data,
Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]

However, on a machine without the tools installed from CU9, OR, on a machine that has no tools and simply does a remote powershell session, the following is returned

[1]    TypeName: System.String

[2]    TypeName: System.String

I suspect that upgrading the tools to those included with CU9 may fix the issue, a colleague did a fresh install using the CU9 install and his seems to work as expected.  

Is anyone else seeing something like this?

This is expected, when you open Exchange management shell it will load various libraries and data definitions that are required to understand the proper formatting that is defined for Exchange Servers and data type which it supposed to have. When you are using normal Windows Powershell and connect Exchange remotely via remote Powershell, it will retrieve the data in serial manner and will not have those data definition loaded in the shell.

Do you mean you are/were seeing proper data type / definition when you connect to Exchange server remotely from Windows shell without Exchange tool/EMS?

Thanks Amit.

I can't say for sure the behavior I was seeing prior to upgrading to CU9 as I wasn't paying much attention. But your explanation makes sense, thanks.

Just wanted to double check if this is expected behavior between CU's... seems a little extreme.