Hi, I want to be absolutely sure that PowerShell implicit remoting to Exchange Server 2010 works without any problems. To be more precise, I learned that main caviat of PowerShell implicit remoting was piping the output of one cmdlet as input to other cmdlet since the first one is executed on remote computer and results are sent back to local computer in .xml format as deserialized object(s) and piping would fail. Don Jones (PowerShell MVP) explained this problem in his CBT PowerShell training saying that early versions of some products could have this problem. If implicit remoting to Exchange Server 2010 does not have any restrictions then I do not need to install Management Tools locally since I rarely use EMC and prefer managing Exchange via PowerShell.
I’ve administered Exchange 2010, and 2013, over the last two years. In that time, I have installed the management tools on my local machine a total of zero times. Keep in mind that when you pipe one cmdlet to another, such as Get-Mailbox -Identity msmith | Get-MailboxStatistics, that the full command (the parts before and after the pipe), will be run on the Exchange server. Only then, will the data be serialized, transferred back to your computer, and deserialized. I haven’t run every Exchange cmdlet, but I’ve never lost an important method I needed to run – a side effect of deserializing data – or had any other problems. I wrote about this early on, but if you don’t have one, here’s a function to help you establish your connection (there’s a bunch of these online): link
In CBT PowerShell Ultimate Training Don Jones explained main caviat of implicit remoting - pipelining (some cmdlets). He gave an example which failed:
$dc=New-PSSession -ComputerName dc.lab.pri
Import-PSSession -Session $dc -Prefix LAB -Module ActiveDirectory
Get-LABADUser -Identity DonJ | Set-LABADUser -City LA
He also mentioned that pipelining Get-EXMailbox | Set-EXMailbox could also fail depending on Exchange version. If I am right Exchange Server 2007 was first version of Exchange which could be managed via Exchange Management Shell thereby this problem might not occur at all in Exchange Server 2010 and later.