November 2004

By The Scripting Guys

For a list and additional information on all Tales from the Script columns, click here.

On This Page

I Married Bigfoot. Oh: and Service Pack 2 Made My Computers Disappear.
So What Exactly is the Windows Firewall?
How to Get Your Computers Back
Scripting the Windows Firewall
Wait a Second ….
Um, I Still Don’t Have My Computers Back ….
Is Group Policy My Only Option?
But What If I Don’t Even Want the Firewall?
It’s Not as Bad as You Think

I Married Bigfoot. Oh: and Service Pack 2 Made My Computers Disappear.

Human begins are fascinated by things that disappear. For example, who among us hasn’t sat in the audience at a magic show and watched in rapt attention as the magician made a volunteer from the audience disappear? (And, let’s be honest, who among us hasn’t thought, “Hmmm, I wonder how I could get that guy down the street to volunteer next time ….) Amelia Earhart was the first woman to fly across the Atlantic Ocean, but is that was she’s best-known for? Of course not; Amelia Earhart is famous because she disappeared without a trace. Judge Crater? Beats us. But, hey, he vanished into thin air; what more do you want? Whether it’s alien abductions, the Bermuda Triangle, or the hamster you had as a child — the one your mom said somehow escaped from its locked cage — people are far more interested in things that aren’t there than things that are there.

Note. You know, the more we think about it, there’s no way that hamster could have wriggled out of its cage. You might want to call your mom as soon as you get done reading this.

Of course, it’s not always fun when things disappear. (We were going to say, “Take the Scripting Guys’ bank account,” except it appears someone already did.) For example, you might have dutifully installed Windows XP Service Pack 2 on your computers, only to get this message the first time you tried to manage those computers remotely:

Good heavens! Did Windows XP Service Pack 2 make your computers disappear? Did Windows XP cause your entire IT infrastructure to vanish into thin air? Is it just a coincidence that no one has seen Amelia Earhart since Service Pack 2 was released?!?

Relax; everything is fine, and your computers are all still there. (Really; if you don’t believe us, walk across the hall and check on them.) Service Pack 2 doesn’t cause your computers to disappear without a trace. (Yes, it might be nice if it could do that to some of your users, but Service Pack 2 won’t make them disappear, either.) In fact; Service Pack 2 doesn’t harm your computers in any way; it’s actually designed to protect your computers. However, the new Windows Firewall – which is not only enabled by default in Service Pack 2, but is configured with the most secure settings imaginable – pretty much prevents you from using anything other than Group Policy to remotely administer those computers. That’s why you can’t manage your computers remotely. The computers are still there, but Windows Firewall won’t let anything in, including your scripts, your command-line tools, and any other management applications you might have.

If you were recently abducted by aliens and thus haven’t had a chance to install Service Pack 2 yet, you’re in luck. (For one thing, being super-intelligent, highly-evolved creatures, maybe the aliens have already figured out how to use scripts with Service Pack 2.) In this month’s column we’ll clue you in on different ways to configure the Firewall settings in Service Pack 2 prior to installation to help ensure that your computers will be manageable the moment that installation is complete. And if you’ve already installed Service Pack 2, remain calm; we’ll tell you what needs to be changed in order to restore remote administration. In other words, don’t book a plane trip for the Bermuda Triangle just yet: the Scripting Guys are here to help.

But before we do that, how about a word from our sponsor?

So What Exactly is the Windows Firewall?

The Windows Firewall – a new addition to Windows XP, and not to be confused with the Internet Connection Firewall that originally shipped with the operating system – is designed to help protect your computer from hackers, crackers, slackers, linebackers, and other kinds of attackers. It does this in pretty straightforward fashion: by default, it automatically rejects any unsolicited network traffic sent its way. That’s why your scripts no longer work: because the remote computer didn’t request those scripts, the incoming traffic is turned away. And, yes, we know you are a local administrator on the remote machine. That doesn’t matter. The Firewall doesn’t check to see who sent the incoming traffic, it just rejects it. Period.

