Recently, I was wondering how much code I would need to do basic hardware and software inventory on several remote systems. After experimenting a little bit I came up with the following line of code:

Get-Content pcs.txt | foreach { Write-Host $_ -f Green; $pc=$_; Get-Content wmi.txt | foreach { Get-WmiObject $_ -ComputerName $pc } }

That’s right! Just one line of code.

I’m reading the computers from a text file (pcs.txt). Then I use a foreach-clause to iterate through the list of pc’s. Write the name of the PC on the screen in green to easily identify which system we’re processing. Then I’m reading the different elements to report on from another text file (wmi.txt). For the current system in the loop I’m running a Get-WmiObject on all the items from the second text file and write that on the screen also.

I have to store the name of the current PC in a variable with the command $pc=$_ because I’m entering a nested loop. Whithin the nested loop $_ get’s filled with the current WMI-class, instead of the current PC. I can still refer to the name of the PC through the $pc variable.

Here are both textfiles. They’re just examples, feel free to supply your own items.
wmi.txt:
Win32_Bios
Win32_LogicalDisk
Win32_OperatingSystem

pcs.txt:
server1
server2

Here’s the same line of code but the using the shortest possible notation:

gc p|%{Write-Host $_ -f Green;$p=$_;gc w|%{gwmi $_ -Co $p}}

Sixty characters! I’m really pushing my luck here doing nasty things like abbreveating parameters (-Co instead of -Computername), using all sorts of aliases (gc for Get-Content, % for ForEach, and gwmi for Get-WmiObject) and using textfiles with a name of just one letter. But hey, for the purpose of writing the shortest line of code, it will do!

Let’s get serious again. PowerShell chooses a different layout than you would expect. To compensate, just use Out-Default.

Get-Content pcs.txt | foreach { Write-Host $_ -f Green; $pc=$_; Get-Content wmi.txt | foreach { Get-WmiObject $_ -ComputerName $pc | Out-Default } }

With Out-Default you can’t write to a text file anymore. Instead of Out-Default, consider using Out-File to create a report.

Get-Content pcs.txt | foreach { "===== Computer $_ ====="; $pc=$_; Get-Content wmi.txt | foreach { Get-WmiObject $_ -ComputerName $pc } } | Out-File report.txt
 Invoke-Item .\report.txt

When you want to use computers from Active Directory the script becomes a little bit different. Be carefull when running this command in a production environment! Escpecially when it’s large!

Get-ADComputer -filter * | foreach { $pc=$_.dnshostname; Write-Host $pc -f Green; Get-Content wmi.txt | foreach { Get-WmiObject $_ -ComputerName $pc } }

Don’t forget to import the ActiveDirectory module if you’re still running PowerShell 2. PowerShell 3 loads this module automatically for you if it’s installed. Check wheter the AD-module is installed with this command:

Import-Module ServerManager; Get-WindowsFeature RSAT-AD-PowerShell

If you don’t want to use any textfiles at all then use this peace of code:

$wmi = "Win32_Bios", "Win32_LogicalDisk", "Win32_OperatingSystem"
Get-ADComputer -filter * | foreach { $pc=$_.dnshostname; Write-Host $pc -f Green; $wmi | foreach { Get-WmiObject $_ -ComputerName $pc } }

Using the new outputmode of Out-GridView in PowerShell 3 we can list the computers graphically, select several of them, and after the press of the OK button only the selected systems are processed.

Get-ADComputer -filter * | Out-GridView -OutputMode Multiple | foreach { Write-Host $_ -f Green; $pc =$_; Get-Content wmi.txt | foreach { Get-WmiObject $_ -ComputerName $pc } }

And here’s an example script file:

# create a collection of interesting WMI classes
$wmi = "Win32_Bios", "Win32_LogicalDisk", "Win32_OperatingSystem"

# get computers from AD, feel free to change the filter
Get-ADComputer -filter * |   foreach {
  # store the dnshostname for reference in the next loop
  $pc=$_.dnshostname

  Write-Host $pc -ForegroundColor Green

  # send the collection of WMI-classes into the pipe
  $wmi |       foreach {
    # run Get-WmiObject on the computer currently stored in $pc
    Get-WmiObject $_ -ComputerName $pc
  }
}

There are a lot of other interesting WMI-sources. Consider these for your WMI-selection:

Win32_Account
Win32_Battery
Win32_Bios
Win32_BootConfiguration
Win32_ComputerSystem
Win32_DiskPartition
Win32_Environment
Win32_LogicalDisk
Win32_NetworkAdapter
Win32_OperatingSystem
Win32_Printer
Win32_Processor
Win32_Product
Win32_ScheduledJob
Win32_Service
Win32_Share
Win32_TimeZone

Please send me a message if you have any questions.

Good luck!

Dimitri

PowerShell 3 has launched! Since september 4th you can download the final (RTM) release of PowerShell 3 from this link:

http://www.microsoft.com/en-us/download/details.aspx?id=34595

Some of the best new features include:

