Getting Started With Windows PowerShell 2
PowerShell 2 shipped with Windows 7 and Server 2008 R2. It is a command-line shell and scripting language built on .NET, and it replaced the old cmd.exe batch scripting model for most administrative tasks. If you are running anything older than that, you need to install it manually. On Windows 7, it is already there unless someone disabled it. You can verify by opening a prompt and typing Get-Host or $PSVersionTable.PSVersion. If it returns 2.0, you are good. If you get an error about scripts being disabled, you have a execution policy problem. The "For Dummies" angle here is simple: start with the cmdlet naming convention. Everything follows a verb-noun pattern. Get-Process, Get-Service, Get-ChildItem. The verb is consistent across modules. Once you learn that "Get" means pull data and "Stop" means kill something, the syntax starts making sense without any memorization. The pipeline is what makes it different from cmd.exe. You pipe output from one command into another using the | character. This is the single most useful mechanic in the entire shell. Here is the basic flow:
Get-Service | Where-Object {$_.Status -eq 'Stopped'} | Stop-Service This finds all stopped services and stops them. Wait, that does nothing useful since they are already stopped. But you get the idea. I used this exact pattern during a server migration once — we had about forty Exchange 2007 servers to patch, and I scripted a pipeline that pulled service states, compared them against a baseline XML file, and generated a conflict report. Took maybe twenty minutes total instead of dragging it out over two days of manual checks. One thing beginners miss is that PowerShell 2 uses Where-Object (aliased as where) with script blocks. In later versions, the simplified syntax was introduced. In v2, you must write {$_.Property -eq 'Value'}. The $_ represents the current object in the pipeline. If you skip the script block and try something like Get-Process | where Name -eq 'notepad', it will fail silently or throw an error. Stick to the full syntax.
Execution policy is the next hurdle. By default, Windows sets it to Restricted, which blocks all scripts from running. You can check yours with Get-ExecutionPolicy. To change it, run Set-ExecutionPolicy RemoteSigned as Administrator. This allows local scripts to run and only requires signed scripts from remote sources. It is the sweet spot for most admin work. Never set it to Unrestricted unless you understand the security implications — and even then, it is usually unnecessary. Help system is built in. Get-Help Get-Process gives you the full documentation right there. Add -Full for examples, or -Online to open the web version. This is not optional — read the help before you try to use a cmdlet. I once spent three hours debugging a script only to realize I had been passing the wrong parameter name because I never checked -Full. The parameter was -ComputerName, not -MachineName, and the error message was not exactly helpful about it. Remoting is available in PowerShell 2 but it is finicky. You need to enable it with Enable-PSRemoting on each machine, and WinRM must be running. It works across domains if your GPOs are set correctly, but within a single workgroup, you need to configure trusted hosts manually. Run Set-Item WSMan:\localhost\Client\TrustedHosts -Value '192.168.1.50' to allow connections from a specific IP. Without this, Invoke-Command will just hang and give you nothing.
Get the Full Details
Here is a practical workflow most people find useful on day one: Get-WmiObject -Class Win32_Process -ComputerName 'SERVER01' | Select-Object Name, ProcessId, WorkingSetSize | Sort-Object WorkingSetSize -Descending This pulls process info from a remote machine, formats it, and sorts by memory usage. It replaces ten separate queries you would have run in the old command prompt era.
A few things to keep in mind. PowerShell 2 is old. It does not support some of the newer syntax features like ConvertTo-Json (that came in v3), Try-Catch-Finally blocks for error handling are more limited, and Out-GridView is essentially broken in many environments because it depends on Windows Forms which may not be properly registered. If you are writing scripts that need to run across multiple Windows versions, stick to v2-compatible syntax. Anything newer will break on Windows 7 machines. Another quirk: the dot-sourcing behavior for variables. If you run a script that sets a variable and exit, that variable does not persist in your session. You have to dot-source it with a leading period: . .\myscript.ps1. This catches people off guard constantly. If you need to download or install PowerShell 2 on an older system, Microsoft's official download page archived the required packages. Look for the Windows Management Framework 2.0 download — it includes PowerShell 2, WMI enhancements, and the new PSDrives. Be aware that installing WMF 2.0 on top of an existing system can sometimes conflict with later updates, so check your installed hotfixes first.
For reference materials, the official Microsoft documentation at docs.microsoft.com has archived PowerShell 2 pages. The book "PowerShell in a Month of Lunches" covers v2 concepts well even though it was written for slightly later versions. And the built-in help system I mentioned earlier — use it religiously.
