I recently started a small series of posts on PowerShell terminology. In this post, I will discuss what I like to call “loosely 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 loosely integrated products, these products don’t provide full PowerShell support. Unlike some server products, with a loosely integrated product, not 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.
These are example of Microsoft products that I consider to be loosely integrated:
- System Center Operations Manager 2007.
- Internet Information Services 7.0.
- SQL Server 2008.
In the above examples, the product team ships the product with a PowerShell snapin (except the IIS7 must be downloaded separately).
In the case of Operations Manager 2007, for example, the product provides a customized PowerShell console named “Command Shell” (renamed to “Operations Manager Shell” as of Operations Manager 2007 R2). What the product team has done is used the Operations Manager SDK managed assembly and created a limited number of cmdlets. So the cmdlets are officially supported, but you cannot accomplish everything from within PowerShell that can be done from the UI. Furthermore, because of the incomplete cmdlet coverage, the UI wizards don’t provide similar functionality to the Exchange 2007 UI whereas when a task is done, the underlying PowerShell code used is not presented.
Hopefully the next version of Operations Manager (maybe in 2012) will provide more complete PowerShell support, which can mean a major rewriting of the user interface.
I’m not going to go into detail about IIS7 and SQL Server 2008, unless a comment is left asking me to discuss them in detail.
So the path to manage these applications is:
PowerShell->.NET assembly or SDK->Application.
I will cover tightly integrated products soon.
