Hey, I’ve been busy, OK? (Well, not really, but ….)

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: ” & _



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”)



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

Comments (11)

  1. Jude says:

    Very Informative stuff. I could see that many organizations going into XP SP2 without really testing out if their applications or scripts that query the desktops.

    I believe this will cause third party applications to force users to disable the firewall feature in XP.

  2. What’s easy for you is easy for others.

  3. Siva Mateti says:

    Cool ๐Ÿ™‚

  4. Mike Dimmick says:

    Just a thought, but couldn’t administrators set up a logon script that did this? Next time a user logs on, the change is applied (although I expect it requires admin privileges to make the change). Alternatively, you can probably configure it through Global Policy.

    Now, a script which sets the global policy appropriately, that would be useful…

  5. sjb says:

    Mike, I’d be pretty peeved if a login script running in the users context can change these settings.

    But then I am one of the people who believe that login scripts should only ever configure the users environment. Not only should they not modify the system config, they shouldn’t even have the rights to do it.

  6. Philip says:

    Does ICF in pre-SP2 XP have an object model that can be scripted against as well? MSDN seems to think so (e.g. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/intconnsharingfirewall.asp) but when you drill down a bit more it starts talking about Windows Firewall, which is SP2.

    The reason I’m asking is because I’m trying to put together a quarantine-checking script for Windows 2003 VPN and I want to make sure that any XP clients have got their firewalls enabled before they connect to us.

  7. James White says:

    Armor2net Personal Firewall software provides a complete spectrum of Internet security and Internet privacy for computers. The program protects the computer from hackers, data thieves, and other Internet-based dangers.

    For more information, please visit: <a href=โ€œhttp://www.armor2net.comโ€>http://www.armor2net.com</a>