PowerShell Version 2 Compatible Function to Determine Windows Firewall State

I recently had a need to perform some security auditing on an environment that still has some servers running PowerShell version 2 (PowerShell version 2 is deprecated). One of the things I needed to determine was whether or not the Windows firewall was enabled on each of the servers in the environment. Luckily, all of the servers at least had PowerShell remoting enabled.

The PowerShell function shown in the previous code example is a wrapper for the Netsh.exe command. The commands that are going to be executed are stored in a here-string and then converted to a script block within the parameters hash table. It uses Invoke-Command to execute Netsh on the remote servers and them uses Select-String to parse down the data to only the lines that are necessary. The results are turned into a usable custom object in a For loop that uses Select-String again to parse out some of the unnecessary information from each of the remaining lines. If the credential parameter is specified, it’s also added to the parameters hash table. Splatting is used with Invoke-Command.

Custom error handling has been added to allow the function to take advantage of running against multiple computers at the same time via Invoke-Command while providing the user with feedback when errors occur such as being unable to connect to the remote computer.

I found that two different errors (access denied and logon failure) can be returned which both mean access denied. During the last few months, I’ve performed a technical technical review on the “Windows Server 2016 Automation with PowerShell Cookbook“. Based on reviewing Thomas Lee‘s PowerShell code, I learned that the Match operator can be used similarly to the Like operator except without the need to specify wildcard characters. I had previously only used it when I needed to specify a regular expression.

If you’re going to use the GroupBy parameter of Format-Table, you have to sort by that property first.

If the function is run against the local computer, the script block is simply invoked. While this doesn’t cover all scenarios where the local computer could be specified, it’s a great option for testing against a local computer where PowerShell remoting isn’t enabled.

This task is much easier to accomplish with newer versions of PowerShell using the Get-NetFirewallProfile cmdlet which was introduced in PowerShell version 3.0.

Here’s a bonus tip: Even though commands such as Get-NetFirewallProfile don’t have a ComputerName parameter, a computer name can be specified with the CimSession parameter without needing to first create a CIM session. A CIM session will automatically be created behind the scenes using the WSMan protocol and then it will be automatically removed once the command completes (a special thanks to Richard Siddaway for clarifying this for me a few weeks ago).

The Get-MrNetFirewallState function shown in this blog article can be downloaded from my PowerShell repository on GitHub.


Leave a Reply

%d bloggers like this: