Think of it as DOS on steroids--PowerShell is great for batch importing or deleting large sets of user accounts and will let you collect a massive amount of detailed system information in bulk via WMI. Those who prefer to manage via the command line will be immediately comfortable, and our tests show there are major efficiency gains to be had.
Will admins who resist turning their Windows environments into Unix wannabes by scripting everything to the nth degree via a shell survive just fine without it? Probably, with one exception: If you plan to implement Exchange 2007, you should start learning PowerShell now because it's a required component for management.
If you're running Windows Server 2008, you have PowerShell as an installable option. Those with Windows 2003, XP, or Vista can download it as a standalone installation. Development of PowerShell, formerly code-named "Morad," started in 2003 with a primary design goal of providing more robust scripting and automation of complex and repetitive system administration tasks. The first beta of PowerShell surfaced in the wild in June 2005, and nuts-and-bolts administrators took to it immediately.GET 'THE GLUE' Now, almost three years later, mainstream Windows Server types are finally taking notice, partly because of the blogosphere's excitement at PowerShell's capabilities, partly because of Microsoft's marketing and education efforts. Redmond affectionately refers to PowerShell as "the Glue" because of its ability to bridge many technologies to accomplish a variety of tasks.
Because it's based on the .Net Framework, Windows PowerShell has syntax features and keywords that are similar to those used in C#. What makes it a viable tool for nonprogrammers are Microsoft's Cmdlets. Cmdlets are much like executable programs, and for sim- plicity, are usually named with a verb-noun structure. The power comes when you glue several Cmdlets together; take item No. 1 in our list of cool PowerShell tricks (see "10 Cool Things To Do With PowerShell"). The verb/noun combination of Get and WMIObject tells PowerShell that you'd like to query the WMI namespace. The parameter following the Get-WMIObject Cmdlet makes a call to the Win32_Service class and makes all the running services on the local computer fly across your screen like the Matrix. Fortunately, by piping the output of the previous command to other Cmdlets, we can control what data is reported back to us in PowerShell, in true Unix-like fashion.