I've been doing a couple of blog posts this year on PowerShell terminology. In this post, I will discuss what I like to call “tightly integrated products”. Briefly, I use this term when I talk about how different Microsoft server products implement their support for PowerShell.
In the case of tightly integrated products, these products provide full PowerShell support. With tightly integrated products, every task that can be accomplished via the product’s administration user interface can be accomplished with the use of a cmdlet developed by the product team itself. In fact, it happens that the user interface actually runs these cmdlets under the covers.
As a matter of fact, from what I understand, PowerShell is now the only public API to managing Exchange 2007 and later. You could use WMI with Exchange 2003, but that interface is now gone. Apparently, you can still use MAPI to automate Exchange 2007 though. I don't know if the difference is that MAPI isn't offiicially supported by Microsoft anymore. Any readers know anything about this? Please leave a comment if you do.
These are example of Microsoft products that I consider to be tighly integrated:
- Exchange 2007 (and later).
- System Center Virtual Machine Manager 2008 (and later).
In the case of Exchange 2007, there was a complete rewrite of the administration interface from Exchange 2003. Now, every command that can be undertaken in the user interface is available as a cmdlet. As mentioned above, the user interface actually runs these cmdlets in the background.
What is cool about this type of integration is that, when undertaking any kind of task in the user interface using the built-in wizards, at the end of the wizard, a screen actually display the actual PowerShell commands that will be run. This makes it easy to copy and paste the commands to use this in other automation scenarios or simply to help with learning how to use PowerShell.
As a matter of fact, Exchange was the first product to fully integrate PowerShell to this level. Exchange 2007 was developed using PowerShell v1. Now, even more exciting news... Exchange 2010 was developed using PowerShell v2! Exchange 2010 fully utilizes some of the new v2 features like PowerShell remoting. Imagine... You can use v2 on a client, and as long as you have the proper permissions on the Exchange 2010, you can remote into the Exchange 2010 and use the Exchange Management Shell... You don't have to copy the admin tools to every client like with Exchange 2007.
Not all of this was good news to everyone though. Some have expressed concern that you can actually do more with the cmdlets as some tasks aren't available through the Exchange 2007 management console. That being said, that improved with SP1 (I'm not sure about SP2 which is now out). Exchange 2010 has expanded the number of cmdlets dramatically. I can't remember the exact numbers though.
I'm not going to specifically discuss SCVMM here, unless someone leaves a comment wishing that I discuss the PowerShell integration in more detail.
So the path to manage these applications is:
PowerShell->Application.
RSS feed
