The latest Scripting Guys' Webcast took place Friday, October 8th, and is now available from the TechNet Webcast archives in on-demand video form.

It's called Scripting with Microsoft Windows XP Service Pack 2: SOS! and you can find it at:
http://msevents.microsoft.com/cui/eventdetail.aspx?EventID=1032259299&Culture=en-US

By the way, you now need to register for the event to view the on-demand video afterwards as well as the event itself, so you have to click the "Register for event" link in the left-hand pane.

Here's what Greg said about it:

This Webcast -- to be presented by the scripting songbird himself, Mr. Peter Costantini -- ... will introduce you to some of the new scripting objects found in XP Service Pack 2. Perhaps more important, it will also tell you how you can get your scripts to work with Service Pack 2 in the first place; by default, the new Windows Firewall prevents you from using scripts to remotely manage a computer running Service Pack 2. But don't despair: Peter will show you how to work around that issue, as well as show you how to do such things as manage the new Pop-Up blocker in Internet Explorer.

The webcast goes into some depth on:

• Deploying and blocking deployment of SP 2 with scripting
• Re-enabling remote administration on SP 2 hosts
• Windows Firewall scripting
• Scripting networking configuration
• Scripting local security configuration
• Scripting Internet applications
• Other scriptable areas of SP 2

And it shows code examples for each area.

Here's a bit of dialogue from the section of the webcast on scripting registry changes:

Dr. Scripto:

The registry is Windows' heart of darkness.  Mister Kurtz designed it.

Peter:

Think back to that English lit class you used to fall asleep in.  Remember Joseph Conrad's novel?  What was that they said about Mister Kurtz? "Mistah Kurtz, he dead"  And not only is Mister Kurtz dead, but he didn't tell anybody where he put the blueprints for the registry.

So the registry has grown organically, with its own logic  It's really less a database than an ecosystem, a sort of mysterious and chaotic digital rain forest.  It's a place of teeming life ... and violent death.

Listen!  Can you hear that flock of DWORDS high in the treetops of HKEY_LOCAL_MACHINE?  And look!  There goes a sinuous REG_SZ slithering through the undergrowth of HKEY_CLASSES_ROOT!

We can never tame the registry, but with patience we can learn to appreciate the ebb and flow of its seasons.  And very cautiously, we can make small changes in it.  Now as you may be aware, that's a controversial topic.

Mark Minasi, the columnist for Windows IT Pro magazine, has suggested that the standard registry warning in our documentation should be changed to read: "Manually changing the registry can cause sudden involuntary sex change."

Now Mark is a very smart and funny guy, but there is absolutely no truth to his allegation.

I do admit that we have heard completely unsubstantiated rumors that scripting the registry can cause hair to grow on the palms of your hands and, in extreme cases, temporary blindness and insanity.

But we want to reassure you that we have not been able to verify one single case of this and that there is almost no chance that this will happen to you.

BabyScript