By default there aren’t any exceptions to this rule. Your scripts can’t get through, but neither can command-line tools, MMC snap-ins, or anything else. In fact, by default about the only thing that can be used to manage a computer running Service Pack 2 is Group Policy. That’s because Group Policy isn’t unsolicited incoming traffic. Instead, when your computer starts up (or when a user logs on) the computer contacts Active Directory and requests that Group Policy be applied. That makes Group Policy solicited traffic, and enables it to slip through the Firewall.

Note. This also applies to logon and logoff scripts, and to computer startup and shutdown scripts. Because these scripts are assigned by and run under the context of Group Policy, they get through the firewall. However, any script you start up on your workstation that tries to connect to a remote computer will be rejected; after all, that script represents unsolicited incoming traffic. We should point out that you can always go the opposite way without any problems. Say you have installed Service Pack 2 on a computer, and you want to start a script that goes out and connects to a remote machine, a machine that isn’t running Service Pack 2. In that case, no problem: that’s because – with few exceptions – the Firewall doesn’t restrict outgoing network traffic.

Of course, you might be thinking, “Well, those might be the defaults, but I don’t like those defaults.” Okey-doke. Then let’s talk about how you can change those default settings.

How to Get Your Computers Back

Because this is a scripting column (we know, it’s sometimes hard for us to tell, too) our main concern is this: how can we regain the ability to use scripts to remotely manage a computer running Service Pack 2? Considering how effectively the Firewall squashes incoming network traffic you might be leery about this; after all, that sounds like a lot of work.

Believe it or not, however, getting your computers back (or at least making them manageable again) is surprisingly easy: all you have to do is enable the remote administration setting on the Firewall. Do that, and you’ll once again be able to remotely manage that machine using scripts, command-line tools, MMC snap-ins, etc. In fact, not only is there just a single setting that has to be changed, but there are also plenty of alternatives for changing that setting: you can use Group Policy, you can modify the registry, you can use Netsh.exe, you can run a script. In fact, the key isn’t really so much how you enable remote administration as it is when you enable remote administration. That’s because there are two important factors to keep in mind:

• If you install Service Pack 2 and then decide to enable remote administration, bear in mind that you will not be able to remotely run a script or a command-line tool to modify the computer. Instead, you will either have to use Group Policy, or individually visit each machine and enable remote administration.

• If you opt to enable each machine individually, you might not be able to solicit help from your users. That’s because you must be a local administrator in order to configure Firewall settings. (Firewall settings apply to the computer as a whole; you cannot configure the Firewall to apply some settings to User A but not apply those settings to User B.) If your users are not local administrators, your options will be limited. For example, you will not be able to write a script, email that script to your users, and then ask them all to run the script. Unless the users are local administrators, the script will fail.

We’ll run through the different options for enabling remote administration in just a second. But because this is a scripting column, let’s take yet another detour and talk about scripting the Windows Firewall. (And, yes, we know that, too: by the time we get done with all these detours, Service Pack 3 will probably be out.)

Scripting the Windows Firewall

The Windows Firewall has a pretty good scripting model, but this model does have one unfortunate drawback: the Firewall object (HNetCfg.FwMgr) cannot be created remotely. In other words, suppose you’re sitting at Computer-A, and you want to instantiate the Firewall object on remote Computer-B. Most likely your script would include code similar to this:

Set objFirewall = CreateObject("HNetCfg.FwMgr", "Computer-B")

Syntactically, that’s the way to create objects on a remote computer. But here’s what you’ll see when you run the script:

Why? It’s simple: you can’t create an instance of the Firewall object on a remote computer. Period. According to the product team responsible for the Firewall, this was done to increase security; by definition, anything that can be created remotely is not as secure as something that can only be run locally. And because the Firewall is designed to make your computer more secure, that pretty much ruled out the ability to create the Firewall object remotely.