• Automatic module loading, no more “import-module” required
• Lot’s of extra modules like DHCP, DNS, iSCSI, NetAdapter, NetTCPIP, Printing, ScheduledTasks, SMB, and many others.
• Few syntax changes. Get-Process | Where-Object { $_.vm -gt 150MB } can now be written as Get-Process | Where-Object vm -gt 150MB
• Integrated Scripting Environment (ISE) includes Intellisense, code folding, brace matching, code snippets, block select and much more!
• Show-Command let’s you use cmdlets in an interactive way.
• Out-GridView now has a -OutputMode parameter! That’s really awesome! For example: Get-Process | Where vm -gt 150 MB | Kill -confirm can now be written as: Get-Process | Sort vm -Descending | Out-GridView -Outputmode multiple | Kill. This means you don’t have to experiment with the parameters (like the VM-size of 150MB) to get the correct processes. And you can confirm in the GUI! What about the Active Directory recycle bin combined with Out-GridView? I’ll write a post about that very soon.
• Workflows. This is an excerpt from the documentation: “To author sequences of multi-computer management activities — that are either long-running, repeatable, frequent, parallelizable, interruptible, stoppable, or restartable — as workflows. By design, workflows can be resumed from an intentional or accidental suspension or interruption, such as a network outage, a reboot or power loss.” More info: http://blogs.msdn.com/b/powershell/archive/tags/powershell+workflow/
• And one of my favorites: PowerShell WebApplication. This installs an IIS website where you can use PowerShell commands through a webbrowser. Internet Explorer required, you think? Google Chrome, Firefox, Safari are all supported!

I would recommend to install PowerShell 3 as soon as possible. If you’re concerned about backward compatibility then stay away from the syntax changes and new modules. But start using the ISE today. It’s awesome!

Dimitri

By the way, there’s also a new alias for select-string: sls. It should have been grep, if you ask me…  ;-)

There are some situations where you want to boot a remote computer that’s powered off, but don’t have the tools to do that. For example: Microsoft SCCM allows you to boot a remote computer (wake it up from power off) to install Windows Updates. If you don’t have SCCM there are thousands of alternative software solutions, but we cannot trust most of them, right?

Look no further! We can power on remote computers through PowerShell! The script demonstrates how to remote boot a PC with a UDP packet we’re creating through the System.Net.Sockets.UdpClient programming interface (part of dot Net).

Just replace the MAC-address with the address of the computer you want to boot, start the script, and boot!

$MacAddress = [byte[]](0x00, 0x25, 0xB3, 0x0D, 0xA8, 0xF9)
$UDPclient = New-Object System.Net.Sockets.UdpClient
$UDPclient.Connect(([System.Net.IPAddress]::Broadcast),4000)
$packet = [byte[]](,0xFF * 102)
6..101 | foreach { $packet[$_] = $MacAddress[($_%6)]}
$UDPclient.Send($packet, $packet.Length)

PowerShell provides some commands to manipulate services, but that doesn’t work on remote computers! The script you can find below demonstrates that stopping a service on a remote computer using Stop-Service is not working.

First I verify that the MSDTC service is running on the local machine and a remote machine: server2. If I want to stop the service on both machines I use the Stop-Service cmdlet. But this command doesn’t work on server2 when I’m piping the output from Get-Service to Stop-Service!  :-(

There are two solutions. The first is you can use the InputObject parameter as part of Stop-Service.

You can also use WMI to stop a remote service.  Just retreive the specific service from a remote computer by using the Get-WmiObject cmdlet and use the StopService method to stop the service.

WMI is intended to work remote so this command gives the correct result!  :-)

"Verifying services"
Get-Service MSDTC
Get-Service MSDTC -computer server2
"Stopping services"
Get-Service MSDTC | Stop-Service
Get-Service MSDTC -computer server2 | Stop-Service   # Stop-Service does not accept pipelined input!
"Verifying services."
Get-Service MSDTC
Get-Service MSDTC -computer server2
"Stopping remote service, alternative"
Stop-Service -InputObject (Get-Service MSDTC -ComputerName server2)
"Stopping remote service using WMI"
(Get-WmiObject win32_service -computer server2 | Where { $_.name -eq 'MSDTC' }).stopservice()

Thanks to Martin Tengvall for pointing out the -InputObject variant.

It’s possible to compress a folder or file since Windows NT. It’s a feature of the NTFS-filesystem. Normally we would do that on the properties of the folder or file in the Windows Explorer, but you can do this with PowerShell too! Just use this command:

Invoke-WmiMethod -Path "Win32_Directory.Name='C:\Test'" -Name compress

And to Uncompress the same folder, use this command:

Invoke-WmiMethod -Path "Win32_Directory.Name='C:\Test'" -Name uncompress

We’re talking about NTFS compression here, not the ZIP-feature introduced in Windows XP and later. You can notice that the folder is compressed by the blue color of the folder in Windows Explorer. Or you can open the properties of the folder to see whether the size on disk is smaller than the normal size. Do not try to compress items that are already compressed, like pictures (JPG…), music (MP3…), video (AVI, MPG…).

When you use WMI to execute operating system functions like this, you get a return value. When the return value is 0 (zero) this means the command functioned. Other return values can mean different things (read-only, no disk space, no permissions,…). In general: when we’re executing WMI-commands we’re allways checking the return value. You could implement it like this:

$a = Invoke-WmiMethod -Path "Win32_Directory.Name='C:\Test'" -Name compress
If ($a.returnvalue) -eq 0 { "Items successfully compressed" } else { "Something went wrong!" }

The other day I stumbled upon a nice PowerShell command to use the speech API found on modern Windows Operating Systems. With this script PowerShell can talk to you! Great for situations where you want to hear about the progress of your script. Or maybe to tell you there’s an alert instead of showing the alert. Here’s the script:

$a = New-Object -COM SAPI.SpVoice
$a.speak("I'm completely operational, and all my circuits are functioning perfectly.")