PowerShell 1.0 gave systems administrators around the world a new administration tool when it was introduced with Windows Server 2003.
For years, Microsoft has worked to develop a graphical user interface, or GUI, that would make system administration and user administration easier and more user friendly.
In many ways, the company succeeded admirably.
Most admins know at least one or two people who have managed to create a user in a very small Windows Server environment through User Manager and think that they should become a Windows Administrator because they already understand “how to do it.”
However, for administrators in environments where users exceed the number of people it takes to field a couple softball teams, things are more complicated. In fact, one of the difficulties of properly administering a networked operating system and its servers is keeping all the “little things” consistent across the enterprise. Forgetting a check-box here, and a radio button there, can add up to a security nightmare waiting to happen, or perhaps, a very angry Vice President unable to remotely connect at a critical time.
The solution to some of these problems has been scripting. By writing scripts, Windows system engineers could ensure that repetitive tasks happened correctly and with far less effort than doing them manually. Everything from creating new user accounts, to installing software and upgrades, to basic login scripts has been coded somewhere along the way by a savvy systems admin looking to avoid headaches and spend a little less time on repetitive tasks.
Eventually, new Windows Server features and enhancements began to outstrip the capabilities of the DOS-based scripting that server administrators had been cobbling together. Fortunately, new tools and utilities were also developed that helped reduce some of the reliance on login scripts. For example, User and Group profiles have long since made mapping drive letters via login script obsolete. However, administrators still needed a more powerful scripting environment.
PowerShell has been slightly underrated within the administrator community. One reason is that in order for PowerShell to really perform throughout the enterprise, it needs to be usable on the servers and all the desktops.
Fortunately, Windows 7 comes ready to execute PowerShell scripts. Windows 7 SP1 is set to ship in the near future, which sounds the bell for many long-time IT professionals who live by the rule to always wait for SP1 before upgrading, and Server 2008 R2 comes with PowerShell 2.0 installed by default. As Windows 7 is installed in the enterprise, PowerShell 2.0 will grow even more useful.
Another reason PowerShell has not gotten its fair share of affection from systems administrators is that there were a few nagging things about how PowerShell worked conspiring to make it seem less powerful than it actually was. However, Microsoft has addressed many of these issues and thrown in a few new features as well.
Let’s take a look at some of these new features now.
Nothing has been a bigger thorn in the side of PowerShell than Remoting. Remoting is the ability to run commands via PowerShell on remote computers. Technically, some remoting was possible in PowerShell one, but it was limited to the Get-WMIObject cmdlet within Windows Management Instrumentation (WMI). Even worse, WMI required RPC connections which meant having to go to the networking guys to get ports opened and firewall exceptions allowed. Not fun.
PowerShell 2.0 allows administrators to run commands on remote computers using the WS-Man (WS-Management) protocols which establish secure connections to remote computers using ports 80 and 443 by default. In many environments these ports will already be open, and in those that they are not, they’ll be a much easier sell to the networking team.
There is one little catch to remoting in PowerShell 2.0. In order to use remoting, it must be enabled on both machines. However, this only needs to be done once. Once enabled, remoting can be used on multiple machines at the same time allowing the administrator to execute the same commands on several computers at once. The applications for this ability are limited only by the admin’s ability (and the availability of the right cmdlet).
Speaking of cmdlets, PowerShell 2.0 comes with over 100 built-in cmdlets. While this covers a lot of ground, there is no doubt that Microsoft Server administrators will quickly find functions and tasks that require other commands. Fortunately, Microsoft has implemented a way to handle this eventuality as well.
Modules are also new to PowerShell 2.0 and allow script developers to organize code into self-contained reusable units. This functionality has already been used to create a PowerShell 2.0 Active Directory Module which brings more possibilities to managing Active Directory via PowerShell.
Another big addition to the PowerShell feature set is the ability to run background jobs. This means that those PowerShell scripts that take a long time to run can continue to perform in the background while the command prompt returns control immediately to the console.
An admin performing numerous tasks late at night can get them all running right away instead of having to wait until 2:00 AM to run that last command. This is especially useful while remoting multiple machines, especially when those machines are separated by various network connection speeds.

PowerShell 2.0 now offers the ability to monitor and act on system events which can allow for more proactive scripting.
The most curious edition to PowerShell 2.0 is the PowerShell GUI, which, on the surface, appears to defeat the whole point of PowerShell. However, the GUI is really more of a basic script editor complete with color coded syntax, partial execution, stepping, and graphic debugging. The GUI also includes context sensitive help which can save admins from scanning through the verbose output of some help commands.
With Windows 7 coming to many businesses in the near future and the upcoming release of Windows Server 2008 R2 SP1, PowerShell 2.0 will be already waiting to go for enterprise-wide control and administration. The time is now for Microsoft systems engineers and administrators to learn how to take advantage of PowerShell 2.0.
Take a look at the video below to see a short demo of PowerShell 2.0.
Scotty Says:
May 14th, 2010 at 12:27 pm
Hi Brian,
Yup Powerhell 2.0 is really cool, especially the ability to monitor and act on system events, which can help react quickly and in an automated fashion.
I work mostly on Active Directory related scripts and am starting to use PowerShell for Windows Server Management as well, and find it very helpful.
Thanks for sharing your thoughts in this regard.
Best wishes,
Scotty
Brian Nelson Says:
May 26th, 2010 at 10:42 am
Scotty,
Thank you for your comment.
Keep an eye out for upcoming articles on using PowerShell 2.0 with the new Active Directory Module which will make your life even better. It might even make you richer and better looking.
Brian
(Note: Management makes no warranties regarding the improvement of wealth or appearance from using PowerShell with or without the Active Directory module.)