I've always taken that quote to heart and it just kills me that Microsoft uses Write-Host to display the banner every time you start Exchange Management Shell (EMS). While it's not really that big of a deal with EMS, it can be a problem when you are trying to run Exchange Cmdlets outside of EMS, especially if you are running them in a separate runspace (more on that in a bit).
The proper way to be able to use the Exchange 2010 Cmdlets outside of EMS (assuming you have the Exchange 2010 Management Tools installed locally) is to dot source RemoteExchange.ps1 and then use Connect-ExchangeServer. I'm not going to get into why this is the proper way over just using Add-PSSnapin, but I will say RBAC and leave it at that.
In the pic below, you can see that in action. YUCK! The Exchange Team just killed dozens of puppies...
While ugly in my opinion, not necessarily harmful. But if you are running a script, you may not want to see all that. In my case, I was playing with runspaces and ran across a problem of Write-Host generating errors (non-terminating errors, but errors none the less). I had this problem because there was no PSHost in my runspace, and PSHost is what Write-Hosts writes to.
In the past, I've looked for a switch or another way to supress the Exchange Banner to no avail. You can't redirect the output or pipe it to Out-Null, because as stated above, Write-Host writes to PSHost and not to a PowerShell Stream. My solution was to define an empty function for Write-Host, essentially hijacking it prior to dot sourcing RemoteExchange.ps1.
In the pic below, you can see that I tried to use Get-Mailbox before dot sourcing RemoteExchange.ps1 (which failed). I then defined my hijacked Write-Host funciton and dot sourced RemoteExchange.ps1. YAY, no puppies killed. I then removed the function and verified that Get-Mailbox and Write-Host both work.
And that's all there is to it. Simple, yet effective.
. 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -Auto
In the pic below, you can see that in action. YUCK! The Exchange Team just killed dozens of puppies...
While ugly in my opinion, not necessarily harmful. But if you are running a script, you may not want to see all that. In my case, I was playing with runspaces and ran across a problem of Write-Host generating errors (non-terminating errors, but errors none the less). I had this problem because there was no PSHost in my runspace, and PSHost is what Write-Hosts writes to.
In the past, I've looked for a switch or another way to supress the Exchange Banner to no avail. You can't redirect the output or pipe it to Out-Null, because as stated above, Write-Host writes to PSHost and not to a PowerShell Stream. My solution was to define an empty function for Write-Host, essentially hijacking it prior to dot sourcing RemoteExchange.ps1.
function Write-Host {}
In the pic below, you can see that I tried to use Get-Mailbox before dot sourcing RemoteExchange.ps1 (which failed). I then defined my hijacked Write-Host funciton and dot sourced RemoteExchange.ps1. YAY, no puppies killed. I then removed the function and verified that Get-Mailbox and Write-Host both work.
And that's all there is to it. Simple, yet effective.
Is there a clean and easy way to do this from within a script? Can't really define and then remove the Write-Host hijacked function the same way.
ReplyDeleteWhy can't you?
ReplyDeleteI've done this in a couple scripts:
# Take over Write-Host
function Write-Host {}
# Load Exchange 2007 Management Tools
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
. 'C:\Program Files\Microsoft\Exchange Server\bin\Exchange.ps1'
# Give Back Write-Host
Remove-Item function:Write-Host