PowerShell Terminology: Tightly integrated products

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.

PowerShell Terminology: Loosely integrated products

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.

PowerShell Terminology: Common Engineering Criteria

I recently started a series on PowerShell terminology HERE.  One thing I mentioned was Microsoft’s Common Engineering Criteria (CEC).

You can read through Microsoft’s official web site HERE.

From my understanding, CEC is a set of best practices that are to be implemented in all server-based products.  Now, this may be some kind of internal document, and I’ve never seen it, so this is my unofficial interpretation of things…

Microsoft added PowerShell as of their CEC 2009 standards.  Apparently, if a server product doesn’t meet all of the CEC guidelines, the particular product team must justify each and every deviance from this to some internal Microsoft group who likely oversees the compliance to the standards.

Based on the products that have recently come out from Microsoft, I don’t believe the standard outlines exactly how PowerShell should be implemented in products.  This is my conclusion based on seeing the differences with how newer products have varying levels of PowerShell support.

I introduced some new terms HERE: “PowerShell-enablers”, “loosely integrated products”, and “tightly integrated products”.  I’ll likely cover these last 2 terms next week.

PowerShell Terminology: PowerShell-enablers

I’m going to blog about a few terms I like to use when I talk about how PowerShell is supported in different Microsoft server applications.

The terms I will introduce in are:

• PowerShell-enablers.
• Loosely integrated products.
• Tightly integrated products.

This is the first post in this small series, so I’m going to briefly discuss “PowerShell-enablers”:

Since Microsoft announced that PowerShell was now part of their Common Engineering Criteria since 2009, there are some products that officially released around the time of the announcement and also after.

There are examples of Microsoft products that don’t provide any PowerShell support per se:

• Hyper-V.
• System Center Configuration Manager 2007.
• Office Suite and Internet Explorer (just client applications, but still).

Now, that being said, these products do support “PowerShell-enablers”.  To me, these are technologies like COM (Component Object Model) and WMI (Windows Management Instrumentation).

Via COM, I can automate Office and IE, and I can access COM from PowerShell.  Via WMI, I can automate Hyper-V and ConfigMgr, and there is excellent support for WMI from PowerShell.

So the path to manage these applications is:

PowerShell->WMI or COM->Application

In the next post, I’ll talk about loosely integrated products.