READY: Should you care about Windows PowerShell?

I’m going to start blogging on the System Center Central web site.  The site is dedicated to Microsoft’s System Center product line, which covers a wide-range of products. 

I’m starting a series of blogs posts there to talk about using PowerShell while focusing on its use with System Center products. I’m going to title the series: “READY”, “SET”, “GO”. “Ready” is already posted HERE where I talk about why you should learn PowerShell.

The “Set” post will probably cover some PowerShell terminology you should really know, and may want to refer back to at any time, and finally the “Go” posts will be a potentially indefinite number of posts where I’m actually going to use PowerShell to try to do something productive to show you how you can use PowerShell.

The integration these System Center products have with PowerShell also greatly varies, and I plan to discuss this in future posts in the series.  I would expect them to have better integration in the future though.

Please feel free to leave comments at any time if you want me to cover anything in particular. My next post  in that series should appear in the next 2 weeks...

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.

TechNet Webcast: Using Windows PowerShell with Hyper-V and Virtual Machine Manager (Level 300)

Date/time: Thursday, September 10, 2009 10:00 AM Pacific Time (US & Canada)

You can sign up for the webcast HERE.

Event Overview
Windows PowerShell is likely to become the automation tool of choice. In this webcast, we provide examples of Windows PowerShell being used to perform common administration tasks in Hyper-V and Microsoft System Center Virtual Machine Manager. We compare the two automation methods in detail, and we discuss some online community-focused PowerShell resources such as http://powershellcommunity.org.

Presenters: Marco Shaw, Microsoft MVP, Independent; Darin Pendergraft, PowerGUI Product Manager, Quest Software; and Peter Zerger, Consulting Partner, AKOS Technology Services, Inc.

Call to Action: Please read if you want to influence PowerShell documentation

Hello everyone,

I'm a co-director of the PowerShellCommunity.org web site. I've been recently approached by June Blender from the Microsoft PowerShell documentation team to setup a process where people from the PowerShell community would participate in the review of PowerShell documentation while it is in a draft state.

I'm still working out the kinks in the process, but currently, I'm looking for at least 4 people from the community to volunteer to help review some outstanding documentation. Specifically, I'm looking for 2 beginner-level users and 2 intermediate/advanced users.

The review could be of new documentation or updates to existing documentation.

If you're interested in participating in the review and being able to provide your comments and influence how PowerShell help features are written, send a message to doc_reviews@powershellcommunity.org. Please indicate your current level of familiarity with PowerShell. Once assigned something to review, you will be expected to review what is assigned to you within 7 days.

You will need to be a member of the http://www.powershellcommunity.org
(http://www.poshcomm.org) web site to participate because the site will be used in the review process.

Once you are accepted as a reviewer, more details will be sent to you via email.

If you do not receive any kind of acceptance message/email, your name maybe archived for future use. Unfortunately, I don't know whether I will be able to respond to every email from all volunteers.