Search results for 'app:weblogs' matching tags 'Scripting Guy!', 'security', and 'firewall'

PowerTip: Use PowerShell to Find Domain-Enabled Firewall Rules

Anonymous — Tue, 13 Nov 2012 06:00:00 GMT

Summary: Learn how to identify domain firewall rules by using Windows PowerShell 3.0 on Windows 8 or Windows Server 2012.

How can I find specific Domain profile firewall rules on my computer running Windows 8 or Windows Server 2012?

Use the Get-NetFirewallRule cmdlet and specify the enabled parameter as true and filter on the domain profile, as shown here.

Get-NetFirewallRule -Enabled true | Where profile -eq 'Domain'

Use PowerShell to Create New Windows Firewall Rules

Anonymous — Tue, 13 Nov 2012 06:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use Windows PowerShell to create new Windows Firewall rules on local and remote systems.

Microsoft Scripting Guy, Ed Wilson, is here. Today, we are off to Europe. The Scripting Wife and I are actually on separate flights—it’s the way the airline miles worked out for the flight. Luckily, the Scripting Wife is an excellent traveler. When I was working in Vienna a few years ago, she flew into Frankfurt, hopped a train to Vienna, and navigated the local S-Bahn trains from the Ost-Bahnhoff to the hotel without incident.

Anyway, from Frankfurt, once we are all there, we hop a train to Dortmond, Germany, where we will meet with Klaus Schulte. Klaus, as you may know, was the winner of the Scripting Games, and he has written several guest Hey, Scripting Guy! Blog posts. Neither the Scripting Wife nor myself has been to Dortmond, and we are looking forward to hanging out with Klaus, taking pictures, and of course, talking about Windows PowerShell.

Enable firewall rules with Windows PowerShell

I know why we do it, but dude, I still like to use Ping to see if a computer is up or down. I know I can use Windows PowerShell and do something like Test-WSMan to see if WinRM works, but old habits die hard. By default, on certain profiles, and on certain versions of the operating system, the Ping command is disabled. It really makes life difficult in the early hours of the morning when I tend to forget these sorts of things. So, I like to explicitly ensure that Ping is permitted through Windows Firewall. Once I have done this, and a machine does not respond to Ping, I know I need to do something else.

Unfortunately, while I can use the Get-NetFireWallRule cmdlet to retrieve information about scope and status of a firewall rule, it does not display what the actual rule itself is or does. This means that, for example, I cannot use Get-NetFireWallRule to retrieve a firewall rule and use it as a pattern when it comes to creating a new rule. In addition, it means that I cannot use the GUI tool to create a new firewall rule, use the Get-NetFireWallRule cmdlet to obtain the actual rules themselves, and then use that to create a new rule. Get-NetFireWallRule is useful for auditing but not for system configuration.

Create a new firewall rule

To create a new firewall rule that permits the Ping command, I first import the NetSecurity module. Next, I use the New-NetFirewallRule cmdlet to create the new firewall rule. The problem with this is that I basically have to know what I am doing … specifically. If, for example, I do not know that a Ping is ICMPv4 protocol, and specifically ICMPType 8, then I have no chance of creating a new firewall rule. This is where the GUI tool is a bit more friendly—rather than having to look up the ICMPTypes, they are available through the ICMP type page. This is shown here.

Here again, even the GUI tool does not actually list the ICMP type. So to get this information, I need to either already know it (Hey, I wrote a book on Network Monitoring and Analysis), or I need to look it up by using Ping.

I recommend using the Windows PowerShell cmdlet to create the firewall rule, and then inspecting the rule in the Windows Firewall with Advanced Security tool. Here is the rule I came up with to permit Ping on network interfaces with the ANY profile. (Note that I could use DOMAIN or PRIVATE profiles as well.)

Import-Module NetSecurity

New-NetFirewallRule -Name Allow_Ping -DisplayName "Allow Ping"`

-Description "Packet Internet Groper ICMPv4" `

-Protocol ICMPv4 -IcmpType 8 -Enabled True -Profile Any -Action Allow

Deploy the rule to all my Windows Server 2012 and Windows 8 machines

The first thing I need to do is to find all of my computers running Windows Server 2012 and Windows 8. I created a specific filter for the Get-ADComputer cmdlet that returns only these types of computers. I also specify Admin credentials to the Get-Credential cmdlet. This is shown here.

