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.
