Tales from the Script - February 2003
The Scripting Guide Giveaway: Everyone's a Winner!
When it was first announced that Microsoft was producing a Windows 2000 Scripting Guide, a lot of people were skeptical. A Scripting Guide? they said. Who cares about a Scripting Guide? You won't even be able to give those things away. Well, as usual, the Scripting Guys have proven the nay-sayers wrong: Not only can we give Scripting Guides away, we are giving Scripting Guides away. Over the next month, the Scripting Guys will be giving away 32 shiny new Windows 2000 Scripting Guides, all part of the great Scripting Guide Giveaway!
The Scripting Guys will now take questions from the audience:
Question: What's the largest city in Estonia?
Answer: Um, questions about the Scripting Guide Giveway.
Question: 32 is a weird number for a giveaway. Is that like some sort of fractal discombinatorial prime number used in advanced scripting algorithms?
Answer: Uh, probably. But the main reason we're giving away 32 copies is because we have 4 boxes of books, with 8 books per box. Four times 8 is just a second here carry the 2 hold on a minute. Look, we're just giving away 32, OK?
Question: Will you guys be autographing these books?
Answer: No. For one thing, some of the Scripting Guys have names like Wilansky and Costantini; the human wrist simply can't take the strain of writing Costantini 32 times (please do not try this at home). Besides, you're likely thinking, Wow, I could sell an autographed copy on EBay, and make millions. Unfortunately, though, we've discovered that things personally signed by the Scripting Guys actually tend to decrease in value.
Question: What do I have to do to win?
Answer: Practically nothing. Originally we thought it would be cool to make people write a script or sing a silly song or bake us chocolate chip cookies in order to have a chance to win. As it turns out, though, there are laws designed to protect people like you from people like us.
By the way, we'll accept entries through March 15. On March 16, we'll draw the names, and notify the 32 lucky winners via email.
Question: Can anyone enter this contest?
Question: Wow, even the guy who always spams you at firstname.lastname@example.org (in English, if possible), telling you that you can get 85% off on printer toner cartridges?
Answer (after checking with lawyers): Yes.
Question: Can I enter more than once?
Answer: You bet. Of course, we'll discard all duplicate entries before we draw names. But if you want to send us a million entries, that's up to you. (Besides, that way we can tell our bosses, Wow, we got over one million entries for this contest.)
Question: What if you get a million legitimate entries? Thirty-two books aren't very many in a case like that.
Answer: What, you think the Scripting Guys are made of money? But that's a good point. If we get a ton of entries, we'll see if we can get additional books to give away.
Question: Were Columbus' three ships the Nina, the Pinta, and the Santa Maria?
Answer:"Nina" was actually a nickname. The real name of the ship was the Santa Clara.
Question: What do we get if we enter but don't win?
Answer: Let's see, if you don't win, that must mean you lost, right? Since when do you get rewarded for losing? But, we'll tell you what: everyone who enters will get a software bundle consisting of the next three Scripting Guy utilities: Scriptomatic 2.0; the long-awaited ADSI Scriptomatic; and the oddly-named Comparomatic.
Question: But won't you be making those things available for free download anyway?
Question: I really, really want to win a Windows 2000 Scripting Guide. I have just one question: what the heck is the Windows 2000 Scripting Guide?
Answer: We knew somebody was going to ask this question. Fortunately, we happened to have this month's Tales from the Script column handy. Read on for more information about the Windows 2000 Scripting Guide.
Question: I'd still like to know which is the largest city in Estonia.
Answer: The largest city in Estonia is the one with the most people living in it.
On This Page
Want to learn how to script? Have we got a deal for you!
So you want to take the plunge and learn how to script, eh? At least that's what a lot of you are telling us:
"I want to learn how to script. Can you help me please?"
"Please advise me on how to start scripting. I'm a novice, and I need to learn scripting from scratch."
"I want to start learning about scripting for Windows 2000 and Active Directory. Can you advise me of a training course to start with?"
We hope you're not interested just because you've heard that if you learn scripting you'll soon be wearing a Rolex and driving a Jaguar. If someone has promised you this, it's probably one of the Scripting Guys hustling you. Be prepared for a follow-up offer of a slightly-used bridge in mint condition. Just the other day, a guy with a cap pulled down over his eyes — a guy who looked a lot like Greg (one of the Scripting Guys) — was standing on the corner outside our building with a sign that read: "Will script for Seattle Mariners tickets."
Seriously, though, thousands of satisfied users testify that scripting can help you do your job better and quicker, as well as make your operations run more smoothly and reliably—the correct buzzwords to use on your boss are "increased productivity." Scripting means less repetitious manual drudge work, fewer late nights, and more time for the family or meditation or trips to Vegas or bungee jumping or whatever lights up the rest of your life. What's that? Well, buddy, it's time to get a "rest of your life." (And if you happen to get two, any chance you could share one with us?)
Did we mention that learning how to script is definitely a good career move? The Scripting Guys are constantly besieged by headhunters offering us glamorous gigs with titles like "IT Deity" in world-class cities like Shanghai and Prague and ... OK, would you buy "temporary sales trainee" in Puyallup, Washington? We're working on our resumes.
Come to think of it, though, scripting is a sort of bridge, and a well-used one in some IT shops. It's a bridge between doing work manually in the UI and using full-fledged applications served up by a developer or consultant (who really does wear a Rolex and drive a Jag). You could also look at it as a kind of duct tape that can hold together your operations. And if you wrap enough duct tape around that bridge ... yes sir, the Scripting Guys do love an occasional mixed metaphor, preferably over crushed ice—shake, don't stir.
All right then, if you're ready to let scripting into your heart and say "Yes, Scripting Guys! I'm all over it! I'm a scripting animal!" then have we got a deal for you.
All New! Award-Winning! Hot Off The Presses! World's Greatest Scripting Guide!
Actually, that's a lie—it hasn't won any awards yet, but we're buying futures on margin that it will. It really is hot off the presses, though (in fact, wed recommend taking a pair of oven mitts with you to the bookstore). Chest-thumping aside, we're tickled to announce that our Windows 2000 Scripting Guide is now available through and on the shelves of a bookstore near you. You say you left your wallet in your other pants? No problem: you can also read the content online here. Either way, we hope you find it useful—please let us know what you think.
OK, lets assume you've run to the store and elbowed through throngs of frenzied technophiles to snag a copy; what do you do with it now? (Only computer people would buy a book and then have to ask, Now what do I do with this?) Well, the beauty of a book, as opposed to reading something online, is that you can curl up in bed with it. Of course, if you fall asleep with the Scripting Guide on your chest, the weight of nearly 1,300 pages might crush your ribcage. So take it out on the deck, lanai, patio, porch, courtyard or other locus of deep contemplation, pour yourself a suitable libation, and thumb through it.
One Way to Read the Scripting Guide
We know you're planning to read the book cover to cover (or at least you're telling us that so you won't hurt our feelings). However, unless you are an accomplished speed-reader, you'll more likely end up sampling a bit here and a bit there, trying out some scripts, and returning to read more about how they work. We can't lay out a roadmap for everyone, but this column will suggest a possible itinerary.
Before we do that, however, let's answer a question that we get asked over and over: This can't possibly be your real job, can it? Oh, sorry, we meant the other question we get asked over and over: Why did you choose VBScript as the language for this book?
Why? Well, mostly because it seemed to be the language best-suited for working with WSH, WMI and ADSI, the technologies that actually make the wheels turn. VBScript is more approachable and English-like than C-family languages such as JScript and Perl. That's an important consideration for newcomers or for system administrators who might have taken a Visual Basic course somewhere along the road. Looking at the other end of the spectrum, VBScript is more powerful and offers access to wider coverage of the operating system than batch files do. And, let's face it, the Scripting Guys are never shy about hopping on a bandwagon: VBScript is by far the most popular scripting language for administering Windows.
That said, the "best" programming language is largely a matter of personal preference; if you are already more comfortable with, say, Perl, you can still learn a lot from this book. Windows scripting technologies are based on the Component Object Model (COM), and any language with a WSH-compatible language engine (which is to say most popular scripting languages) can work with COM automation. Most of the examples of system-administration scripting out in the world we're written in VBScript; because of that, you're probably already adept at translating them to your favored language. And remember: regardless of the language you use to write scripts, you still have to use WMI or ADSI to carry out useful tasks. And the Windows 2000 Scripting Guide is, to say the least, chock-full of WMI and ADSI information you won't find anywhere else.
If you are a batch-file wizard, you can check out an alternative way of doing things and see which methods work best for the tasks you need to accomplish. If you love certain command-line tools and use them all the time, it's easy to call these tools from a script, something which can give you more control over program logic, input, and output. For an overview of mixing scripts and command-line tools, see Tales from the Script - October 2002 - "Running Programs From WSH Scripts" on TechNet Script Center.
Now, let's crack open the book. As you peruse the Scripting Guide contents, you'll notice that the book is organized into three sections:
Part I: Scripting Concepts and Technologies for System Administration
These are conceptual chapters that cover in depth the major technologies that enable Windows system-administration scripting: VBScript, WSH, the Script Runtime Library, ADSI and WMI.
Part II: Scripting Solutions for System Administration
This is the heart of the book: chapters organized by task areas that show you how to script specific administrative tasks. Chapters include Active Directory Users; Computer Assets; Computer Roles; Disks and File Systems; Files and Folders; Logs; Printing; Processes; Services; and Registry.
If these sound like the sorts of things you deal with on a daily basis, well, that was the idea: we wanted to show you how to automate those mundane but time-consuming tasks that you have to do day after day after day. In other words, scripting is just another way of doing what you do anyway. You've heard of disk quotas, right? Well, here's a way to script disk quota administration. You need to manage services, don't you? Here's a way to manage services using scripts. There's nothing magical or mysterious about it.
Part III: Scripting for the Enterprise
These chapters, also organized around tasks, cover guidelines and techniques for scripting in an enterprise environment with many servers and many clients and numerous system administrators. The scripts presented in the task-based chapters are generally pretty simple: they back up event logs on one computer. We did that for pedagogical reasons: that keeps the scripts simple, it keeps the scripts short, and it focuses your attention on the meat of the script, in this case the few lines of code required to back up an event log.
On the other hand, we know this isn't how things works in the real world. In the real world, you want to back up event logs on all your computers. And you want the script to keep a log of which backups succeeded and which backups failed. And you want your script to be robust; you don't want it to crash just because 1 of your 5,000 servers was offline. These are the things you'll find in the Enterprise chapters: we show you how to take the simple little scripts found throughout the rest of the book and enterprise-enable them.
A Note or Two About Part 1
Now, be forewarned that the scripting concepts and technologies in Part I are very hard, so hard that you need —at least— an advanced degree in mathematics to understand them, so hard that no system administrator should even open these chapters because they might instantly turn your brain to jelly. At least that's what some people say about these technologies. We believe, on the contrary, that you can pretty quickly learn enough about them to begin using them for practical purposes; in fact, with a reasonable outlay of effort, you can even master their use for scripting. We also believe it's worth your while: by harnessing the power of these technologies and learning how to explore them, you give your scripts access to nearly all areas of the Windows operating systems, the directory service, and much more. Over time, as you become more experienced in using the technologies, you can return to these chapters and dig into the underlying concepts more deeply.
In fact, this is the thing that really separates the Windows 2000 Scripting Guide from other scripting books on the market. In most scripting books, core technologies such as ADSI and WMI are, at best, given a 30-page chapter (or are even forced to share such a chapter). In the Windows 2000 Scripting Guide, you'll not only get 100+ pages of ADSI information and 100 more pages of WMI information, but the rest of the book uses those two technologies almost exclusively. Why? Because this is a system administration Scripting Guide, and you can't write system administration scripts without using ADSI and WMI. Other than a few code snippets designed to teach a particular point, the scripts found throughout the Windows 2000 Scripting Guide all carry out useful system administration tasks. If you're looking for a Hello, World script, you bought the wrong book.
Note: Sorry, but if you were looking for a Hello, World script we can't give you your money back. However, we can give you a Hello, World script, absolutely free:
Wscript.Echo Hello, World.
Here's a reading plan for a first pass through Part I: it involves reading the Introduction and the first sections of the VBScript, WSH, WMI and ADSI chapters, 110 pages in all. And of course, you should try as many of the scripting examples as you have time for. By the time you're done, you should have a much better understanding of the roles these technologies play in Windows scripting.
Read all: pp. 3 - 14
Read VBScript Overview: pp. 15 - 46
Read WSH Overview, WSH Architecture & Running WSH Scripts: pp. 129 - 147
Read ADSI Overview & ADSI Scripting Fundamentals: pp. 309 - 335.
Note that even if you don't use Active Directory or another directory service, you can still use the WinNT provider for tasks related to local users and groups.
Read WMI Overview & WMI Architecture: pp. 427 - 446
You can come back later and read Chapter 4 "Script Runtime Primer." This chapter discusses the FileSystem Object and the Dictionary Object, both of which are useful aids for scripting but are not essential to cover on a first pass. After that, you can read the remaining parts of the conceptual chapters as the need and opportunity arise.
Actually Getting Work Done
Oops, we're sorry we said that. We know that some of you (and some of us) are severely allergic to this concept. On the other hand, most of us do like paychecks, and getting work done is a good way to ensure that they keep coming. In that spirit, let's look at the task-based chapters of the Scripting Guide.
We suggest beginning with a task area with which you already have some experience. Chapter 8, "Computer Assets" (for example, deals with common tasks such as inventorying computer hardware, managing operating systems, upgrading software and managing recovery options. Chapter 11, "Files and Folders", also covers ground familiar to many sysadmins.
Read the introduction to the chapter and skim the rest to see what kinds of tasks it discusses. Choose a few of the tasks with which you are already familiar. Try performing the task as you usually would in the GUI or with a command-line tool. Then read through the script, type it into Notepad, and try running it.
Let's say, hypothetically, that you have to do an audit in which you identify the version of Windows running on all your computers, as well as any service packs and/or hot fixes that have been installed on these computers. The "Computer Assets" chapter contains a section called "Managing Operating Systems" which covers such things as:
"Identifying the Name and Version Number of the Operating System"
"Retrieving the Properties of the Operating System"
"Identifying the Latest Installed Service Pack"
"Enumerating Installed Hot Fixes"
If you want to, you can walk around to all your computers, start up the System Information utility on the first one, and check the operating system version and service pack number. ("Version" lists the most recently installed Service Pack after the version and build numbers.) On Windows XP, you should see something like this:
You can write down the name of the computer, the operating system version and service pack number, and then try to figure out how to find out all the hot fixes that have been installed on the computer (Hint: Check Add or Remove Programs). When you're done, you can walk over to the next computer and repeat the process.
Or you can sit at your desk, put your feet up, and run Listing 8.8, "Identifying the Latest Installed Service Pack".
When that's done, run Listing 8.9, "Enumerating Installed Hot Fixes", to find out which ones are installed on your box. And then decide for yourself which approach is easier.
Try working through at least a couple more chapters from Part II in this way. Chapter 9, "Computer Roles", might be a worthwhile one as the tasks involve both WMI and ADSI. Or check out the chapter on event logs. Did you know you can use a script to mine an event log for information? Did you know you can backup and clear event logs using a script? Oh, OK. Well, maybe someone you work with didn't know that.
Finally, thumb through Part III: Scripting for the Enterprise (unless you're reading the book online; you don't want to get thumbprints all over your monitor). Much of Chapter 17, "Creating Enterprise Scripts", discusses more advanced (but not tricky) techniques that are particularly helpful within larger organizations. "Retrieving Arguments," pp. 1060 - 1072, discusses techniques for running scripts against multiple computers, one area where the usefulness of this model of scripting shines through. The November "Tales from the Script" column on TechNet, "Running WMI Scripts Against Multiple Computers" covers related topics.
As a more challenging exercise, try inventorying the OS versions, service packs and hot fixes installed on a group of computers by putting together one of these techniques for running against multiple computers with Listings 8.7 through 8.9 in the "Computer Assets" chapter.
Chapter 18, "Scripting Guidelines", contains some useful suggestions on naming conventions, script construction and formatting, and debugging that can be helpful during the learning process. Try constructing a meta-template for your needs based on these ideas, then plug in code from the more specific functional templates in the WMI and ADSI chapters.
Congratulations, you're now a survivor of an exploratory pass through the book. Beware of used bridges and keep your roll of duct tape at the ready. The road is wide open and the wind is in your hair. Only you know where you want to go next. But do check back on the TechNet Script Center periodically for new scripts and columns. And wherever the road takes you, don't forget to send a postcard (or e-mail) once in a while.
Late-Breaking News: A New Scripting Newsgroup
Microsoft now has a new newsgroup devoted to system administration scripting: microsoft.public.windows.server.scripting (available from the news server news.microsoft.com). Here at Scripting Guy World Headquarters, we get —literally— hundreds of email questions each month. To be perfectly honest, that's a little more than we can handle; consequently, we aren't always able to answer each question that comes our way. (If you wrote to us and we never replied, sorry.) We think the newsgroup might help, and for at least two reasons: 1) we won't have to keep answering the same question over and over; and, 2) we won't have to answer all the questions ourselves; we assume that, eventually, you scripters will be able to answer most of the questions yourselves. (But don't worry; this newsgroup is our responsibility, and we'll always play a very active role in it.)
Anyway, if you have a question about scripting (like "How do I stop a service using a script?" or "Can I write a script that identifies all the users whose password is about to expire?") we encourage you to post the question in the newsgroup; if you do, you're all-but guaranteed to get an answer. You can still write to us at email@example.com (in English, if possible), but, again, we can't promise we'll be able to answer you. Ideally, we'd like to see technical questions about scripting posting to the newsgroup, and firstname.lastname@example.org (in English, if possible) used as a way for you to give us feedback/criticisms/suggestions on the Script Center and any of our related projects. Hey, give the newsgroup a try, and let's see what happens.
For a list and additional information on all Tales from the Script columns, click here.