Rolling Review: Windows 2008 Server PowerShell

Gotchas From The
Test Lab

BEFORE YOU CAN EXECUTE PowerShell scripts, you need to modifythe default script execution policy. Type "help Set-ExecutionPolicy" at the PowerShell prompt for detailsAFTER INSTALLING PS 2.0, .Net 2.0, and WS Man 1.1, be sure to run the "configure-WSMan.ps1" script from PowerShell to configure PS Remoting on the local computerIF YOU'RE RUNNING IIS on the local computer, be sure to shut down IIS and turn up the Windows Remote Management service—running scripts remotely might not work otherwiseTO RETURN A LIST of all the classes available in the "Get-WMIObject" Cmdlet, type "Get-WMIObject -list"

The second installment of our Windows Server 2008 Rolling Review focuses on Microsoft's unified scripting tool and operating environment, Windows PowerShell. In our first installment, we pitted Citrix XenApp against Windows 2008 Terminal Services, but in this case, PowerShell stood alone in our Boston Real-World Labs. Are there commercial packages that can do everything PowerShell can? Sure, but they'll cost you. PowerShell is free and represents a big change in how Microsoft server technologies are administered.

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.For example, consider command No. 2. Starting after the pipe, we ask PowerShell to parse the results and return to us only the name and running state of all services on the local computer. Let's further suppose we want to display only the running state of all of the MS SQL-related services running on a host whose server name is SQLServer: Just add:

| Where-Object {$_.Name -match "MSSQL"}

The output of this command is a short and sweet display of all MS SQL related services and their running conditions. We found the PowerShell syntax quickly became second nature. In contrast, a similar VBScript script would be difficult to write and debug in a timely manner without a great deal of experience. And single-line PowerShell statements can be saved as scripts and invoked at any time.

While PowerShell 1.0 is a powerful tool, it has some serious limitations. The most glaring is that, because remote access to other systems in PowerShell 1.0 is limited to information that can be gathered via WMI queries, we were unable to remotely manage and kill system services and processes.

Microsoft's release of a Community Technology Preview version of PowerShell 2.0 addressed many remote administration issues via WS-Management version 1.1, or WinRM. Sometimes called PowerShell Remoting, WinRM provides a command-line interface that you can use to perform common management tasks. Under the hood, WinRM is a Web services-based protocol that uses HTTP and HTTPS for transport, and is therefore firewall friendly. Because WinRM uses ports 80 and 443 by default, you may need to do some tweaking of services that might lock up Port 80.Before you take the CTP version of PowerShell 2.0 for a spin, you'll need to uninstall PowerShell 1.0--the hardest part of the upgrade--and install .Net 2.0 and WS Management 1.1. PowerShell 2.0 runs on x86 and x64 platforms of Windows XP-SP2, Windows Server 2003-SP2, Windows Vista, Windows Vista-SP1 Beta, and Windows Server 2008 RC0 and above. In addition to the new Remote administration capabilities, PowerShell 2.0 delivers a GUI-based shell environment that loosely resembles a simple developer's workspace. To use the GUI version of PowerShell 2.0, you'll need to install .Net 3.0.

While PowerShell is a terrific tool for remote administration, we wondered if we could solve other problems more quickly in the 2.0 version than in the GUI, or perform tasks more efficiently than with a resource kit utility. As we looked at the various bags of tricks that exist in cyberspace, it became clear that PowerShell's real value comes from being able to script and automate arduous, complicated tasks.

For example, we manage a large number of servers and wanted to see a consolidated list of stop errors, on demand and in a spreadsheet. With two lines of code, we were able to load a text file containing the host names of 25 servers in our lab environment, query each for a list of stop events generated in the system log in the past day, export the data to a spreadsheet, and automatically launch Excel to display the info. Pretty impressive for two lines of code. In another time-saving scenario, we were able to do a bulk import of 25 user accounts into Active Directory and easily populate those accounts with the appropriate user properties.

Finally, we found that PowerShell excels in file system administration. Say you're looking to clean up disk space--it's a snap to build a script that can search for files over 100 MB and export that data for easy viewing in Excel.

In the next edition of our Longhorn Rolling Review, we'll take an in-depth look at Server Core and reveal the advantages, and the gotchas, of this new installation option for Windows Server 2008.

10 Cool Things To Do With PowerShell

1. NUMBERS, PLEASEReturn only the serial number and version of the BIOS of your system, collected from the Win32_BIOS class
Get-WMIObject Win32_BIOS | Select-Object SerialNumber,Version2. STATE OF THE UNIONList the services running on the PC; select and display service name and running state
Get-WMIObject Win32_Service | Select-Object Name,State3. MAIL CALL

List services running on a remote system named "email"; select and display service name and running state
Get-WMIObject Win32_Service -computername email | Select-Object Name,State

4. RECENT HISTORYQuery and return the 100 most recent events in the system log for any events of type "Warning"
Get-eventlog -newest 100 -logname system | where-object {$_.entry Type -eq "Warning"}5. KILL SWITCHKill the Excel process running on the local computer
Get-Process | Where { $_.Name -Eq "Excel" } | Kill6. TESTING 1,2Use WSMan to remotely execute the Get-Service Cmdlet on a host called "testPC"
Invoke-expression -command "Get-Service" -ComputerName testPC7. ON THE RUNUse WSMan to list all running processes on a remote host called "test PC"
invoke-expression -command "Get-Process" -ComputerName testPC8. NINJA MAN

Use WSMan to remotely kill the Excel process on a host called "testPC"
invoke-expression -command "Stop-Process -processnameExcel" -ComputerName testP

9. STOP THE PRESSESRemotely stop the print spooler service on a host called "testPC"
invoke-expression -command "Stop-Service -displayname 'Print Spooler'" -Computer-Name testPC10. AT YOUR SERVICEOne of our favorites, this two-line command exports a list of allservices to a csv file, and then launches Excel to display the data
Get-Service | Export-CSV c:Processes.csv < enter > Invoke-Item c:Processes.csv

0