One of the developer resources useful to IT folks that you might overlook in the vastness of microsoft.com is -- deep breath -- the Application Compatibility Testing and Mitigation Guide for Windows XP Service Pack 2

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

BabyScript

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:

http://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)
  http://msdn.microsoft.com/library/en-us/wmisdk/wmi/declaring_an_association_class.asp
• ASSOCIATORS OF Statement
  http://msdn.microsoft.com/library/en-us/wmisdk/wmi/associators_of_statement.asp
• SWbemServices.AssociatorsOf in the WMI SDK
  http://msdn.microsoft.com/library/en-us/wmisdk/wmi/swbemservices_associatorsof.asp
• "CIM Class Types" in the Windows 2000 Scripting Guide
  http://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.

One of the reasons I thought we should do a scripting blog is because there are a lot of things (like book reviews) that we can’t do on TechNet. Being somewhat naïve, I thought the other Scripting Guys (who actually read computer books) would jump at the chance to share their opinions with you. So far, though, they’ve kind of wienered out on me. I’ll keep pushing them, however, because I know they have a lot of interesting things to share with the scripting world.

(I’d encourage you to send angry emails to scripter@microsoft.com and shame them into contributing to the blog. But – sigh – at the moment I’m the only one who reads and replies to those emails, so ….)

So why can’t I just do book reviews myself? Well, I have a confession to make: I don’t ever read computer books. (I’m not saying that’s good or bad, that’s just the way it is.) One time, when I worked at the University of Washington School of Dentistry doing computer support stuff, I had to swing by the Dean’s Office on my way home to show someone how to do a mail merge in Word. (Back then my days seemed to consist solely of showing people how to do a mail merge in Word.) I set my book (The Collected Stories of P.G. Wodehouse) down and helped the receptionist with her mail merge problem. As I was doing so, our administrative assistant popped by and picked up the book. “Oh, I love P.G. Wodehouse,” she said. “Whose book is this?”

“Mine.”

“No, really; whose book is this?”

“It’s mine.”

“No, really, I just want to know whose – fine, don’t tell me.”

No one would believe that I didn’t spend my free time reading about computers. But it’s true.

Here’s another shocker: Up until I couple weeks ago, and before I finally succumbed to family pressure, we had no Internet connection at home. (I know, it’s hard to believe that people could even live in such primitive conditions.) And I won’t even mention the fact that we don’t have digital cable and that I don’t have a cell phone; I don’t want anthropology students hanging around trying to determine whether or not I’m the missing link. (Although the truth is, even the Neanderthals tend to roll their eyes whenever my name gets mentioned.)

The interesting thing, of course, is that people always ask me if I can recommend a good scripting book; heck I can’t even recommend a bad scripting book. In my defense, though, I will say that prior to joining the Scripting Guide team, I had no reason to read a scripting book (not when there are books like Sometimes a Great Notion and Catch-22 out there). And after joining the Scripting Guide team, I specifically chose not to read any scripting books. That might seem like a dumb idea when you consider the fact that I didn’t know much about scripting, but I decided that I didn’t want to be unduly influenced by what other people had or had not done. Besides, if I was writing about scripting during the day, I didn’t want to go home and read about scripting at night.

In fact, up until last week the closest I had ever come to reading a scripting book occurred when I read selected parts of two books on WMI written by Alain Lissoir. These books, by the way, are great; you can’t believe how much information Alain has packed into two little volumes. Be aware, however, that neither book is aimed at beginners; if you don’t know anything about WMI, I’d strongly suggest that you start with the WMI Primer in the Windows 2000 Scripting Guide and then move on to Alain’s stuff. However, if you’re fairly comfortable with WMI scripting and at least somewhat familiar with WMI terminology, then I definitely recommend Alain’s books. (The only problem I have with them is that he’s pretty much explained everything there is to know about WMI; he didn’t leave anything for the rest of us.)

By special request, however, I was asked if I would read a new book – Administrator’s Top 10 Introductory Scripts – by Jeff Fellinge. And so I did. Like I said before, I’m not overly familiar with the genre, but as near as I can tell Jeff has taken a different tack here. What he’s done is written 10 full-scale production scripts (a logon script; a script that lists Active Directory accounts due to expire; a worm vulnerability detector; etc.). He’s then used those scripts as the basis for individual chapters in the book, methodically working his way through each script, explaining how the different sections of each script work. (Incidentally, I'm not convinced that these are the top 10 scripts, but they're useful and interesting nonetheless.)

I really like the fact that Jeff has chosen to write full-featured scripts, scripts that can do things like handle command-line arguments. Why? Well, a lot of people get their scripting information from the TechNet Script Center. Nothing wrong with that, except in the Script Center (as I’ve noted before) we specifically shy away from full-scale production scripts (that is, scripts that use error handling and accept command-line arguments and carry out multiple functions and ….). We always tell people that they can take our little code snippets and knit them into a full-scale production script, but we’ve never shown them any examples of this. Fortunately, Jeff has done that for us. That alone makes it a worthwhile addition to the scripting oeuvre. (See, if all I ever read was computer books, I wouldn’t know how to toss in high-falutin’ words like oeuvre.) We Scripting Guys tend to emphasize the “quick and dirty“ approach to scripting, and that has its benefits. At the same time, however, there are also benefits to using scripting as a way to create more sophisticated utilities. That's the direction taken in this book.