Import-Module NetSecurity, ActiveDirectory

$cred = Get-Credential -Credential iammred\administrator

$cn = Get-ADComputer -Properties operatingsystem -Filter `

"Operatingsystem -like 'windows 8 *' -OR OperatingSystem -like '* 2012 *'"

Now, I create a CIM session to each of these computers. When I do this, I specify the name of the computer and the credentials to use to make the connection. I do not worry if computers are offline when calling the command because it only connects with online machines. It simplifies the code. This appears here.

$CIM = New-CimSession -ComputerName $cn.name -Credential $cred

Next, I use the same New-NetFirewallRule command I used before—only this time I add that I want to use the CIM sessions in the $cim variable. Here is the code.

New-NetFirewallRule -Name Allow_Ping -DisplayName "Allow Ping"`

-Description "Packet Internet Groper ICMPv4" `

-Protocol ICMPv4 -IcmpType 8 -Enabled True -Profile Any -Action Allow `

-CimSession $cim

Verify that the changes took place

Because I already have the CIM sessions in the $CIM variable, I can use that with the Get-NetFirewallRule cmdlet to verify that the remote servers and workstations have received the new firewall rule. This command is shown here.

Get-NetFirewallRule -DisplayName "Allow Ping" -CimSession $cim |

Select PSComputerName, name, enabled, profile, action |

Format-Table -AutoSize

The command and the associated output are shown here.

I also want to verify that the Pings themselves will take place. Now, remember that the Get-ADComputer command returned some computers that were offline. But the $CIM variable contains CIM sessions to each computer that is obviously online. Unfortunately, the Test-Connection cmdlet does not accept a CIM session object, but that does not matter because it does accept an array of computer names. With auto array expansion, I can get the computer names from the variable containing all of the CIM sessions easily. Here is the command to which I arrived.

Test-Connection -ComputerName $cim.computername -BufferSize 15 -Count 1

The command and associated output are shown here.

PS C:\> Test-Connection -ComputerName $cim.computername -BufferSize 15 -Count 1

Source Destination IPV4Address IPV6Address

------ ----------- ----------- -----------

EDLT DC2 192.168.0.102

EDLT DC3 192.168.0.103

EDLT DC4 192.168.0.104

EDLT EDLT 192.168.3.228 fe80::bd2d:5283:5572:5e77%19

EDLT HYPERV2 192.168.0.46

EDLT HYPERV3 192.168.0.43

EDLT SQL1 192.168.0.150

EDLT WDS1 192.168.0.152

EDLT WEB1 192.168.0.54

Sweet, it worked! Join me tomorrow when I will talk about more way-cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Weekend Scripter: Playing Around with Windows Firewall

Anonymous — Sun, 28 Oct 2012 05:00:00 GMT

Summary: Microsoft Scripting Guy, Ed Wilson, shows how to use Windows PowerShell to work with Windows Firewall on Windows 8 and Windows Server 2012.

Microsoft Scripting Guy, Ed Wilson, is here. The Scripting Wife and I returned home from the Windows PowerShell Saturday #003 event in Atlanta, Georgia, last night, and we were exhausted—happy, but exhausted. The event was packed, and Mark Schill and the crew did a fantastic job organizing a flawless Windows PowerShell Saturday. Well done. All the sessions were marked high to extremely high by attendees.

If you follow the Scripting Wife on Facebook or Twitter, you know I have not been able to eat or drink anything hot for a week—that means no hot tea—and it has been driving me crazy. So, I am sitting on the lanai sipping a cool glass of water—not quite the same as English Breakfast Tea—not by a long shot.

Anyway, one of the things I have wanted to play with is the cmdlets for Windows Firewall. With nothing on the agenda but a murder mystery, written by my good friend and mentor Jaden Terrell, and a glass of cool water, today is the day.

Windows 8 Firewall cmdlets—a quick look

I am a huge fan of Windows Firewall because it works well, provides a measure of in-depth security, and comes with the operating system. In fact, I rarely find firewall-related issues, and, therefore, I do not turn it off—in fact, I leave it running on both the desktop and the server.

The first thing to do when working with the firewall is to determine the network connection profile because this determines the way the firewall policies work. In Windows 8 and Windows Server 2012, the Get-NetConnectionProfile cmdlet is extremely useful for this task. I first enumerate my network adapters, find the ones that are up, and then get the network connection profile. The commands are shown here.

