Ok, ok, it has been a long time since I posted anything here, hasn’t it? Do I have an excuse for that? Shoot, not only do I have an excuse, I have three of them:

 

  1. I’m lazy.
  2. It’s baseball season. (As I noted awhile back, coaching baseball limits the amount of free time I have outside of work, and that’s pretty much the only time when I can put together blog entries. On the bright side, we’re 3-0 versus our cross-town rivals, and my son made a regional all-star team that will play in Japan in August. So don’t expect many blog postings in August, either.)
  3. I spend surprisingly little time doing scripting-related stuff.

I know, I know, that last one sounds pretty lame: we call ourselves the Microsoft Scripting Guys, and yet we don’t spend all our time doing scripting stuff? Sad, but true (although that might be changing in the very near future.) Although we do some scripting stuff, we haven’t always been given an opportunity to play around with new/undocumented scripting stuff, exactly the kind of information I’d like to premiere in the blog. Sure, we could we talk about mapping network drives in this space, but, I mean, come on: mapping network drives, in a blog? Not that mapping network drives isn’t important, it’s just that it isn’t exactly cutting-edge material, either. And so by sticking to the notion that the blog ought to focus on things we haven’t talked about elsewhere, well, that means most days I really don’t have much to say. And that’s because most days I don’t spend much time (if any) looking any new/different scripting technologies.

 

Over the past few days, however, I’ve started fooling around with Windows XP Service Pack 2. And it’s a good thing I did: there are some new scriptable items in Service Pack 2 (like Windows Firewall and Software Update Services), so – for once – that gives me an opportunity to talk about something new and different in the blog. (Most likely what I’ll do is just mention some stuff here, and then sooner or later we’ll post more detailed information in the Script Center.) It’s also a good thing I looked at Service Pack 2 because we had queried the WMI and ADSI teams to ask them if either of their technologies were being changed for SP 2. They said no, and – technically – that’s true; WMI and ADSI are largely unchanged. But guess what happened when first I tried to run a WMI script against a remote machine that had Service Pack 2 installed? If you guessed, “It worked like a charm!”, well, sorry. Instead, I got this error message:

 

The remote server machine does not exist or is unavailable.

 

When I tried running an ADSI script, I got an even cooler result: nothing. The script ran, and then just kind of disappeared, without even giving me an error message of any kind. (If any of you happen to open a closet door or something and you see a lost ADSI script in there, it’s probably mine.)

 

So what’s the deal here; does this mean WMI and ADSI have been changed (for the worse) with Service Pack 2? No; in fact, if you run the scripts locally they work just fine. As it turns out, the culprit is the new Windows Firewall. By default, the Windows Firewall is enabled when you install Service Pack 2, and, by default, the Firewall blocks all incoming RPC traffic. If you try to run a script against a remote computer running Service Pack 2, the firewall will block the script, regardless of any admin privileges you might hold. (The firewall simply blocks all incoming signals; it doesn’t really care who might have sent them.)

 

So are you hosed, are all those WMI scripts you have so painstakingly crafted over the past year or two now totally useless once you install Service Pack 2? Fortunately, the answer is no. In fact, your scripts will still work just fine, without you having to change a single line of code; instead, you simply have to open the appropriate ports on the Windows Firewall.

 

A hassle? Well, maybe (though the argument, of course, is that it’s a small price to pay for added security and protection). But at least it’s easy to open the appropriate ports; in fact, here’s a script that will take care of that for you:

 

Set objFirewall = CreateObject("HNetCfg.FwMgr")

Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

 

Set objAdminSettings = objPolicy.RemoteAdminSettings

objAdminSettings.Enabled = TRUE

 

Pretty easy, huh? Run that script locally on each machine that has Service Pack 2 installed, and your WMI and ADSI (and other scripts) will work just like they always have.

 

(Oh, did I say that you had to run the script locally on each machine? Well, there’s a bit of a Cacth-22 situation going on here: you need to run the script to open the firewall, but because the firewall isn’t open, any script you run remotely can’t get through. Consequently, you’ll have to run the script locally after you install Service Pack 2. Are there better ways to do this? Possibly; you can use an unattend file to install Service Pack 2, and within that file you can indicate that you want remote administration enabled. We’re still investigating the best/easiest ways to do all this. Stay tuned.)

 

By the way, the Windows Firewall has its own object model, and is fully scriptable. We intend to document this as fully as we can by the time Service Pack 2 is officially released. In the meantime, here are a couple scripts you can play around with. Over the next week or so, I’ll pop a few additional scripts into the blog, just to give you a better idea of what (and how) you’ll be able to manage the firewall after you upgrade all your XP machines to Service Pack 2.

 

Disable the Windows Firewall

 

As I noted before, the Windows Firewall is enabled by default when you install Service Pack 2. For most people that’s a good thing; if you already have a firewall running on your machine, however, you might not want to have Windows Firewall running as well. So how can you disable Windows Firewall? Why, by running this script, of course:

 

Set objFirewall = CreateObject("HNetCfg.FwMgr")

Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

 

objPolicy.FirewallEnabled = FALSE

 

Later on, if you decide to re-enable the firewall, just set the FirewallEnabled property to True, like so:

 

Set objFirewall = CreateObject("HNetCfg.FwMgr")

Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

 

objPolicy.FirewallEnabled = TRUE

 

Basic Firewall Properties

 

Here’s a script that will provide some basic information about Windows Firewall. Without going into a lot of detail, it will tell you:

 

  • Whether or not the firewall is currently enabled.
  • Whether or not exceptions are allowed to the default firewall settings. If ExceptionsNotAllowed is set to True, then all incoming traffic is blocked, no exceptions allowed (hmmm, wonder if that’s where the property name came from). What that means is that only network traffic that you initiate can pass through the firewall. If this property is set to False, then you can do things like allow traffic originating from and intended for certain applications to get through the firewall. That’s something we’ll talk about next week.
  • Whether or not notifications are disabled. If notifications are not disabled, then anytime a script or application tries to wriggle its way through the firewall a message box will pop up alerting the user to this.
  • Whether or not Unicast responses to multicast broadcasts are disabled. To tell you the truth, I don’t fully understand the reason why you might want to enable or disable this. But, hey, I’m just a scripting guy; I can’t be expected to actually understand computing!

 

Set objFirewall = CreateObject("HNetCfg.FwMgr")

Set objPolicy = objFirewall.LocalPolicy.CurrentProfile

Wscript.Echo "Current profile type: " & objFirewall.CurrentProfileType

 

Wscript.Echo "Firewall enabled: " & objPolicy.FirewallEnabled

Wscript.Echo "Exceptions not allowed: " & objPolicy.ExceptionsNotAllowed

Wscript.Echo "Notifications disabled: " & objPolicy.NotificationsDisabled

Wscript.Echo "Unicast responses to multicast broadcast disabled: " & _

    objPolicy.UnicastResponsestoMulticastBroadcastDisabled

 

Resetting the Firewall

 

This is kind of a handy little script, especially after you start messing around with the firewall. Next week we’ll show you some scripts that can do things like open ports, add applications to the exceptions list, and otherwise change the default settings. That’s good, but when you’re all done fooling around you might think to yourself, “Ok, I’m not totally sure what I did here, and whether or not I might have inadvertently screwed things up.” Hey, don’t worry about it; just run this script, and it will automatically restore the default settings:

 

Set objFirewall = CreateObject("HNetCfg.FwMgr")

objFirewall.RestoreDefaults()

 

Cool, huh? Next week, we’ll go into the Windows Firewall object model in a little more detail – promise. (Well, of course, we have a game on Monday and another on Wednesday, practice on Tuesday and Thursday, a doubleheader Saturday ….)

 

P.S. If you don’t trust me to actually continue the exciting saga of Windows Firewall next week, well, I can’t say as if I blame you. Therefore, if you want to hedge your bets a little, you might take a look at the Windows Firewall SDK, located here: http://msdn.microsoft.com/library/en-us/ics/ics/windows_firewall_start_page.asp