When Microsoft first introduced Windows PowerShell in 2003, many IT administrators considered it just another method for scripting tasks and managing Windows servers. But over time, it has become the tool of choice for managing, monitoring and scripting different types of hardware and software. Many vendors have embedded PowerShell into their products, and Microsoft made it a core management platform for desktops in Windows 7.
The first version of PowerShell couldn't run scripts or query against remote computers from a central workstation or server. However, in the latest release -- installed by default in Windows 7 and Windows Server 2008 R2 -- Windows Remote Management (WinRM) allows for centralized management with a "single pane of glass" architecture. (Note: The newest PowerShell version can also be downloaded for Windows XP and Vista.)
While some enterprises may have at least one third-party product that does what PowerShell can do, most of them require the installation of an agent. PowerShell, on the other hand, is native to the operating system and is a scripting language, so it can be a powerful asset even with other products.
Getting started using PowerShell for desktop management
The first step for overall management control is to make sure your desktops are running the latest version of PowerShell with WinRM enabled.
To enable WinRM, execute the following command as the local administrator from the local machine's PowerShell prompt:
This also opens the appropriate firewall ports for communication with the central management workstation. The workstation is now ready for remote PowerShell commands and queries.
In addition, you should set the security of running scripts by entering the following as the local administrator:
Of course, depending on your security requirements, you may choose a different security level for script execution, such as RemoteSigned. This ensures that any scripts you run in an interactive session will be executed without error. You can learn more details on the settings -- and their ramifications -- by running help Set-ExecutionPolicy –detailed at the PowerShell prompt.
There are three ways to work with remote computers from a central workstation via PowerShell remoting. The first allows for one or more machines to be queried; the other two are more for one-to-one sessions. The "Invoke-Command" method is the one most commonly used. "Interactive" is similar to a Secure Shell or Telnet session to the remote machine, and "Implicit" imports a remote PowerShell session into the central session.
Working with native PowerShell cmdlets
The newest version of PowerShell has more than 30 cmdlets for sending remote commands to workstations. Almost all native cmdlets that accept the –ComputerName parameter will send remote commands to any desktop that has WinRM enabled.
For example, the command Get-EventLog – Logname Application –EntryType Error –ComputerName mypc retrieves the application event log entries that contain the event type of error from mypc. You can extend the –ComputerName parameter to include multiple targets, such as –ComputerName mypc, suzipc, tompc.
You could also use the scripting language power of PowerShell to turn the parameter into a dynamic variable. You could then run remote commands against hundreds or even thousands of desktops.
A native cmdlet I often use is Get-Counter, which lets you see, in almost real time, the performance measurements of the remote computer. Apply this cmdlet with an extended list of remote computers or via a dynamic variable to view the counters for all the machines in your organization. Type help get-counter –full at a PowerShell prompt to find the syntax applicable to your situation.
In addition, you can perform inventory functions on the remote machine. For software inventories, query a WMI Class for all .MSI installed software using the Get-WMIObject cmdlet. For software not installed via an .MSI installer, simply query the registry for all software entries. This TechNet article is an excellent resource for building your own software inventory tool.
For hardware inventories, you would use another WMI query that specifies the hardware classes. See this PowerShellPro article for a script that I have used several times.
Free tools that help with PowerShell scripting
Using cmdlets from the command line is second nature to administrators who live in the scripting world. But for admins without a lot of experience with the command-line interface (CLI) -- or for those who want to avoid extremely long "one-liners"' -- the free tool PowerGUI by Quest Software can be helpful.
This product is a graphical user interface (GUI) front end to PowerShell. One of its best features is its use of PowerPacks, which are created by scripting gurus and compiled into a single file. After you import these scripts, PowerGUI enters the PowerShell commands for you. You can see the actual scripts in the included ScriptEditor and use them to build your own.
Once you master the PowerShell environment for your remote desktops and start to feel brave in your scripting, I recommend looking at Sapien's PrimalForms for incorporating your scripts into a GUI (it even has a free version). With PrimalForms, you can put a graphical front end on your scripts for yourself or for others who don't feel comfortable in the command prompt. For example, the GUI front end to several scripts that I created has become a staple on the desktops of several help desk admins. An excellent step-by-step example of creating PowerShell GUI with PrimalForms is available at NTPRO.NL.
There are thousands of resources for PowerShell and PowerShell scripts. Be sure to check them out before creating your own script. Most of the time, someone has already written a script to do exactly what you need, or you can find a script that you can customize.
About the author:
Mike Nelson has been in IT for over 20 years and had exposure to a very diverse field of technologies. He has devoted over half a decade to virtualization and server-based computing. Nelson is currently a senior analyst at a Fortune 100 company in the U.S. Midwest.
This was first published in April 2011