In addition, Jeff has also written these scripts in Jscript. I know there are lots of Web page scripting books that use Jscript, but there are few – if any – system administration scripting books that use Jscript. Yet another first, and a welcome one at that. Although I do everything in VBScript, I like seeing books that use other scripting languages to carry out system administration tasks. That helps drive home the point that it doesn’t really matter, that you should use the language you’re most comfortable with. I know that, because of the Web, a lot of people are familiar with Jscript; I think it’s great that there’s now a book that shows them how to apply their Jscript skills to system administration scripting. I’d hate to think that people might spend years honing their Jscript knowledge, only to feel they had to learn an entirely new language in order to do system administration scripting. You don't, guys. As long as your scripting language can work with COM objects (like WMI and ADSI), well, the language you choose to use is as much a matter of personal preference as it is anything else.

In fact, the one criticism I have of the book is that it doesn’t use Jscript exclusively. The introductory chapters, for example, tend to jump back and forth between VBScript and Jscript, showing concept A in VBScript, concept B in Jscript, etc. To be honest, I’m not sure there’s much to be gained by that. Later on, the big production scripts are written in either Jscript or VBA . Why VBA? Well, in several scripts Jeff use Microsoft Excel as the UI for his scripts, typically returning information from a number of sources and then writing that information to a spreadsheet. I would have liked it better had there been an exclusive focus on Jscript. The truth is, if you’ve decided to use Jscript, well, then who cares how the same operation is carried out in some other language? As the saying goes, ya gotta dance with whut brung ya.

And using nothing but Jscript wouldn't keep you from stashing data in Excel; instead of starting Excel and then running a VBA script, you could start a Jscript script and then launchand manipulate Excel from within that script. Because VBScript, Jscript, and VBA are not alike, I’m afraid people might get a bit confused by some of these scripts; all the more reason to stick with one language all the way through. Interestingly enough, Jeff uses an HTA to serve as the UI for another script. Why not use HTAs throughout the book rather than Excel? To me, it seems like overkill to use Excel simply as a way to store tabular data.

But those are minor quibbles. There is still a lot of interesting code in here, and the next time you’re in your neighborhood bookstore, it might be worth your while to check it out. It’s nice, too, because the book deals with Windows XP and Windows Server 2003. I feel that we Scripting Guys helped jumpstart system administration scripting in Windows, but then we kind of dropped the ball by not following up our Windows 2000 book with an XP/2003 book. I think it’s great that people like Jeff are picking up the slack for us.

By the way, seeing as how the other Scripting Wieners – um, Scripting Guys have chosen to remain silent, I’d be interested in hearing about books that the rest of you have found interesting. If you have a favorite or two, by all means, let us know.

Yesterday was an interesting day. I went into the little editor they have for this blog site, and – like I always do – copied the day’s entry out of Word and pasted it into the editor. Everything looked hunky-dory, so I clicked the Submit button, logged out, and went back to work.

A little while later, I got a couple of emails telling me that the bottom half of the article was unreadable. That’s nothing new; heck, most of the things I write are unreadable. When I went and looked at the blog, though, it turns out that it really was unreadable: words and sentences were cut in half, margins were out of whack, there was a weird grey box in the middle of the post, etc. All in all, pretty dang weird. I assumed the problem was with some HTML code that I had included in the post, so I tried taking that out and re-posting the article. That didn’t help: even with the HTML removed, I got the same screwy results. I put the HTML back in; same thing. Took the HTML out – well, you guessed it.

At that point I decided to try andedit the HTML of the article itself. Holy smokes; what a bad idea that was! Turns out that this blog uses Microsoft Word-like (in other words, crazy) HTML. For example, I would have thought the HTML for the first paragraph of this post would look something like this:

{P}Yesterday was an interesting day. I went into the little editor they have for this blog site, and – like I always do – copied the day’s entry out of Word and pasted it into the editor. Everything looked hunky-dory, so I clicked the Submit button, logged out, and went back to work.{/P}

Note. To try to avoid problems, I’m using curly braces like these {} rather than traditional HTML tags, at least until I figure out how this all works.

Instead, it looks like this:

