Automating the world one-liner at a time…
The Buddha once said that, “A jug fills drop by drop”. In this case, the jug is universal PowerShell cmdlet coverage which is a really large jug! We’ve never been confused on this point – I’ve often referred to it as the “30 year hole” that we needed to dig ourselves out of. When PowerShell V1 shipped, it had a very small number of cmdlets. It was mostly used by advanced scripters to script their own solutions. Soon afterwards, the Exchange team released 400+ cmdlets and then it was reasonable for Exchange admins to manage their Exchange tasks. Quarter by quarter, release by release, more and more teams shipped cmdlet support or extended the cmdlet support they had already shipped and the bucket got more and more full.
That is a great bit of philosophy but the reality is that if you need cmdlet coverage and it isn’t there, you are sucking wind. If your job involves working much with PKI, you know what I mean. Today you have to run certutil.exe and parse the output or just use the GUI.
With that, it’s time for another great phrase, “Nature abhors a vacuum”. Where there is a need, the need get’s filled over time. Sadly, the OS release cadence means that vacuums can exist for a while which is why god invented the community. Quest – the superstars that brought us the first AD cmdlets and PowerGUI have just released a new set of PKI cmdlets. These are part of their QAD cmdlets so they are FREE and available without registration.
How could you improve on that? Well, they also published a comprehensive PDF doc on PKI and PKI management with PowerShell as well as a PowerPack for PowerGUI.
With these cmdlets, the number of things that become easy to do with PowerShell grows yet again. If it was hard to use PowerShell yesterday because you didn’t have PKI support, now it is easy. Drop by drop, the jug fills. Day be day, more and more users will find that PowerShell meets their needs.
Jeffrey Snover [MSFT] Distinguished Engineer 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
The "OS release cadence" line made me wince in general. Does that mean we shouldn't expect a V3 until Windows 8 ships?
The 'Vacuum' is known to spontaneuously generate pairs of paritcles. Perhaps it also generate CmdLets.
@Blake - Until the "next release of Windows" - yes that is correct. Now you know why we are so hard-core about extensiblity and why we are so excited by Script Cmdlets - they allow anyone to produce their own cmdlets.
@jv - Virtual pair production. Crazy cool stuff, especially Hawking's theory about how VPP around the event horizon of a black hole leads to them exploding. Let's hope there is no such equivalent in the PowerShell space. :-)
Jeffrey Snover [MSFT]
Visit the Windows PowerShell Team blog at: blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: www.microsoft.com/.../msh.mspx
Ahem, both DirectX and .Net teams release their products out-of-sync with Windows versions. And especially DX is a very major component of the OS. Why PowerShell cannot do the same? After all, let be honest, it consists of 2-3 dlls sitting in the GAC, some text files containing the help and 1 executable. Doesn't seem very hard to upgrade every 3-4 months, as DX team does.
@Teo - the internal workings of Microsoft can sometimes be as mystifying to people inside the company as they are to those outside. I can guarantee you 2 things:
1) If we could ship more frequently, we would.
2) You don't want the details of how the sausage is made.
i agree with "until the next release of Windows"
But i think you shouldn't leave PowerShell Pack(Resource Kit) for One year or more.
Jeffrey, I did not mean to offend. I am working for a very small company and we have quite funny inter-dependencies among our products, so I can imagine that PowerShell situation would be even trickier. But I hope that you (the PS team) can work out some way to continuously improve PS and ship a new release more often and more regularly (say once 6 months or similar).
I agree with "Smith Catar"....pushing packets of functionality as was done with the PowerShell Pack would be awesome (and instructive).