Don’t tell anyone I told you, but I think Microsoft sabotaged Windows PowerShell a few years ago because it was too powerful.
I mean, it can do everything. It can automate every Microsoft server product. It can even automate itself. Hundreds of vendors will go out of business because everything will be command-line and even the mighty Microsoft System Center will be useless.
For some people, fear starts to set in because they start to believe this. For others, they know better.
In Windows Server 2012, Microsoft made significant improvements in Windows PowerShell support. The number of out-of-the-box cmdlets (if you install all of the features) increased 10 times, from the 230s to 2,300s. But even with over 2,300 cmdlets, you still can’t do everything in PowerShell.
If you haven’t checked out Windows Server 2012, trying to find your way around with 2,300 cmdlets at your disposal might not be a walk in the park. For automated, repeatable tasks, all of the cmdlets will help you script a lot of things, but you’ll still want to fire up the UI to get something done quickly. I know I still do.
With Windows Server 2008 R2 Core, all you had was a console window on boot. Fortunately, you could install Windows PowerShell on this version, but even with its added functionality, it seems most choose to go with full OS installs with the UI.
Microsoft has added a nifty new feature in Windows Server 2012 allowing you to basically switch back and forth between the “UI version” and the “UI-less version” with just a reboot. If you’re looking to really minimize the need for extra hardware, running the UI-less version is the ticket, but what’s a few 100MB of RAM these days? Is it really worth the hassle of going back and forth?
You can automate everything in Exchange 2013 and Virtual Machine Manager 2012 using Windows PowerShell. But what does that really mean? Does that mean you can replace these products with Windows PowerShell? No! It’s just the administration interface to the products is 100 percent Windows PowerShell compatible. So when you’re clicking through the UI of these products, Windows PowerShell cmdlets are being called in the back end to interact with the core of the respective products to undertake various administrative actions. The core or engine itself it not written in Windows PowerShell.
I mentioned VMM 2012, but what about the System Center 2012 products? Well, these other products don’t have the same level of Windows PowerShell coverage. In the case of the other products in the System Center suite, Windows PowerShell support might be considered an afterthought because an SDK or WMI are wrapped up in cmdlets.
Windows PowerShell is very powerful. Can someone come along and use it to replace what System Center 2012 can do out of the box? Not in a lifetime. Windows PowerShell is meant to complement System Center, not replace it. You’re thinking about writing Windows PowerShell scripts to monitor systems? Prepare for a lot of work to get everything right, while this is what System Center 2012 Operations Manager does, and does it well out of the box.
You need to complement your Operations Manager 2012 monitoring with some specialized-use case scenarios through some automation? Use Windows PowerShell. You need to run some automated reporting from Configuration Manager 2012 and the built-in reports can’t help you? Use Windows PowerShell.
I think Windows PowerShell is the greatest thing ever to come to the Windows operating system. I was reminded just last week when trying to do string formatting in VBScript (I didn’t have any choice). But all things said, Windows PowerShell can’t do everything, and it’s not because Microsoft decided to hold it back.