No longer an optional extra, but a built-in part of Windows 7, PowerShell 2 enables administrators to manage the computers in the enterprise from both the command line and from scripts.
No matter how we try to get away from the command line, for many administrative and maintenance jobs for both individual PCs and for an office full of Windows 7 computers, when push comes to shove you can’t beat individual shell commands or reusable batch or script files. That’s why I was very happy to see Microsoft’s new PowerShell 2 baked into Windows 7 and Windows Server 2008 R2.
The single most important change in PowerShell 2 is that it is not just for individual computers, retro-fitted for administering multiple PCs. No, this version of PowerShell was designed from the beginning to manage networked PCs. In short, PowerShell is just as much for network administrators as it is for system administrators or PC technicians.
PowerShell is built on top of Microsoft’s .NET Framework. Its commands, or “cmdlets,” are actually .NET classes that invoke a PowerShell program, script (*.ps1), modules (PowerShell scripts that execute in its own environment without affecting the outside system), and executable file. The PowerShell user interface, which looks a lot like the old Windows DOS prompt, also lets you create aliases with familiar DOS command names for cmdlets. So, for example, you can still use “move” to move a file or directory even though “mv” is the PowerShell command.
PowerShell also uses that old Unix/Linux concept of pipelines to “pipe” or transmit the output of one command to be the input to another. Unlike Unix though, which uses character streams, PowerShell pipeline passes PowerShell Objects, which are all typed .NET objects, between cmdlets.
The end result is a programming language and environment that you can use to create quite complex programs. Administrators who also have .NET development experience will find PowerShell programming to come quite easily.
Putting PowerShell to Use
For those to whom coding doesn’t come easily, Microsoft provides a pair of tools to help them get up to speed. The first, PowerShellPack consists of ten PowerShell 2 modules. These let you set up everything from a user interface to a simple graphics editor.
What’s far more important for an enterprise administrator is that the PowerShellPack includes several ready-to-use modules such as PSUserTools (for adding users on a system, checking for elevation, and to launch an administrator session) and TaskScheduler (for setting up, managing, and deleting system tasks). These represent a big step forward toward easy remote administration without the need for a third-party program.
For administrators who really, really do not want to touch a command line again or to write out scripts by hand, there’s the PowerShell Integrated Scripting Environment (ISE). With the ISE, according to Microsoft, you can run “commands and write, test, and debug scripts in a single Windows-based graphic user interface with multi-line editing, tab completion, syntax coloring, selective execution, context-sensitive help, and support for right-to-left languages. You can use menu items and keyboard shortcuts to perform many of the same tasks that you would perform in the Windows PowerShell console. For example, when you debug a script in the Windows PowerShell ISE, to set a line breakpoint in a script, right-click the line of code, and then click Toggle Breakpoint.” To get a better idea of what PowerShell ISE looks like in action, watch this ITExpertVoice screencast.
Of course, to really get the most out of PowerShell 2, you’re going to need to get your hands dirty and code. Or, do you?
Microsoft provides numerous PowerShell guides, which have some of the best question and answer sessions with experts I’ve seen for any programming language. If you’re already a VBScript expert, Microsoft provides a guide for getting up to speed with PowerShell. Finally, Microsoft has an excellent collection of ready-to-use PowerShell scripts.
One thing I especially like about the Microsoft PowerShell script collection is that it’s easy to sort through them; you can find exactly what you need without much fuss or muss. For instance, I quickly found scripts for digging out User Object information from Active Directory; Creating an Active Directory User Object, and the ever-useful, List Inactive Computer Accounts in Active Directory. It’s worth picking up PowerShell just to use these automated scripts.
There are also several useful independent PowerShell script sites. Among the better ones are PowerShellCommunity, ScriptFanatic, and PowerShell Pro. (Know of some other good resources? Share them with the rest of us in the comments section.)
PowerShell 2.0 for the Administrator
Just at a glance at the sheer number of new PowerShell cmdlets that were designed with system manager and network administrators in mind is impressive. These include: Get-Hotfix, Send-MailMessage, Get-ComputerRestorePoint, Add-Computer, Rename-Computer, and Reset-ComputerMachinePassword. Maybe the day will yet come when we really can sit at our desks and remotely manage all our users!
OK, that’s a pipe-dream so long as users can manage to kick free their power-cords and insist that you come fix their “broken” computer. But, the richness of PowerShell 2′s commands does make it possible to do a lot of remote PC provisioning and management without stirring from your chair.
What makes this possible is PowerShell Remoting. This feature enables you to execute scripts to one or hundreds of remote machines. In addition, thanks to PSJob, you can run PowerShell commands, cmdlets, and modules in the background. Best of all, you can perform transaction operations that let you run cmdlets when certain conditions are met and roll them back if circumstances change.
PowerShell 2 supports two kinds of remote management: Fan-in and Fan-out. With the first, scripts are pushed to remote users as they log into a single corporate server. Once they are connected, the scripts run automatically. So, you could have your users automatically get their patches from a server when they login to the office network. In Fan-out remoting, which uses Windows Management Instrumentation (WMI) and Windows Remote Management (WinRM), commands and scripts are pushed out to PCs to run immediately.
I’ve only scratched the surface of what’s possible with PowerShell 2, but I think you get the idea. Scripting has never offered such powerful potential before for managing whole networks of Windows 7 and Windows Server 2008 R2 systems. In addition, since PowerShell 2 can be added to earlier versions of Windows, you can expand your PowerShell management tools across your entire Windows-based network.
If you’ve been avoiding scripting, it’s time to stop. These tools are exactly what you need to make managing even the largest networks much easier and less time-consuming. Enjoy.
Want more like this? Sign up for the weekly IT Expert Voice newsletter so you don’t miss a thing!