{P class=MsoNormal style="MARGIN: 0in 0in 0pt"}{SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"}Yesterday was an interesting day. I went into the little editor they have for this blog site, and – like I always do – copied the day’s entry out of Word and pasted it into the editor. Everything looked hunky-dory, so I clicked the Submit button, logged out, and went back to work.{/SPAN}{/P}
{P class=MsoNormal style="MARGIN: 0in 0in 0pt"}{SPAN style="FONT-SIZE: 10pt; FONT-FAMILY: Arial"}{?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /}{o:p}{/o:p}{/SPAN> {/P}

Every individual line in the sample HTML code I posted was surrounded by paragraph tags and span tags and style and font parameters and, well, it was all very … interesting …. And so I tried dutifully to edit each line. I’d make the changes, click the Submit button … and all the weird formatting and weird tags would get added back in, and I’d be left with an unreadable page once more. Eventually I copied the thing out of the blog editor, pasted it into Word, saved the document as a Word file, reset all the formatting, replaced the HTML tags with curly braces, copied the revised article, and pasted it back into the blog editor. That did the trick, but I still don’t know what went wrong, nor do I know why I wasn’t able to fix it. Yet another thing to put on my to-do list, I guess.

Of course, I should be used to spending my time figuring out why you can’t do something that seems so simple. Last Friday, for example, I got an email from someone in Microsoft, a guy who actually does our logon scripts (and does some pretty slick things, by the way). He had what sounded like a simple request: he needed to find a way to list:

• Internet Explorer add-ins (the things found in C:\Windows\Downloaded Program Files).
• Microsoft Outlook add-ins.
• Windows Explorer add-ins.

He couldn’t figure out how to get at any of these things, and wondered if there was something he was missing. (Actually, what he was missing the first rule of scripting, which is: You can always script anything except what you need to script this very moment.)

As it turned out, he was missing a couple things, though I can’t really blame him for not knowing about them. For example, this script will return the items found in C:\Windows\Downloaded Program Files:

strComputer = "."

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

    & "\root\cimv2\Applications\MicrosoftIE")

Set colIESettings = objWMIService.ExecQuery _

    ("Select * from MicrosoftIE_Object")

For Each strIESetting in colIESettings

    Wscript.Echo "Code base: " & strIESetting.CodeBase

    Wscript.Echo "Program file: " & strIESetting.ProgramFile

    Wscript.Echo "Status: " & strIESetting.Status

    Wscript.Echo

Next

How come he wasn’t aware of this? Well, look at the WMI class being used: root\cimv2\Applications\MicrosoftIE.MicrosoftIE_Object. No one has ever heard of this class before; as near as I can tell it’s never been documented anywhere. In fact, there are a number of classes in the root\cimv2\Applications\MicrosoftIE namespace that might be useful to people. But, again, no one even knows about them. (We do have some sample scripts in the Script Center that use these classes, but they’re buried in some nebulous category like Computer Management, and it’s no wonder no one ever sees them. But that’s an issue we’ll take up some other time.)

So how did I know about them? Well, a few months ago, when I was bored, I opened up Wbemtest and just started clicking around, seeing what was in there. Root\cimv2\Applications\MicrosoftIE happened to be one interesting namespace I found. (Note: You might not have this namespace and these classes on your machine. I think they are automatically installed along with IE 5.5, but I could easily be wrong about that.) Another interesting namespace is root\WMI. There are a bunch of classes in this namespace, many of which don’t return any data, but others which do return data. For example, there are a lot of classes that start with MSNdis_80211 which return information about wireless networking. I haven’t had a chance to really dig into these and see how useful they are, but they sure look useful. But, again, undocumented. And not because they’re top-secret and confidential, just because, well, they’ve never been documented.

And because I’m running Office 2003, I have a namespace called root\MSApps11. Sure enough, there’s a class in there that lets me get at the Outlook add-ins. (One caveat: this thing won’t return any data unless Outlook is running.) Thus:

strComputer = "."

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

    & "\root\MSApps11")

Set colSettings = objWMIService.ExecQuery _

    ("Select * from Win32_OutlookCOMAddin")

For Each strSetting in colSettings

    Wscript.Echo "GUID: " & strSetting.GUID

    Wscript.Echo "Path: " & strSetting.Path

    Wscript.Echo "Name: " & strSetting.Name

    Wscript.Echo "Installed: " & strSetting.Installed

    Wscript.Echo

Next

Once more, undocumented, even though there are classes in there for all the Office apps. (Again, one problem with these is that the apps typically have to be running before you can get at the data.) Useful stuff? I can't say for sure. But some of it looks very useful. (Like, say, being able to know what Outlook add-ins people have installed on their computers.)

I never did find a way to get at Windows Explorer add-ins, but that doesn’t mean there isn’t one, it just means I haven’t stumbled across it.

Obviously this is a problem: there are millions of unwritten scripts lying around simply because people don’t know they can even write those scripts. We get emails all the time from people asking, “How can I know what things I can script on my computer?” or “Can you point me to the one spot where I can find information about all the object models and all the things I can script?” The truth is, we don’t have an answer for them. (Well, unless you consider, “You can’t” or “No” as answers.) This is something we’d love to address in some way, but we haven’t yet come up with anything that seemed reasonable. In the meantime, don’t be afraid to open up Wbemtest and poke around. Likewise, there’s an object browser for scripting called TLViewer that can be useful (though it does have a few quirks). And, of course, the Object Browser in Visual Studio is pretty handy, though buying Visual Studio just to look at a few COM classes might be overkill. I’d be interested in hearing how other people hunt down scriptable items, and any suggestions you might have for ways we can make these items more discoverable to people.

As for me, I’ve got HTML fish to fry.