Note I use the error action of 0 to remove errors about connection profiles for virtual adapters that are not connected to a network but are considered to be up. I also use the simple Where-Object syntax (? is an alias for the Where-Object cmdlet). Keep in mind when working with Windows PowerShell cmdlets that you have tab completion, and it greatly simplifies typing commands.

PS C:\> Get-NetAdapter | ? status -EQ 'up' | Get-NetConnectionProfile –ea 0

Name : Unidentified network

InterfaceAlias : vEthernet (InternalSwitch)

InterfaceIndex : 19

NetworkCategory : Public

IPv4Connectivity : NoTraffic

IPv6Connectivity : NoTraffic

Name : iammred.net

InterfaceAlias : vEthernet (External Switch)

InterfaceIndex : 23

NetworkCategory : DomainAuthenticated

IPv4Connectivity : Internet

IPv6Connectivity : LocalNetwork

To find the names and the status of the various Windows Firewall profiles, I use the Get-NetFirewallProfile cmdlet. I pipe the results to the Format-Table cmdlet (ft is the alias), and I choose only the name and the enabled properties. I then use the autosize switch to tighten up the display. The command and results are shown here.

PS C:\> Get-NetFirewallProfile | ft name, enabled -auto

name Enabled

---- -------

Domain True

Private True

Public True

Now for the first frustration: Except for the public network category, the value of the network category and the name of the firewall profile do not match up, and, therefore, it prevents piping. In this case, I cannot use Get-NetworkAdapter to get my network adapters, pipe it to the Get-NetConnectionProfile cmdlet, and then pipe it to the Get-NetFireWallProfile cmdlet. However, I can focus on the details of a specific firewall profile. Here are the details of the public network profile.

PS C:\> Get-NetFirewallProfile public

Name : Public

Enabled : True

DefaultInboundAction : NotConfigured

DefaultOutboundAction : NotConfigured

AllowInboundRules : NotConfigured

AllowLocalFirewallRules : NotConfigured

AllowLocalIPsecRules : NotConfigured

AllowUserApps : NotConfigured

AllowUserPorts : NotConfigured

AllowUnicastResponseToMulticast : NotConfigured

NotifyOnListen : True

EnableStealthModeForIPsec : NotConfigured

LogFileName : %systemroot%\system32\LogFiles\Firewall\pfirewall

log

LogMaxSizeKilobytes : 4096

LogAllowed : False

LogBlocked : False

LogIgnored : NotConfigured

DisabledInterfaceAliases : {NotConfigured}

The cool thing is that the Get-NetFirewallProfile cmdlet accepts an array for the profile name. Therefore, I can use a command something like the one appearing here.

Get-NetFirewallProfile domain,private,public

Even better, the Get-NetFirewallProfile cmdlet accepts wildcards. Therefore, I can use a command something like this one.

Get-NetFirewallProfile d*,p*

One problem with the firewall cmdlets is that they are all part of the massive NetSecurity module—a module that supplies 84 cmdlets and functions. I found this out by using the command shown here.

PS C:\> (gcm -Module netsecurity).count

Further, there are no aliases for any of the commands in the NetSecurity module. This is revealed by the command shown here.

gcm -Module netsecurity | % {gal -Definition $_.name -ea 0}

Besides no aliases for the firewall cmdlets, all of the names are pretty long, and due to the naming convention, tab expansion for the cmdlet names is not very efficient either. The 27 cmdlets appear here (sorted by name because the verb and noun are not exposed through Get-Command).

PS C:\> gcm -noun *fire* | sort name | select name

Name

----

Copy-NetFirewallRule

Disable-NetFirewallRule

Enable-NetFirewallRule

Get-NetFirewallAddressFilter

Get-NetFirewallApplicationFilter

Get-NetFirewallInterfaceFilter

Get-NetFirewallInterfaceTypeFilter

Get-NetFirewallPortFilter

Get-NetFirewallProfile

Get-NetFirewallRule

Get-NetFirewallSecurityFilter

Get-NetFirewallServiceFilter

Get-NetFirewallSetting

New-NetFirewallRule

Remove-NetFirewallRule

Rename-NetFirewallRule

Set-NetFirewallAddressFilter

Set-NetFirewallApplicationFilter

Set-NetFirewallInterfaceFilter

Set-NetFirewallInterfaceTypeFilter

Set-NetFirewallPortFilter

Set-NetFirewallProfile

Set-NetFirewallRule

Set-NetFirewallSecurityFilter

Set-NetFirewallServiceFilter

Set-NetFirewallSetting

Show-NetFirewallRule

Because of the naming convention, when using tab expansion, I have to type NetFirewall, and then a letter, such as P or R or S, to get close to the actual function name. If I type NetF and press tab, I have to cycle through the commands to find the function name I'm looking for.

Note If your duties require you to spend much time working with the firewall cmdlets, I recommend that you create your own series of aliases for the functions with which you regularly work. Store these aliases in a module that you can load on demand or in your profile, if you wish to have them at hand.

That is a quick overview of the firewall functions. Hope all is well with you, and happy scripting.

Ed Wilson, Microsoft Scripting Guy

Use PowerShell for Network Host and Port Discovery Sweeps

Anonymous — Mon, 02 Jul 2012 05:00:00 GMT

Summary: Guest blogger, Niklas Goude, discusses using Windows PowerShell to perform ping sweeps and port scans on a connected network.

Microsoft Scripting Guy, Ed Wilson, is here. This week we have guest blogger Niklas Goude. Before we get to Niklas, I want to mention that you should mark your calendars for September 15, 2012 because that is the date that the second Windows PowerShell Saturday event occurs. It will be held in Charlotte, North Carolina. Attendance is limited, so keep your ears attuned for when registration opens. We will have three tracks and the event will be a lot of fun.

Niklas Goude is a Security Consultant at TrueSec and an MVP in Windows PowerShell. In addition to his work performing security assessments for a variety of clients, he also has extensive experience in using Windows PowerShell to automate and implement Windows environments. He has been speaking at TechDays; SharePoint conferences in the U.S., Australia, and New Zealand; and other events and conferences. He is the author of two books about Windows PowerShell, and he shares his knowledge at PowerShell.nu. He is a member of the TrueSec Expert Team, an independent, elite team of security and infrastructure consultants that operates all over the world. The security team at TrueSec performs various tasks and services related to IT security such as code review, security health checks, and penetration testing. TrueSec also delivers top-notch training sessions in advanced IT security. Check out the TruSec website for additional information.

Now, without further ado, here is Niklas…

Penetration testing is an important part of improving security in any network environment. A hacker usually only needs to find very few weaknesses (even only one) to compromise important IT systems. An important task for an IT administrator is to identify potential weaknesses and mitigate them.

This is the first blog in a weekly series of five where we will talk about basic penetration testing techniques and how they affect misconfigured systems. The series will cover everything from initial network reconnaissance techniques and brute force attacks to advanced extraction of registry secrets to assess dangerous system dependencies.

The key learning point is to demonstrate how you can use Windows PowerShell to accomplish almost any task no matter the subject. The secondary learning point is to make you aware of common security issues and misconfigurations that may occur in Microsoft infrastructures today. One important thing to keep in mind is that the vulnerabilities we are looking for exist simply because of misconfigurations made by administrators, such as weak passwords, system dependencies, misconfigurations, and more. I hope you will learn and enjoy!

Note Today’s blog discusses using Windows PowerShell to perform network discovery. On some networks, use of such techniques is expressly disallowed except for specifically authorized teams and individuals. You must ensure that you have permission to perform the techniques described here prior to using such techniques at work. This also is a good time to emphasize the importance of proper network security configuration. For help with security configuration of your computer, see the Microsoft Safety & Security Center.

Part 1: Scanning

Scanning for IP addresses, MAC addresses, host names, and open ports is a way of finding the available computers on a network and finding out which service each computer publishes. In this blog, we will talk about how this can be performed by using Windows PowerShell.

Scenario

This scenario is based on a Windows domain environment that consists of three machines:

DC01: domain controller
SRV01: SQL Server and IIS
SP01: SharePoint 2010, SQL Server, and IIS

In addition, we have a client on the same network as the domain however the client is not a member of the domain. Each command in this scenario is executed from the client.

Configuration

The servers are manually installed by using the default settings. The servers use the Windows Firewalls default settings. The recommended internal firewall design is described in the following Microsoft TechNet Security Bulletin: Internal Firewall Design.

Code

The first step in scanning the network for IP addresses, host names, and open ports is to determine which network we are currently sitting on. The simplest way to do this is to use ipconfig. As you already know, Windows PowerShell has full support for running executables.

Simply type ipconfig to find out which network you are on. If you are running Windows PowerShell 3.0, you can also use the new Get-NetIPAddress cmdLlet.

PS > ipconfig

Windows IP Configuration

Ethernet adapter Wired Ethernet Connection 2:

Connection-specific DNS Suffix . :

Link-local IPv6 Address . . . . . : fe81::3314:cf47:dbc2:935c%11

IPv4 Address. . . . . . . . . . . : 10.0.0.100

Subnet Mask . . . . . . . . . . . : 255.0.0.0

Default Gateway . . . . . . . . . : 10.0.0.1

This example tells us that our IP address is 10.0.0.100 and the subnet is 255.0.0.0. With this information, we can perform a ping sweep on the network to find out if any hosts are reachable. We could, of course, achieve this by using ping.exe. However, there are more efficient ways to perform ping sweeps in a Windows network by using Windows PowerShell. One way is to use the Test-Connection cmdlet, which returns a Win32_PingStatus object that we can investigate in Windows PowerShell. We can also create an instance of System.Net.Networkinformation.Ping by using the New-Object cmdlet. This is the approach we’ll focus on. The following example demonstrates how to create an instance of System.Net.Networkinformation.Ping.

PS > $ping = New-Object System.Net.Networkinformation.ping

The Ping class supports a method called Send(), which we can use to send an Internet Control Message Protocol (ICMP) echo request to a computer by simply specifying an IP address. The following example demonstrates how to send an ICMP echo request to 10.0.0.2.

PS > $ping.Send("10.0.0.2")

Status : Success

Address : 10.0.0.2

RoundtripTime : 0

Options : System.Net.NetworkInformation.PingOptions

Buffer : {97, 98, 99, 100...}

If the computer responds, the status property is set to Success as shown in this example. It’s also possible to add a timeout by using a different overload definition. The timeout specifies the maximum number of milliseconds to wait for the ICMP echo reply message. The following example demonstrates how to ping 10.0.0.10 and wait for 500 milliseconds.

PS > $ping.Send("10.0.0.10", 500)

Status : TimedOut

Address :

RoundtripTime : 0

Options :

Buffer : {}

If we wanted to perform a ping sweep on multiple computers, we could simply take advantage of the Windows PowerShell pipeline support, and pipe any number of given IP addresses to the Send() method.

PS > "10.0.0.2","10.0.0.3" | ForEach-Object { $ping.Send($_, 500) }

Status : Success

Address : 10.0.0.2

RoundtripTime : 0

Options : System.Net.NetworkInformation.PingOptions

Buffer : {97, 98, 99, 100...}

Status : Success

Address : 10.0.0.3

RoundtripTime : 0

Options : System.Net.NetworkInformation.PingOptions

Buffer : {97, 98, 99, 100...}

Now that we know how to perform a simple ping sweep by using Windows PowerShell, let’s take a look at how to use Windows PowerShell to resolve a host name.

The System.Net.DNS class contains a static method, GetHostEntry(), which we can use to ask the DNS server for the host name that is associated with a given IP address.

PS > [Net.DNS]::GetHostEntry("10.0.0.3")

HostName Aliases AddressList

-------- ------- -----------
SRV01.hacme.local {} {10.0.0.3}

