Test Subnet with PowerShell

keyboardanalyzeA few years ago I published a PowerShell function to test IP addresses on a given subnet. I had an email the other day about it and I decided to refresh it. My new version adds a few bells and whistles that I think you might like. For example, you can now run it from a remote computer. In other words, you can ping IP addresses from another computer which might be helpful.

I’ve also added an option to resolve the IP address to a hostname using DNS. Because I don’t want to require anything on a remote computer, I am using the .NET DNS class to resolve the name. In addition, I have included a fallback resolution using NETBIOS. If you ask for resolution, and DNS doesn’t return a name, you can opt to use the NBTSTAT command to resolve the hostname. I use a regular expression pattern to pull the computername.

Here’s version 2.0 of Test-Subnet.

And to be clear, “subnet” may be a bit of a misnomer as I’m not calculating any addresses with a subnet mask. Instead you enter the base IPAddress, like and then a range of host numbers between 1 and 254, which is the default by the way. The command will then test through, or whatever you entered.

My script employs some other techniques you might find help such as splatting, parameter sets, Write-Progress and parameter validation. Here’s a screenshot of results that I’ve sent to Out-Gridview and then customized.


But since the command writes objects to the pipeline you could do whatever you wanted. I trust you’ll let me know what you think. Enjoy!!

Send PowerShell Reports by Mail

Today I came across a post about pinging a list of computers and send the results as a table via Outlook. Brian is a very smart Active Directory guy so I offered some PowerShell suggestions to make his task even easier. Obviously you can only offer so much in a blog comment, so I thought I’d drop a few more details here. Continue reading

Test-Subnet WinForm

Recently, I posted an entry on how to ping an IP subnet with PowerShell. Using objects in the PowerShell pipeline is a good thing. But sometimes we want a GUI and I figured the ping subnet script would make a good WinForm script. Continue reading

Ping IP Range

Last week I came across a post on using PowerShell, or more specifically a .NET Framework class, to ping a range of computers in an IP subnet. The original post by Thomas Maurer is here. I added a comment. And after looking at this again I decided to take the ball and run with it a bit further. I’m a big proponent of PowerShell tools that are object oriented and that can add real value to the pipeline. To that end I wrote Test-Subnet. Continue reading

Test Connection Troubles

In this week’s Prof. PowerShell column, I have an article on using the Test-Connection in Windows PowerShell. I thought it was pretty straightforward, but I didn’t take problems into account. I received an email asking what to do about error messages. For example, what if you have a computername in the list that can’t be resolved to an IP address? At first I thought you could use a traditional Trap, but after a little testing that’s not really going to give you what you want, I think. Here’s how I would handle it.

Now you can certainly use a Trap statement. You’ll need to use the –ErrorAction common parameter with Test-Connection cmdlet. That’s what I would do with most cmdlets. But in this case, I’m probably going to use it expecting a boolean value of True or False. The cmdlet is a wrapper for the Win32_PingStatus class and as such will attempt to resolve computernames.  You can use an IP address for the computername, but you’ll get the same type of error if the computer is down.

Instead, I’ll simply tell Test-Connection to ignore any exception and keep on rolling. I can (probaby) safely assume that if there was an exception that the computer is “down” or I do not have a valid connection, which is the whole point of the cmdlet anyway, right?

On my network some of these computers are valid and some are not. I don’t really care why a computer fails the connection test and I’m not sure I can get that information anyway from the underlying exception. The exception is the same, although the message does vary. Here’s almost the same code with the addition of a Trap statement.

The other significant change is that I changed the ErrorAction to Stop so that the exception is caught by the trap.  The Trap is part of the ForEach construct so that PowerShell will continue with the next command in the same scope as the trap.

Obviously there are many ways you can use Test-Connection and I won’t swear that these ideas will work in all situations, absolutely. But hopefully it will give you a place to start.