I know—you're expecting me to write about the Microsoft judgement. But first, I have nothing to say that someone hasn't already said, and second, my opinion makes everyone mad. On the one hand, I agree that Microsoft violated the antitrust laws, and—like 'em or not—they are the law. But on the other hand, the forced-breakup-as-penalty seems a bit extreme, as if I'd been arrested for stealing a book from a bookstore, convicted, and then sentenced to the electric chair. But that's not what I want to talk about this month. Instead, I think I have a more important topic. These are important times for us administrator types. In addition to our other duties, we're getting a new one: programming.
But wait, wait, don't go—it's good news, trust me. One flaw of Windows NT 3.1, 3.5, 3.51, and (until recently) 4.0 has been lack of programmability. Many administrator tasks are both multistep and repetitive: create the user, don't forget to create the home directory, customize the logon batch script . . . But the automating tool has been administrator carbon units rather than programming-language-driven silicon units. Sure, we always had some ability to automate—the old limited DOS-derived batch language (the "son-of-a-batch" programming language, you might call it) and some very nice (and expensive) third-party tools. For most of us, however, automating regular tasks has been out of reach.
But browser compatibility may not matter if your goal is to write administrative scripts. If you learn how VBScript handles such items as Outlook Calendar objects in a browser, you're 99 percent of the way to writing Outlook Macros in Visual Basic for Applications (VBA), or standalone Visual Basic (VB) applications, or server-side ASP applications in—you guessed it—VBScript.
After all, you don't want to be the last administrator around still doing things by hand, do you?