SRV01.hacme.local {} {10.0.0.3

It is also possible to ask the DNS server for the host name Async by using the BeginGetHostEntry() and the EndGetHostEntry() methods that are supported by System.Net.DNS.

Next, let us look at how to determine which ports are open on a system. The System.Net.Sockets.TcpClient class supports the Connect() method, which we can use to connect to a given IP address and port. First we create an instance to System.Net.Sockets.TcpClient.

PS > $tcpClient = New-Object System.Net.Sockets.TCPClient

Next, we use the Connect() method and try to connect to a specific IP address and port. In the following example, we test if port 445 is open. Port 445 is the SMB port. If the connection is successful, the Connected property is set to True as shown here:

PS > $tcpClient = New-Object System.Net.Sockets.TCPClient

PS > $tcpClient.Connect("10.0.0.2",445)

PS > $tcpClient.Connected

True

If the connection fails, an error message is displayed and the Connected property is False.

PS > $tcpClient.Connect("10.0.0.2",1234)

Exception calling "Connect" with "2" argument(s):

"A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 10.0.0.2:1234"

At line:1 char:1+ $tcpClient.Connect("10.0.0.2",1234)

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException

+ FullyQualifiedErrorId : SocketException

PS > $tcpClient.Connected

False

It is also possible to test the port’s Async by using the BeginConnect() method.

These are the basic steps that we need to perform a network scan by using Windows PowerShell. The nice thing about Windows PowerShell is that we can reuse the code by placing it in a function and simply calling the function instead of typing the code every time we want to perform a network scan.

The following example demonstrates the Invoke-TSPingSweep function in action.

PS > Invoke-TSPingSweep -StartAddress 10.0.0.1 -EndAddress 10.0.0.10 -ResolveHost -ScanPort

IPAddress HostName Ports

--------- -------- -----

10.0.0.2 DC01.hacme.local {53, 139, 389, 445...}

10.0.0.3 SRV01.hacme.local {21, 80, 139, 445...}

10.0.0.10 SP01.hacme.local {80, 139, 445}

The function uses the code described in this post and supports the following parameters:

StartAddress
EndAddress
ResolveHost
ScanPort
Ports
Timeout

Using the functionality of Windows PowerShell makes it very easy to search for specific ports that are returned from a network scan to determine if a computer is running a specific service. For example, if we wanted to find all computers running SQL Server, we could simply store the output in a variable and use the Where-Object cmdlet to retrieve each object where the Port 1433 is open.

PS > $pingSweep = Invoke-TSPingSweep -StartAddress 10.0.0.1 -EndAddress 10.0.0.10 -ResolveHost -ScanPort

PS > $pingSweep | Where-Object { $_.Ports -eq "1433" }

IPAddress HostName Ports

--------- -------- -----

10.0.0.3 SRV01.hacme.local {21, 80, 139, 445...}

PS > $pingSweep | Where-Object { $_.Ports -eq 80 }

IPAddress HostName Ports

--------- -------- -----

10.0.0.3 SRV01.localdomain {21, 80, 139, 445...}

10.0.0.10 SP01.localdomain {80, 139, 445}

There are, of course, other tools that you can use when performing network scans. One such tool is the Nmap security scanner, which has the possibility to perform the tasks described previously and a lot more. As I mentioned earlier, Windows PowerShell has full support for executables, so another approach for performing a network scan would be to invoke nmap.exe and parse the XML output into a Windows PowerShell custom object to utilize the benefits of Windows PowerShell when working with the ouput. The following example demonstrates how to run nmap.exe and output the results to an XML document.

PS > & 'C:\Nmap\nmap.exe' -F 10.0.0.1/24 -oX C:\temp\nmap.xml

Next, we can use Get-Content and read the content of the XML document. By adding the [xml] data type and placing the cmdlet within parenthesis, the content is read as an XML object.

PS > $nmap = [xml](Get-Content C:\temp\nmap.xml)

PS > $nmap.nmaprun.host

starttime : 1340110002

endtime : 1340110018

status : status

address : {address, address}

hostnames :

ports : ports

times : times

Downloads

To download this entire code sample, see Invoke-TSPingSweep in the Script Center Repository.
Additional functions and code related to security are available on the TruSec website.
For more information about Nmap, see the NMAP.ORG site.

~Niklas

I want to thank Niklas for an interesting and informative blog. Security Week will continue tomorrow with Part 2 of Niklas’s security series.

Ed Wilson, Microsoft Scripting Guy

Hey, Scripting Guy! Weekend Scripter: Improving Yesterday’s Windows Firewall Script

Anonymous — Sun, 04 Jul 2010 05:00:00 GMT

Microsoft Scripting Guy Ed Wilson here. The Smokey Mountains are about 10 degrees cooler than Charlotte , North Carolina , is. The problem is that it was nearly 100 degrees Fahrenheit in Charlotte. Anyway, getting to spend some time with my old high school...(read more)

Hey, Scripting Guy! Weekend Scripter: How to Retrieve Enabled Windows Firewall Rules

Anonymous — Sat, 03 Jul 2010 05:00:00 GMT

Microsoft Scripting Guy Ed Wilson here. The Scripting Wife and I are getting ready to head up to the mountains in search of a bit of cool air. Even if it is hot up there, it will still be cool because we are meeting one of my old high school friends....(read more)