Automating the world one-liner at a time…
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.
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 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.
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
"If you work with Microsoft Server products, you are going to be a PowerShell user."
While I'm a proponent of technical change and refreshes for the sake of consistent improvement, this statement is over-reaching to say the least.
At a basic level, PowerShell is about economies of scale and squeezing more efficient methods out of existing employees whose jobs consist of executing commands. But for basic scenarios that have zero scalability issues to consider, it's just not that important to know the language. The higher level GUI tools suffice and big bad Google provides instant results for the cmdlets that SHOULD have a GUI equivalent but don't.
Now if you have plans to ship server products that stop offering GUI interfaces and provide nothing but a CLI, I'll consider proactively learning PowerShell, but win2k8 server core doesn't count because again it's built for the mega-enterprise environment and it's a choice that the business makes when they still have the option to use win2k8 with explorer shell.
Also have yet to see any job listings on the open market requiring PowerShell experience.
Jeffrey, you are super hard core. :D
As a server admin, I also need to occasionally write Excel macros, HTA's, ASP(X) pages, compiled code, and management scripts. For me the various flavors of VB make sense because I can us the same base skillset across all environments.
None of the 10 admins on our server team have C/C++/C# skills. We are not full time programmers. What was wrong with a VB based PowerShell language?
Hi i want to start process and monitor a number of machines asyncronously from one machine.
How can i achieve this in powershell?
I would be glad if ASAP