This download contains documentation and scripts for handling issues of application compatibility that also deal with problems that most sysadmins will face in deploying SP2.

On the Scripting Solutions Center of TechNet Script Center we've posted a set of supplemental scripts with their own readme that show how to perform most of the tasks in the Application Compatibility Guide, using WMI or the new Windows Firewall COM object model.  The Guide's scripts use mostly WSH and batch files.  The two sets of scripts complement each other -- there's something for everyone's needs and scripting preferences.

Windows XP Service Pack 2 Application Compatibility - Supplemental Scripts

Let us know how you're handling the deployment and management of SP2 and what issues you're encountering at:
scripter@microsoft.com

It's called Scripting with Microsoft Windows XP Service Pack 2: SOS! and you can find it at:
https://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 https://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.

Now that we've glanced at recursion out of the corner of our eye (on Day 1) and lived, it's time to stare straight-on into the unspeakable horror of the Medusa Code.  If you have sunglasses, please put them on now.  If you try to speak its name, Files-list-recurse-wmi.vbs, we won't be responsible for what might happen to your tongue.

Here's the output from the same test folder:

Hmm, looks kind of familiar, doesn't it?  You mean, it takes all that code in WMI to produce the same output?  Yep.

Actually, this script goes beyond the bonus script in the webcast.  That one only listed folders and subfolders.  This one displays the full Monty, folders, sub-folders and all their files.  But it takes quite a few more lines of code than the FSO version.

We start out by assigning the drive and top folder names separately, so we can take them apart later.  WMI lets us (or makes us) define the elements of a file path separately.  Then we'll query the CIM_DataFile class for file instances, filtering with the separate drive and path variables.  Note the lovable quirk of WQL that we have to put double backslashes on both sides of the path.  This gives rise to some of the contortions in this script, as other methods of the class require a path separated by single backslashes rather than double ones.  VBScript is there to help with the Replace function, that lets us pass it a string, a substring to replace and second substring with which to replace the first.  So we use it to replace double backslashes with single backslashes and vice versa.

At this point, we've only listed the files in the top folder.  What to do next?  Well, at this point we need a way to get at the subfolders in the current folder, but Win32_Directory doesn't give us anything as handy as the FSO SubFolders property.  What we do have, though, is something called an association class.

Now both Greg and Dr. Scripto told me not to talk about association classes, and even Dean had reservations.  That way lies madness, they said.  Association classes are so Byzantine, so baroque, so rococo, that people will run screaming away from scripting and never return.  OK, I said, I’m sure they’ll take it on faith that they just work.

Then I tossed and turned that night because I knew I couldn’t do this to our readers.  So here’s what an association class is: a class that associates two other classes or managed resources.  So far, so good.  In this case, the association class is Win32_Subdirectory, which associates two different sets of instances of Win32_Directory.  One of the two Win32_Directory instances is called GroupComponent, and it represents the parent directory of the two related instances.  The other is called PartComponent, and it represents the subordinate directory or directories in the relationship.

So when this ASSOCIATORS OF query:

"ASSOCIATORS OF {Win32_Directory.Name='" & strName & "'} " _

 & "WHERE AssocClass = Win32_Subdirectory " _

 & "ResultRole = PartComponent"

filters for "ResultRole = PartComponent", it's asking for the directories that are subdirectories of the directory specified by strName.  The query returns a collection of these associated subdirectories, which we assign to an object reference, colSubFolders.

If you want to pursue this, the WMI SDK documentation for Win32_Subdirectory is at:

https://msdn.microsoft.com/library/en-us/wmisdk/wmi/win32_subdirectory.asp

Besides using the keywords “ASSOCIATORS OF” in a WQL query, as this script does, you can also call the AssociatorsOf method of the SwbemServices object, which is the kind of object referenced by objWMIService in this line:

Set objWMIService = GetObject("winmgmts:\\" & strComputer)

Then when you call objWMIService.AssociatorsOf(parameters), the only required parameter (there are also several optional ones including association class) is the object path of a managed resource or resources, such as:

"Win32_Service.Name='Alerter'"

Other association classes work in slightly different ways, but all enable you to associate related instances of classes.  For a fuller explanation of association classes, see:

• "Declaring an Association Class" in the WMI SDK (this one is at a system programming level)
  https://msdn.microsoft.com/library/en-us/wmisdk/wmi/declaring_an_association_class.asp
• ASSOCIATORS OF Statement
  https://msdn.microsoft.com/library/en-us/wmisdk/wmi/associators_of_statement.asp
• SWbemServices.AssociatorsOf in the WMI SDK
  https://msdn.microsoft.com/library/en-us/wmisdk/wmi/swbemservices_associatorsof.asp
• "CIM Class Types" in the Windows 2000 Scripting Guide
  https://www.microsoft.com/resources/documentation/windows/2000/server/scriptguide/en-us/sas_wmi_kzqu.mspx

Have you run screaming yet?  If not, you've become one of the few, the proud, the ASSOCIATORS.  We're working on a secret handshake, but you can tell members of the confraternity by the glazed look in their eyes.

But we're not quite done yet.  Once we've used the association class to get the subfolders, we still have to loop through the collection and then, as with FSO, the subroutine has to call itself recursively to loop through any subfolders of the subfolders.

I hope it goes without saying that if you wanted to perform this astounding feat on a remote machine, you could just change line 1 to:

            strComputer = "computer1"

where computer1 is an accessible host on your network on which you have administrative privileges.

So we've done it.  We've actually walked a directory tree using both FileSystemObject and WMI.  Let the high-fiving and end-zone dances (or, for those of the soccer persuasion, "Gooooooooool" celebration) begin.

I know you're thinking to yourselves, but you're too polite to ask: Um, couldn't you do all this in one line with dir /s?  Well, actually, um, I guess so (Dr. Scripto, help me out here!).  But then we wouldn't have had all this fun.  Nor would we appreciate what dir has to do under the hood.  If you ever wanted to customize this or add some functionality that does something to or within the resulting directory tree, you wouldn't know how.  And, most important, we would not have achieved such a deep understanding of extreme file and folder scripting with both FSO and WMI.

If you attended Day 3 of the Scripting Week webcasts, "Scripting Files and Folders Makes Me Happy" https://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?" https://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.