When I showed these scripts to Dean, he thought there had to be an easier way to recurse through a directory tree with WMI, and he found it.  The only caveat is that you must run it on Windows XP or Windows Server 2003.  This is because WMI Query Language, the SQL dialect that you use with the ExecQuery method of SwbemServices, first added the LIKE keyword in Windows XP (see http://msdn.microsoft.com/library/en-us/wmisdk/wmi/like_operator.asp).

In this case, LIKE enables you to query for all directories that contain a specific string, surrounded by percent signs, for example: "%c:\\ff%" (remember that WQL queries require two backslashes rather than one to delimit file paths).  This would include all subdirectories of c:\ff and their subdirectories.  In other words, LIKE enables you to use WQL's equivalent of wildcards.  You can also use the percent sign at just one side of the string.  In this script we use "c:\\ff%", which returns any path on c: drive that begins with "ff".  Keep in mind that this will also return not just the subdirectories of c:\ff, but also any other top level folders that begin with ff, such as c:\ffx.

The query including LIKE in this script seems to run very slowly, at least on my computer.  That may be because my computer is old and cantankerous, like me.  Or it may be because WMI has to search the whole file system to make sure there are no other matches that are LIKE the string.

Here's Dean's script, which I suppose we could call Files-list-recurse-like-wmi.vbs, except that the name is getting too long.  Call it what you will.

BabyScript

If you attended Day 3 of the Scripting Week webcasts, "Scripting Files and Folders Makes Me Happy" http://go.microsoft.com/fwlink/?LinkId=30795, you may recall an odd and vaguely menacing script in the second section on WMI.  It bristled with strange code and was labeled "Bonus: listing a folder tree," but we didn't discuss it.  As Dr. Scripto said, merely looking at it could turn you to stone.

OK, so Dr. Scripto exaggerates a little.  But we're going to call that script the Medusa Code because it sounds cool, kind of like the name of an action movie.  We'll come back to the Medusa Code later, so stay on the edge of your seats.  But for starters we're going to talk about what the Medusa Code was trying to accomplish in the first place: listing a directory tree recursively.

Ah, "recursively": there's a word that rolls off the tongue!  Dr. Scripto loves to say it, although I had always suspected he wasn't too sure what it meant.  I wasn't either, so I got out my dictionary and checked.  There was no listing for "recursively," but it had a definition for "recursive": "1: of, relating to, or involving mathematical recursion."

Doh!  Of course!  Elementary, my dear Scripto.

Not being of a mathematical bent (I mean, being kind of bent, but not mathematically so), I forged ahead to the second definition: "2: of, relating to, or constituting a procedure that can repeat itself indefinitely or until a specified condition is met."

Hmmm, repeating itself indefinitely – sounds like Greg on a bad day.  At that point, I threw the dictionary on my main pile (my office is organized by piles) and opened Notepad.  When something doesn't make sense, it usually helps to open Notepad and start writing code.

At that point, Dr. Scripto whispered in my ear: "Don't worry about 'recursive.'  Just write a script that walks a directory tree and lists all the files and folders in each branch."  Aha, my muse had spoken.  "But that's not repeating itself indefinitely," I whined.  "No," replied Dr. Scripto, "just repeating itself until a specified condition is met.  And that condition?  That no more sub-folders can be found to recurse through."

If you'll recall from the webcast, with WMI you can easily display the names of all the files or folders on a computer or on a particular disk drive.  But you probably don’t need to do that too often, and when you do, it can take a long time.  When you get down to listing all the files or folders in a specific directory, you run into a shortcoming of some methods of the WMI file and folder classes: they only list the first level of files or folders even if there are sub-folders and files in them.  In other words, they don't walk down all the branches of the directory tree.  Ipso est, they're not recursive.

To show how to list a directory tree recursively, we're going to take a little detour back to the FileSystemObject.  You'll recall that the webcast began with FSO and worked up to the WMI file and folder classes.  So we'll follow the same path: before we get to WMI and the Medusa Code, it's a little bit easier to see how recursion works with FSO because the rest of the code is simpler.

Here’s a script that uses FSO to list all files in a folder and its sub-folders recursively (we'll call it Files-list-recurse-fso.vbs):

Here's the output I got by running the script on a test folder:

The script is pretty straightforward for the most part.  It gets the folder specified by the variable strFolder (in this case, c:\ff), then gets a collection of the files in that folder and loops through it with a For Each loop, displaying the full path of each one.  A nice feature of the FileSystemObject is that Folder objects include a Files property that's a collection of all the files in the folder.  How logical!  How'd they ever come up with that?

But take a closer look at that Sub.  What's it doing there?  By jingo, Dr. Scripto, it's calling itself!  Is that legal?  Actually, as Dr. Scripto reassures me, that's what a recursive subroutine does, kind of like a dog chasing its own tail.

Besides the Files collection, FSO Folder objects have a SubFolders collection that includes — you'll never guess — all the folders contained within the folder.  Very handy.  We can use SubFolders to loop through each subfolder in the top-level folder, then get the collection the files in each and loop through that, displaying each one.  Then, within the top For Each loop for subfolders, the sub-routine calls itself, passing itself the name of each subfolder in the collection successively.  This is the key to how it can drill down through the levels of a directory tree.  There are only three levels in the output example, but the script will keep drilling down — recursing — until it hits oil or the bottom level of the tree.

Is that crystal clear now?  If you want to see this in action (and think you can handle this much fun), you could run the script in the Microsoft Script Debugger and watch the variables change through all those loops.  If you start to get dizzy, just look away.  For more information, Greg talked about how to run scripts in the debugger during our August 4 webcast "What Do You Want To Script Today?" http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032255873&EventCategory=5

Incidentally, if you want to read a directory tree on a remote machine, FSO allows you to use a UNC path, such as "\\computer\share".  So you could change line 2 to:

strFolder = "\\server1\c$\ff"

and display that tree recursively, provided of course that administrative shares are enabled on server1 and that you have administrative credentials on the machine.

More soon about doing this with WMI.