Is that a problem? To be honest, yes. After all, you’re used to sitting at your administrator workstation and running WMI scripts that go out, connect to a computer, and bring back the desired information. That won’t work with the Firewall; Firewall scripts must be run locally. So, yes, it’s a problem, but fortunately there are a couple of ways for you to sidestep the issue, although one of them (using WMI’s Win32_Process class) works only after remote administration has been enabled.

One way to get around the fact that the Firewall object cannot be created remotely is to run your scripts as computer startup or computer shutdown scripts; as we noted earlier, because Group Policy is actually solicited incoming traffic, computer startup and shutdown scripts are not affected by the Firewall.

So then why shouldn’t you run these as user logon or user logoff scripts? Well, remember, you must be a local administrator to manage the Firewall. If your users are not local administrators, logon or logoff scripts won’t do you any good; that’s because those scripts run under the security context of the user logging on or logging off. Computer startup and shutdown scripts, by contrast, run under the LocalSystem account; consequently, these scripts can be used to manage the Firewall.

When using computer startup or shutdown scripts, it’s also important to bear in mind that these scripts are running locally on each computer that starts up or shuts down. Why is that so important? Well, for one thing, you’re used to using Wscript.Echo as a way to display information obtained from a computer. For example, here’s a script that tells you whether or not the Firewall is enabled. It creates the Firewall object, connects to the current Firewall policy, and then echoes the value of the FirewallEnabled property:

Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile
Wscript.Echo "Firewall enabled: " & objPolicy.FirewallEnabled

That’s fine as long as the script runs on your computer. Remember, though, that as a startup or shutdown script this script will be running on a remote computer. Any message boxes that might appear, or any messages echoed to the command prompt, are going to appear on that remote computer. As an administrator sitting at your workstation, you’ll never see any of those messages, and so you’ll never know whether the firewall is enabled or not.

So how do you work around that problem? Don’t worry; this is an easy one. Instead of using Wscript.Echo to display information in a message box, use the FileSystemObject to write that data to a text file. For example, here’s a script –designed to run locally, like all Firewall scripts – that collects information about the basic Firewall configuration and then writes that data to a text file, saving it to the Firewall share on the server atl-fs-01:

Set objNetwork = CreateObject("Wscript.Network")
strComputer = objNetwork.ComputerName

Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.CreateTextFile("\\atl-fs-01\firewall\" _
    & strComputer & ".log")

objTextFile.WriteLine("Firewall enabled: " & objPolicy.FirewallEnabled)
objTextFile.WriteLine("Exceptions not allowed: " & objPolicy.ExceptionsNotAllowed)
objTextFile.WriteLine("Notifications disabled: " & objPolicy.NotificationsDisabled)
objTextFile.WriteLine _
    ("Unicast responses to multicast broadcast disabled: " & _
         objPolicy.UnicastResponsestoMulticastBroadcastDisabled)

objTextFile.Close

If you’re familiar with the FileSystemObject, this script is pretty straightforward. (If you’re not familiar with the FileSystemObject, check out this section of the Microsoft Windows 2000 Scripting Guide.) There’s really only one tricky thing involved here. Notice that, in the first two lines of the script, we use the Wscript.Network object to obtain the name of the computer where the script is running. We then stash that name in the variable strComputer.

Why? We’re glad you asked that question. We could have hard-coded a file name in the script; say, \\atl-fs-01\firewall\firewall_settings.log. That would work great … as long as you only have one computer. But suppose you have two computers. The first computer starts up, and saves its configuration information to Firewall_settings.log. The second computer starts up and saves its settings to Firewall_settings.log, thus overwriting the information saved by computer 1. By saving data to unique text files, text files that are named after each computer, we sidestep that issue.

Note. Couldn’t we have each computer append information to a single file? Sure, although even then you’d have to make sure that the computer name is specified along with the Firewall data. You could also have each computer store its data in a database, or add it to an Excel spreadsheet. Our purpose here isn’t to show you the way to handle data reporting; we just want to make you aware of the need to uniquely identify each computer and its Firewall data. The example we showed is probably the easiest way to do this, but by no means is it the only (or the best) way to do this.

Of course, in lots of organizations users don’t shut down and restart their computers; instead, they simply log off and leave the computers running. That introduces yet another complication: if users never shut their computers down, then their computer startup or shutdown scripts will never run.

Once again, however, there’s a way to get around this, although this approach can only be used after remote administration has been enabled on your Service Pack 2 computers. If you copy your Firewall scripts to your remote machines, you can then use WMI’s Win32_Process class and the Create method to kickoff and run those scripts. For example, you might create a folder named C:\Scripts on all your computers and then copy your Firewall scripts to each of those folders. (And, yes, you could easily write a script to automate this process.)

Now suppose it’s 3:00 in the afternoon, you’re sitting at your desk and you find yourself thinking, “Hmmm, I wonder how the Windows Firewall is configured on atl-ws-01.” Group Policy won’t help you here; Group Policy is really designed to configure computers, not to report on the way that computers have been configured. You could call the user who owns that computer and ask him or her to locate and read back all the Firewall settings. But, to be honest, that doesn’t sound like much of an option, either. What you really need is a script that connects to the remote computer and reports back the Firewall settings. But didn’t we just get done saying that you can’t create the Firewall object remotely?

Yes, we did, and it’s true: you can’t create the Firewall object remotely. Remember, though, that we just finished copying all our Firewall-related scripts to this remote computer. Because the script you want to run (Basic_properties.vbs) lives in the C:\Scripts folder on atl-ws-01, you can use this script to run Basic_properties.vbs on the remote computer:

strComputer = "atl-ws-01"
Set objWMIService = GetObject _
    ("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")
 
Error = objWMIService.Create _
    ("c:\scripts\basic_properties.vbs", null, null, intProcessID)

What we do here is bind to the Win32_Process class on the remote machine atl-ws-01. We then use the Create method to run the script C:\Scripts\Basic_properties.vbs. The cool thing is that C:\Scripts\Basic_properties.vbs is the path on the remote machine. We’re not referencing C:\Scripts\Basic_properties.vbs on our administrator workstation, we’re referencing C:\Scripts\Basic_properties.vbs on the remote computer atl-ws-01. There’s no need for us to have Basic_properties.vbs or even C:\Scripts on our computer. Everything takes place remotely.

Note. This is a nice little trick for running command-line tools and other utilities that can’t connect to remote machines. Netstat.exe can’t connect from your computer to a remote computer? No sweat; use Win32_Process and the Create method to run Netstat.exe on the remote machine, and then just have the output piped back to your computer.

Remember, too, that Basic_properties.vbs has to be similar to the one we showed you a minute ago. It can’t echo data to the screen; you’ll never see it. Instead, it needs to write data to a text file or a database or something. In general, though, this approach will work, and it’s not too terribly cumbersome.

Wait a Second ….

OK, so this approach is a little cumbersome; after all, if you have a couple hundred computers you’ll have to copy all your Firewall scripts to each computer, and then worry about making sure those scripts stay in synch any time you make changes to your Firewall scripts. But don’t worry, we – that’s right, we have a workaround for you. How did you know that; have you been hacking into our computers and reading these columns before they go online? Maybe we should practice what we preach and enable the Windows Firewall ….

At any rate, here’s a workaround. This script use the FileSystemObject to copy a Firewall script (Basic_properties.vbs) to the C:\Scripts folder on the computer atl-ws-01. The script then uses the Win32_Process class to run Basic_properties.vbs, and then immediately deletes Basic_properties.vbs from atl-ws-01. The net effect: The script runs on the remote machine, but you don’t have to worry about maintaining the same scripts on all your computers. As a bit of a bonus, no trace of Basic_properties.vbs remains on atl-ws-01, lessening the possibility that a user – inadvertently or otherwise – might delete, modify, or otherwise muck around with your script.

Const OverwriteExisting = TRUE

Set objFSO = CreateObject("Scripting.FileSystemObject")
objFSO.CopyFile "C:\Firewall\basic_properties.vbs", _
    "\\atl-ws-01\C$\Scripts\", OverWriteExisting

strComputer = "atl-ws-01"Set objWMIService = GetObject _
("winmgmts:\\" & strComputer & "\root\cimv2:Win32_Process")

Error = objWMIService.Create _
    ("cscript c:\scripts\basic_properties.vbs", null, null, _
        intProcessID)

objFSO.DeleteFile("\\atl-ws-01\C$\Scripts\basic_properties.vbs")

Note. that you must be using admin shares (like C$) for this to work. If you aren’t using admin shares, then you’ll need to copy the file to a shared folder on your remote workstations.

Um, I Still Don’t Have My Computers Back ….

Oh, that’s right: this column was supposed to be about enabling remote administration on computers running Service Pack 2, wasn’t it? Wow: it’s like the entire column we had intended to write just disappeared! Spooky ….

So here goes: The officially recommended way to enable remote administration is to use Group Policy, and there’s no doubt that Group Policy – under the right circumstances – is the fastest and easiest way to get remote administration up and running on all your Service Pack 2 computers. There is a catch, however. (There’s always a catch.) To get the new Firewall properties into a Group Policy object, you must first install Service Pack 2 on a computer, reboot that machine, log on as a domain administrator, and then modify the appropriate GPO from the computer running Service Pack 2. That’s because you must replace the System.adm Group Policy template found on the server with the version of System.adm that ships with Service Pack 2.

Now that’s not so bad, except that after you do this, from then on – and we quote from the official documentation here – you can only modify them [your GPOs] from a computer running Windows XP with SP2. If you haven’t installed Service Pack 2 on your primary administrator workstation, you won’t be able to use that workstation to modify your GPOs. If your fellow administrators haven’t installed Service Pack 2, they won’t be able to modify the GPOs. That’s because your System.adm files will be out-of-synch. Updates are in the works to overcome this, but it’s definitely something to keep in mind.

In fact, it might be enough to make you think about using a computer startup script instead. Startup scripts are administered using Group Policy, but they don’t require an ADM template. Consequently, you can assign a startup script that enables remote administration without having to worry about which computers will and won’t be able to administer the GPO. Because you don’t replace System.adm, that’s not a concern.

And we’d argue that this approach is almost as easy as configuring a Group Policy setting to enable remote administration. After all, the heart of your startup script doesn’t have to be any fancier than this;

Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

Set objAdminSettings = objPolicy.RemoteAdminSettings
objAdminSettings.Enabled = TRUE

All we’re doing here is creating the Firewall object, binding to the current profile, binding to the RemoteAdminSettings object, and then setting the Enabled property to TRUE. That’s it; that’s all you have to do. If later on you decide to disable remote administration, just set the Enabled property to FALSE:

Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

Set objAdminSettings = objPolicy.RemoteAdminSettings
objAdminSettings.Enabled = FALSE

Of course, if you haven’t already upgraded all your computers, you should also include code to verify that the machine where the script is running has Service Pack 2 installed; otherwise, you’re bound to run into problems when the script tries to create the HNetCfg.FWMgr object on a computer that doesn’t have Service Pack 2 installed. Fortunately, we just happened to have some sample code that determines whether or not a given computer is running Windows XP with Service Pack 2:

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & _
    "\root\cimv2")
Set colOS = objWMIService.ExecQuery _
    ("Select * from Win32_OperatingSystem WHERE ")
        "Caption = 'Microsoft Windows XP Professional' AND " & _
            ServicePackMajorVersion = 2")
If colOS.Count <> 0 Then
    Wscript.Echo "This computer is running Windows XP Service Pack 2."
Else
    Wscript.Echo "This computer is not running Windows XP Service Pack 2."
End If

Again, a pretty simple little script: we just query for all instances of the Win32_OperatingSystemClass where the Caption is equal to Microsoft Windows XP Professional and the ServicePackMajorVersion is equal to 2. If the Count comes back as 0, that means we aren’t running Windows XP Professional and/or Service Pack 2. If the Count comes back as 1, then we are.

If you’d like more information about how to configure and assign computer startup and shutdown scripts, you might check out this whitepaper available from the Microsoft Downloads Center.

Is Group Policy My Only Option?

We know: there are those of you who don’t like to use Group Policy, and there are those of you who can’t use Group Policy (for example, you might be part of a small company that uses a workgroup as opposed to a directory service). If that’s the case, your best bet is to configure remote administration before you install Service Pack 2. This can be done using a .INF file or by using an unattended setup file; for more details, see the paper Deploying Windows XP Service Pack 2.

And what if you’ve already installed Service Pack 2? Well, that’s a bit of a problem. If you can’t use Group Policy, you’ll need to have an administrator go around to each computer and run the script that enables remote administration. If your users are local administrators, you can email the script and ask them to run it. Otherwise, it’s return of the old-fashioned sneaker net.

Yes, we know: not exactly what you wanted to hear. But because remote administration is disabled, you can’t connect to the computer over the network and make the change. Someone will have to physically visit each computer and run a script or do something to enable remote administration. Or – hint, hint – take the plunge and use Group Policy. Trust us; Group Policy really isn’t all that hard, and there’s a whitepaper that will explain in step-by-step detail how to manage Firewall settings using Group Policy.

But What If I Don’t Even Want the Firewall?

Generally speaking, we don’t recommend that you disable the Windows Firewall; why put yourself at risk like that? However, you might already be running a third-party firewall; in that case, you should probably disable one of the two (it’s probably safe to say that two firewalls are not better than one). To help avoid conflicts and confusion, you can disable the Windows Firewall using this simple little script:

Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

objPolicy.FirewallEnabled = FALSE

But what if you have a change of heart later on? What if you find yourself thinking, “I miss the Windows Firewall. I sure wish I had it back.” Listen, don’t beat yourself up about that; just run this script instead:

Set objFirewall = CreateObject("HNetCfg.FwMgr")
Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

objPolicy.FirewallEnabled = TRUE

The Firewall will be re-enabled, and you’ll undoubtedly live happily ever after. And, of course, you can also use Group Policy to enable and disable the Firewall. Likewise, if you don’t want the Firewall in the first place, then use the .INF file or unattended setup to disable the Firewall when you install Service Pack 2. Again, there are plenty of options available to you, especially if you haven’t installed Service Pack 2 yet.

It’s Not as Bad as You Think

On the bright side – and, really, there is a bright side here – after you get remote administration enabled you’ll once again be able to use your scripts to manage computers running Service Pack 2. (That’s right: it’s as if Service Pack 2 never even existed!) Not only will all your old scripts work, but you’ll be able to write – and run – a whole slew of new scripts as well. That’s because there’s a bunch of new, scriptable stuff in Service Pack 2. If you’ve got a hankering to do some Service Pack 2 scripting, take a look at the so-called Windows XP Service Pack 2 Application Compatibility Scripts found in the Script Center. Don’t worry about the name; it’s a holdover from work done by another team. Instead, focus on the scripts, which show you different ways to manage the Windows Firewall, to manage the pop-up blocker in Internet Explorer, and do all sorts of things of you could only dream of prior to Service Pack 2.

Well, OK, maybe you didn’t actually dream of writing scripts to manage the pop-up blocker. But now that you have the pop-up blocker, you’ll want to find the quickest and easiest way to manage this new feature across the enterprise. And scripting is definitely a good place to start. And, yes, we’ll have a lot more to say about scripting Windows XP Service Pack 2 (and the forthcoming Windows 2003 Service Pack 1) over the next couple months, so stay tuned.

Now, as for all that stuff about mysterious disappearances and people vanishing into thin air and everything, well we think that is just a

 

Sorry; it’s an old joke. But we couldn’t resist.

Do you have questions or comments about this month’s column? Do you know what really happened to Amelia Earhart, or why Snickers bars always disappear from the candy machine before anything else does? Write to us at scripter@microsoft.com (in English, if possible). And don’t forget to ask your mom about that hamster.