Is it really unsupported to use the Exchange PSSnapin?

I used to think so. It seemed pretty cut and dry to me at least. After all,  the official public documentation from Microsoft is very clear:

Loading the Microsoft.Exchange.Management.PowerShell.SnapIn Windows PowerShell snap-in and running cmdlets other than the *-TransportAgent cmdlets is not supported and may result in irreparable damage to your Exchange deployment.
This is reiterated by my friend Rhoderick:

http://blogs.technet.com/b/rmilne/archive/2015/01/28/directly-loading-exchange-2010-or-2013-snapin-is-not-supported.aspx

But Rhoderick does say something I never really paid attention to before now:

Unless you are following a specific process that is documented by Microsoft or are working with a Microsoft support representative, the only way you should be connecting to Exchange is the method documented above

So there it is. Another exception to the rule that you may want to be aware of if you are running Exchange 2013 CU11. In the event of a “critical failure”, Microsoft advises you use the PSSnapin.

If you open EMS and are not able to connect to any Exchange Servers due to loss of communication, then you will need to add the PSSnapin for Exchange to your local PowerShell Session.

Hopefully you will never be in a failure scenario that necessitates using the PSSnapin, but if you are, it’s an available option.

For more on the mailbox anchoring issue, hop over to Andrew’s blog:

https://exchangemaster.wordpress.com/2016/01/06/mailbox-anchoring-affecting-new-deployments-upgrades/

 

Recommended Reading

Discuss