Group Policy: SBS Admins - Enable the Windows Firewall for your Windows XP SP2 clients

A while ago I did a post on configuring the Windows Firewall using Group Policy to get WMI scripts running against Windows XP SP2 clients. Since then it’s been on my list to do an expanded article going over the benefits of using the Windows Firewall, primarily because I see so many SBS environments that simply aren’t taking advantage of it.

So I’ll start by hitting the highlights, beginning with a financial incentive.

It’s free.

Since I’m bridging the SBS-Enterprise gap today, that’s always a good incentive for the SMB market – and something that corporations can get behind.

It works.

So there… not only is it free, but it actually does what it’s advertised to do… helps stop the spread of bad stuff… like exploits targeting vulnerabilities patched by MS06-040. Yes, it only filters incoming traffic, but that beats not filtering any day of the week. Vista should do outbound filtering, but that's a subject for a different day.

It gives your Patch Team space to evaluate before patching.

Oh, you are the patch team? Even better… because you really should test those patches before firing them off to your entire customer base. If you’re not testing, come up with a plan to start testing. In the mean-time, start following the newsgroups, mailing lists, and web sites that give the play-by-play on new patches. Check out this link for some patching resources that I follow.

You can specify a different firewall profile depending on how the computer is connected.

Check out the Group Policy editor (gpedit.msc). You have two profiles: the Domain profile, and the Standard profile (you can find these in the Group Policy editor here: Computer Configuration>Administrative Templates>Network>Network Connections>Windows Firewall.). When enabled, the Domain profile gets applied when the computer is connected to the domain - specifically, when it sees that the DNS suffix matches your domain configuration. The standard profile can be enabled when the computer is not connected. We started out (quite a while ago), by dogfooding this with internal users – mostly developers and IT Pro’s that would readily articulate pain points. Then we turned it on for internal use, and begun tightening it down.

Doesn’t enabling the Windows Firewall break-stuff?

It can. But internal testing, can really help alleviate, if not eliminate problems before a widescale rollout.

Did it break anything for you?

Not much. One thing that we did uncover was a “Scan to desktop” application that had developed quite a cult following in the office. Anything that got scanned on the scanner showed up on the desktop of the user doing the scanning. Very typical for the corporate environment … but not nearly as common in your average SBS environment. Testing revealed it prior to rolling out the Windows Firewall across the organization, and an appropriate exception was created for it.

How do you enable the Windows Firewall?

This could probably be better answered with a short How-To. This link can at least get you started; in the mean time I’ll see if I can either link something up, or create a How-To. The short version… in ADUC, create a new OU below your current “SBSComputers” OU. Throw your test computers into that OU, then turn on and configure the Windows Firewall Domain Policy using the Group Policy editor for that specific OU (Computer Configuration>Administrative Templates>Network>Network Connections>Windows Firewall). More better ways exist - but this is good for a quick and easy test ;).

Also - remember that Group Policy refreshes for Users and Computers are every 90 minutes. So you might want to do a "gpupdate /Force /Sync /Boot" on one of your test boxes to verify that the Windows Firewall gets enabled.