Dan Jones has a great blog HERE explaining why the SQL team decided to support PowerShell when they already had T-SQL.  It originally started as an email thread responding to the question posed by an MVP.  This was a great question to ask.  In many ways, PowerShell is merely trying catch up to what the SQL team has been doing for years but do so in a way that everyone can participate.  As you’ll see from Dan’s blog, we did it in a way that it made sense for the SQL team to embrace it. 

Let’s be clear about how what an awesome standard the SQL team set. 

• They have a command line interface which is consistent, composable and provides incredible power.
• Their GUIs are layered on top of the CLI 
• Did you think we invented that?  Absolutely not – the superstars at SQL have been doing this for years!
• Their GUI TEACHES the CLI.  When you are about to execute a task, you can view the script, you execute the script OR you can SCHEDULE the script to run at another time.
• DROOL DROOL DROOL.
• Their scripts can be TRANSACTED.
• We’re adding transaction support in V2 but it will only support those cmdlets/providers which opt-in.  To start, that just means the registry.

SQL:  Awesome product.  Awesome Team.

So given all that wonderful stuff, why would they embrace PowerShell?  Dan’s blog has all the details so go give that a read.  The thing I would like to highlight is their focus on the customer.  Dan talked about customers increasingly using multiple products and the benefits of having a single way to script against them all.

I’ve said it many times in my talks and and super passionate about it so I’ll repeat it here.

I know that learning PowerShell is an investment. 

I also know that customer’s hair is on fire and they don’t want to invest in learning new languages.  Trust me – I understand that deeply and we struggled with whether PowerShell needed to be a new language.  In the end, we decided that we could not deliver the right customer value without creating a new language but we did not do so lightly. 

Anyway – the commitment I made was to that I would do everything in my power to make that investment a GREAT investment with high payback.  Anytime I ask you to learn a concept, I’m going to use that concept over and over and over again so that you get a great ROI.  That is why we have 1 parser.  You learn our command line syntax and ALL PS commands use it.  That is why we are SUPER HARD CORE about the verb naming.  You learn our verbs and then you’ll be able to use them again and again and again (at the end of the day – we can’t "control" this but we do everything in our power to persuade teams to follow the standard).  That is why we have COMMAND FAMILIES where we define .NET interfaces for teams to implement and then we provide the consistent commands to go against multiple plugins.  In V1 we did that for navigation (e.g. filesystem, registry, cert store, etc) and in V2 we are extending that to EVENTS, TRANSACTIONS, and JOBs. 

There are dozens more examples but the one I’ll close on is the Common Engineering Criteria (CEC) which  requires all Microsoft Server products to ship PowerShell cmdlets going forward.  What this means is that your investment in PowerShell will be usable for ALL Microsoft Server Products.  If you’ve learned PowerShell from using Exchange, you are going to be able to use those skills to work with SQL and IIS and System Center and so on and so on.  They’ll all have the same syntax, the same naming, the same common semantics (like -WHATIF) and you’ll have a common language which can script across the products.

If you work with Microsoft Server products, you are going to be a PowerShell user.

Now with that concept fully in focus – if you don’t like something in PowerShell – you need to tell us.  We have a CTP of V2 out there and this is your opportunity to give us feedback and make PowerShell the best investment you’ve ever made.

Cheers!

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx