June 2005

By The Scripting Guys

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

On This Page

Whack! Scripting the Internet Explorer Popup Blocker
As an Added Bonus, You Get to Script the Registry, too!
When It Comes to Popup Blockers, One is All You Need
Enabling the Popup Blocker
Configuring the Popup Blocker
Setting the Filter Level
Allowing Popups from Specified Web Sites
Questions? Comments?

Whack! Scripting the Internet Explorer Popup Blocker

With all due respect to Pong, Asteroids, Space Invaders, and the other great arcade games of the past, it’s hard to find a game more fun – and satisfying – than Whac-A-Mole. If you’ve never played Whac-A-Mole, the premise is simple: you stand before the game with a plastic club in your hand, waiting for little plastic moles to pop their heads up out of their holes. As soon as one does, the object of the game is to whack it on the head before it disappears again. That sounds easy, and it is – at first. But then, as arcade games are wont to do, the game gets progressively harder. Soon there are multiple moles poking their heads out of holes, and each mole is visible for only a split second before disappearing again. In no time at all you’re just whacking everything in sight, hoping that most of the things you are whacking will turn out to be moles. (Hint: It’s never a good idea to stand too close to a Whac-A-Mole game when someone else is playing.)

Seeing as how this is the Age of the Internet, it’s only fitting that we now have a newer, more high-tech version of this classic arcade game: Whac-a-Popup. You don’t even need to visit an arcade to play this game; all you have to do is start surfing the Web and, sooner or later, you’ll notice all sorts of little browser windows (typically ads) popping up all over the place. The object of this game is to close all the popup windows before they exhaust either your system resources or your patience. And, the same as Whac-A-Mole, the game gets progressively harder as well: sometimes closing a single popup window causes two or three more to open in its place.

Sure, it sounds like a lot of fun but trust us: it’s really – at best – extremely frustrating. (And, yes, most people do call it something other than “frustrating.”) Popups have become a veritable plague throughout the Internet and – at the risk of tooting our own horn – Microsoft has taken some steps to address this problem. In fact, we’ve taken at least three steps to address this problem: we’ve released a popup blocker as part of Windows XP Service Pack 2, and we’ve also released two popup blockers to go along with the two MSN Toolbars. Any one of these utilities can go a long ways towards wiping out Internet popups in our lifetime.

Popup blockers such as this can be extremely useful in the enterprise; after all, they definitely reduce stress, strain, and irritation for your users. That’s the good news. Unfortunately, there’s also a little bit of bad news. You might want to manage the popup blockers used in your organization; for example, there might be Internet or intranet sites your users visit where popups should be allowed. Admittedly, it’s fairly easy for a user to add a site to the list of sites where popups are allowed; however, that means you have to rely on each user to perform this task. It would definitely be easier if you, the system administrator, could manage the popup blocker. Unfortunately, neither the popup blocker found in Windows XP Service Pack 2 nor the popup blockers found in the MSN Toolbars come with much in the way of enterprise-wide management tools. (There are Group Policy settings available with Service Pack 2, but nothing in the way of enterprise management tools for the MSN Toolbars.)

Likewise, your first thought might be, “Wow, three popup blockers! That must be three times as good as having just one popup blocker.” Well, not really. In fact, using both the Service Pack 2 popup blocker and one of the MSN Toolbar popup blockers can lead to problems. For example, let’s say you’re using both these popup blockers, and that it’s necessary to allow popups for a given Web site. Your user dutifully adds the site to the Allowed list in the MSN Toolbar popup blocker. So what happens the next time that user visits the site? Nothing; no popups appear. That’s because the Service Pack 2 popup blocker is still blocking popups. In order to allow popups you need to configure both popup blockers, something that has already doubled the amount of administrative time required to manage popups. The truth is, you really want to use only one popup blocker and, as the system administrator, you’d probably like to determine which popup blocker is enabled and which one is not. But how can you do that without a lot of enterprise-wide management tools at your disposal?

OK, you guessed it: you can use scripts to manage the various Microsoft popups blockers. (When we write a column called Tales from the Script it probably shouldn’t come as a big surprise to us when everyone guesses the answer to a question like that.) Although no WMI classes are available to manage the popup blockers (and, yes, that would have been a very nice addition, wouldn’t it?) both of the MSN popup blockers and the Service Pack 2 popup blocker store their configuration information in the registry. And that gives us the opening we need: if it’s in the registry we can probably use scripts to retrieve and configure the settings. And that’s exactly what we’re going to do.

As an Added Bonus, You Get to Script the Registry, too!

Although the main focus of this column lies in using scripts to manage the Microsoft popup blockers, it also gives us an excuse to talk about registry scripting in general. Novice script writers are often confused by scripts that interact with the registry, partly because the registry itself can be confusing, and partly because Microsoft offers two different scripting technologies – Windows Script Host (WSH) and WMI – that can be used to manage registry keys and values. We’ll try to clear up this confusion a little bit, starting with this recommendation: you should always use WMI when writing registry scripts.

Why? Well, we can think of at least two reasons (we mean besides the huge kickback offered to us by the WMI team):

• WMI has more powerful registry manipulation capabilities than WSH does. For example, WMI has a built-in command for enumerating all the subkeys of a registry key; WSH has no such command.

• WMI can be used to read and write registry settings on remote computers just as easily as it can be used to read and write registry settings on the local computer. By contrast, WSH can read and write to the registry on only the local computer.

Of course, we should also point out that the WMI registry methods are a bit more complicated than the corresponding registry methods in WSH. That’s because, for the most part, WSH only has two methods: RegRead (for reading registry values) and RegWrite (for writing registry values). With WMI you not only have separate methods for reading and writing, you also have separate methods depending on the type of registry value you are dealing with. All these WMI methods are shown in the following table:

Yes, it takes a little getting used to, and at first you’ll probably need to refer to this table from time-to-time. On the bright side, though, the WMI registry provider is part of WMI; that means your registry scripts will usually follow a very distinct pattern. For example, scripts that modify the registry invariably require you to:

• Define a constant to indicate which part of the registry you want to work with. (Typically HKEY_CURRENT_USER or HKEY_LOCAL_MACHINE).

• Specify the computer (local or remote) you want to run the script against.

• Connect to the StdRegProv class (which is in the root\default namespace).

• Assign values to constants representing the registry path, the registry value name, and the new value being assigned.

• Call the appropriate method (such as SetDWORDValue) to change the value.

As you’ll see later in this column, scripts that read from the registry follow a similar pattern.

Of course, some of you might be panicking right about now; after all, don’t modify the registry is a warning you’ve probably heard all your life. Scripting Guy Peter Costantini, for example, likes to quote tech guru Mark Minasi, who once stated that the registry has been known to cause involuntary sex change in gerbils. (Is that true? Well, to be honest, we don’t even know how to tell whether that’s true or not.) Even the registry chapter in the Windows 2000 Scripting Guide starts off with a big disclaimer that essentially says, “This chapter shows you how to write scripts that manipulate the registry. Now, whatever you do, don’t ever write any scripts that manipulate the registry.”

In other words, if we’re encouraging you to use scripts that modify the registry isn’t that the same thing as telling you that it’s OK to take candy from strangers?

It’s definitely true that any time there’s an alternative method to directly modifying the registry – such as a WMI class or a COM object – you should take that route. Likewise you should set aside a test machine and try your registry scripts there before applying them to your real computers. Other than that, however, modifying the registry isn’t any more dangerous than doing any other sort of system administration work, especially if you limit yourself to relatively innocuous tasks. For example, what if your script to enable the popup blocker fails? In that case, you can just enable the popup blocker by hand. As they say in basketball, no harm, no foul. Like we said, set up a test machine, try things out ahead of time, and don’t run with scissors.

When It Comes to Popup Blockers, One is All You Need

As we noted earlier, it’s actually better to have just one popup blocker running than it is to have two popup blockers running. As a system administrator, you’ll also find it easier if all your users are running the same popup blocker. For this column we’ll assume that you’ve standardized on the popup blocker included with Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1. In other words, you want your users to run the built-in popup blocker and only the built-in popup blocker. That means you have to determine whether or not your users are running one of the MSN popup blockers and, if they are, you need to disable that blocker.

And that’s great, except for one thing: how do we know if users are running an MSN popup blocker and, if so, how do we disable that blocker?

Don’t worry; we already thought of that. Here’s a script that can tell you whether the MSN Toolbar Suite popup blocker is installed. We won’t discuss this particular script in any detail; for more information about checking to see if a registry value exists (which is what we’re doing here) see this Hey, Scripting Guy! column. What this script does is return the value of the HKCU\Software\Microsoft\MSN Apps\MSN Popup Blocker\Enabled registry value. If a Null is returned, that means the registry value does not exist. (Interestingly enough, no error is generated if a WMI script tries to read a non-existent registry key.) If anything but a Null is returned then the registry value exists.

Here’s the script:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
Set objRegistry = GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\MSN Apps\MSN Popup Blocker"
strValueName = "Enabled"
objRegistry.GetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

If IsNull(dwValue) Then
    Wscript.Echo "The registry key does not exist."
Else
    Wscript.Echo "The registry key exists."
End If

If you’re unsure what all that scripting gobbledygook means don’t worry; we’ll explain it all before we’re through with this column. For now let’s assume that the registry value is found, the MSN Toolbar popup blocker is installed, and we want to make sure that we disable the thing. How hard is that going to be?

Believe it or not, not hard at all: all we have to do is set the value of Enabled to 0. Let’s show you a script that does that very thing, then explain how it works:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & _
    strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\MSN Apps\MSN Popup Blocker"

strValueName = "Enabled"
dwValue = 0

objRegistry.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

The preceding script not only disables the MSN Toolbar popup blocker but also serves as a blueprint for scripts that change values in the registry. The script begins by assigning the value &H80000001 to the constant HKEY_CURRENT_USER; this constant tells the Standard Registry Provider which registry hive to look in. (If we wanted to work with HKEY_LOCAL_MACHINE we would have created a constant by that name and assigned it the value &H80000002.) After connecting to the WMI service (note that the Standard Registry Provider is found in the root\default namespace), we then define three variables:

Next we have a single line of code that calls the SetDWORDValue method and configures the registry value:

objRegistry.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

All in all, pretty easy.

But what if the user is running the plain vanilla MSN Toolbar as opposed to the MSN Toolbar Suite? In that case, the popup blocker is controlled by a registry value named PopupGuardStatus, found in the Software\Microsoft\MSN Toolbar key (which, in turn, is found in the HKEY_CURRENT_USER hive). Because this is a DWORD value (with 0 disabling the popup blocker) all you need is a script like this:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & _
    strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\MSN Toolbar"

strValueName = "PopupGuardStatus"
dwValue = 0

objRegistry.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

If you compare the scripts that disable the two MSN Toolbar popup blockers you’ll notice that there are only two differences: the value assigned to strKeyPath (the registry path) and strValueName (the registry value being changed). Everything else is exactly the same. And that’s the point. If you look at these sample scripts as templates, you are well on your way to modifying any registry value. For example, you can take the preceding script and easily modify it to work with any REG_DWORD value. All you have to do is:

• If required, change the constant from HKEY_CURRENT_USER to HKEY_LOCAL_MACHINE. (That, of course, depends on which part of the registry you need to work with.)

• Change the value assigned to the variable strKeyPath.

• Change the value assigned to the variable strValueName.

• Change the value assigned to the variable dwValue.

That’s all it takes. And that’s why we like WMI.

Enabling the Popup Blocker

Of course, now that you’ve disabled the MSN popup blockers you’ll want to make sure that the Windows XP Service Pack 2 popup blocker is running. Service Pack 2 also stores configuration information for its popup blocker in the registry, although Service Pack 2 does a much better job of hiding this information than MSN Toolbar does. If you’re diligent enough, however, you’ll find popup blocker information for Service Pack 2 in the HKCU\Software\Microsoft\Internet Explorer\New Windows portion of the registry; to make sure the popup blocker is enabled you just need to set the PopupMgr value to yes. In other words, you need a script like this one:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & _
    strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\Internet Explorer\New Windows"

strValueName = "PopupMgr"
strValue = "yes"
objRegistry.SetStringValue HKEY_CURRENT_USER,strKeyPath,strValueName,strValue

What’s the major difference here? Actually, there’s only one. The PopupMgr value happens to have a REG_SZ (string) data type (remember, the MSN Toolbar values both had REG_DWORD data types). Referring back to our table, if we want to write to a REG_SZ registry value we need to use the SetStringValue method. And guess what: that’s exactly what we did.

On a more trivial note, we also changed the name of the variable dwValue to strValue. We didn’t have to do that, but that does make it clear that we are working with a string value rather than a DWORD value.

Incidentally, if for some reason you decide to disable the Service Pack 2 popup blocker then just set PopupMgr to no.

Of course, you don’t always want to write to the registry; sometimes you just want to read from the registry, and see how things are currently configured. If all you want to know is whether or not the popup blocker is enabled then you can simply use a script like this:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & _
    strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\Internet Explorer\New Windows"

strValueName = "PopupMgr"
objRegistry.GetStringValue HKEY_CURRENT_USER,strKeyPath,strValueName,strValue 

Wscript.Echo "Popup blocker enabled: " & strValue

So what differentiates scripts that read from the registry from scripts that write to the registry? Well, for one thing we use a different method here: because we’re getting a value from the registry (as opposed to setting a value in the registry) we use the GetStringValue method. For another, you might have noticed that we don’t specify a value for the variable strValue (previously we used this variable to hold the new value we wanted to write to the registry). And yet, even though we don’t assign anything to strValue, in the last line of the script we echo back the value of strValue. What’s up with that?

In this case, the variable strValue is known as an out parameter. Values that you provide to a method are known as in parameters: in this example HKEY_CURRENT_USER, strKeyPath, and strValueName are all in parameters, because you assign values to these variables and then provide them to the method. By contrast, you don’t assign a value to the variable strValue; all you do is supply the variable with a name. The method takes care of assigning the out parameter in a value; in this case, the value assigned will correspond to the value of Software\Microsoft\Internet Explorer\New Windows\PopupMgr.

Configuring the Popup Blocker

Service Pack 2 not only enables you to turn the Popup Blocker on and off, but it also gives you the ability to determine (on a per-site basis) which popups are blocked and which ones aren’t. From within Internet Explorer, you can access the configuration settings for the Popup Blocker by clicking on Tools, Popup Blocker, Popup Blocker Settings. Let’s take a look at the Popup Blocker Settings dialog box and see how the elements map to the values found in the registry:

Don’t panic; we’re going to show you a table that explains what each of these registry values mean. And, no, we didn’t goof and accidentally point four different values to the Filter Level dropdown list; we’ll explain why we did that as well. But first, let’s take a look at the table of registry values (we’ll get to Allow in a minute):

Because these are all DWORD values you can use the GetDWORDValue method to read the existing values and the SetDWORDValue method to configure the existing values. Here’s a sample script that reads the current value of PlaySound:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & _
    strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\Internet Explorer\New Windows"

strValueName = "PlaySound"
objRegistry.GetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue 

Wscript.Echo "Play a sound when a popup is blocked: " & dwValue

And here’s a sample script that disables the playing of sounds any time a popup is blocked:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\Internet Explorer\New Windows"

strValueName = "PlaySound"
dwValue = 0
objRegistry.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

Every bit as easy as it looks. And take note: this follows the same pattern and uses the same templated approach as our previous registry scripts. That’s not a coincidence.

Setting the Filter Level

In Service Pack 2 you have three options for configuring the Popup Blocker’s Filter Level: the filter level can be set to High, Medium, or Low. Interestingly enough, there is no single setting in the registry that controls the filter level. Instead, the filter level is calculated based on the settings of the following four registry values, with 1 indicating that the feature is enabled and 0 indicating that the feature is disabled:

In other words, if BlockUserInit is enabled and everything else is disabled then the Filter Level is calculated as High Security. If only UseHooks is enabled then the Filter Level is considered Medium Security.

Note that you are not limited to the combinations shown in the table. Suppose you enabled just AllowHTTPS; in that case the Filter Level would be calculated as Custom. Likewise, suppose you enabled everything. Once again the Filter Level would be considered Custom.

So can we write a script to change the Filter Level? Sure: all we have to do is create a single script that changes all four registry values. For example, here’s a script that sets the Filter Level to High Security; it does this by setting the BlockUserInit value to 1 and the other three registry values to 0.

Here’s the code:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\Internet Explorer\New Windows"

strValueName = "BlockUserInit"
dwValue = 1
objRegistry.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

strValueName = "UseTimerMethod"
dwValue = 0
objRegistry.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

strValueName = "UseHooks"
dwValue = 0
objRegistry.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

strValueName = "AllowHTTPS"
dwValue = 0
objRegistry.SetDWORDValue HKEY_CURRENT_USER,strKeyPath,strValueName,dwValue

By now you’ve seen enough registry modification scripts that we’ll assume you can figure out for yourself how this one works. Remember, it’s no different or no more difficult than any of the other scripts we’ve seen; it’s just a little longer, simply because it’s configuring four registry values rather than just one.

Allowing Popups from Specified Web Sites

Now that we’ve mastered basic configuration of the popup blocker let’s move up to the big-time: adding new sites to the list of allowed sites. Oh, no, none of that: you are too ready for this. Trust us, it’s no harder than anything else you’ve done up to this point.

Having said that, however, this particular task does require a little bit of explanation. Allowed sites are found in the Software\Microsoft\Internet Explorer\New Windows\Allow portion of the registry. Each allowed site is a separate registry value within the Allow key. That makes sense. The quirky part is that each of these registry values is a “zero-length binary value.” In the Windows Server 2003 version of RegEdit, the allowed sites portion of the registry looks something like this:

We know what you’re thinking: “Wait a second, Scripting Guys: no one said anything about zero-length binary values.” You’re right, we didn’t. But that’s an easy enough oversight to take care of, and we’ll fill you in on the two minor changes required in order to write zero-length binary values to the registry. (And if that doesn’t impress your co-workers you might want to take their pulse, just to make sure they’re still with us.)

Before we launch into our explanation, here’s a script that adds www.microsoft.com to the list of allowed sites:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & _ 
    strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\Internet Explorer\New Windows\Allow"
strValueName = "www.microsoft.com"
strValue = Array()
objRegistry.SetBinaryValue HKEY_CURRENT_USER,strKeyPath, _
    strValueName,strValue

So what did we have to do in order to write zero-length binary values to the registry? (By the way, a zero-length binary value is just an “empty” registry value with the data type REG_BINARY.) First, we need to use the SetBinaryValue method; that’s something you probably already figured out. Second – and a little trickier – we need to use this code to assign a zero-length value to our variable strValue:

strValue = Array()

REG_BINARY data types typically deal with arrays of digits; because of that we need to pass an array to the registry value. The syntax Array() is the way to specify an empty array: an array with no values in it. This isn’t something you see every day, but it works.

And what if you’d like to remove a site from the Allowed Sites list? That’s even easier:

Const HKEY_CURRENT_USER = &H80000001

strComputer = "."
 
Set objRegistry=GetObject("winmgmts:\\" & _ 
    strComputer & "\root\default:StdRegProv")
 
strKeyPath = "Software\Microsoft\Internet Explorer\New Windows\Allow"
strValueName = "www.microsoft.com"

objRegistry.DeleteValue HKEY_CURRENT_USER,strKeyPath,strValueName

As you can see, we simply bind to the desired registry value; in this case www.microsoft.com. We then call the DeleteValue method to delete that value. That’s all there is to it. If you wanted to get fancy you could write a script that enumerates all the registry values found in the Allow key and then delete them all. But that’s a script we’ll let you figure out on your own. (Here’s a hint, though: this script shows you how to enumerate all the values found in a registry key.)

Questions? Comments?

That should do it for this month. If you have questions or comments about this article, please send them to scripter@microsoft.com (in English, if possible). And don’t forget to – that’s weird: we could have sworn we saw several little plastic moles – each carrying a hammer – peeking through our doorway. Nah….