Hate it or hate it more, product activation is a necessary evil in the XP world. Here’s how to ease the pain.
- By Chris Brooke
- September 01, 2002
The IT world is replete with controversy: Unix vs. NT, Java vs. .NET,
pizza-and-beer vs. “just” beer. For example, if you ask 100 Windows administrators
what feature they’d like to see in the next version of Windows, you’ll
likely get 100 different answers—each vehemently defended. However, there
are some areas in which partisan differences are set aside, and we come
together in harmony. Case in point: If you ask a group of network administrators
what Windows feature they’d like to see removed, they’ll probably reply
in one voice: “Product Activation!” The decision by Microsoft to include
activation in Windows XP has caused the most amount of hate mail from
administrators since Microsoft tried to retire the Windows NT 4.0 certification
track! Never mind the fact that activation is low-impact, well integrated
into the Windows XP installation process and usually accomplished via
a simple button-click—people still hate it. Well, some people don’t mind
it, but few actually like it.
I’m not going to reopen the painful debate of “activation is a good thing”
vs. “what a pain in the neck.” No, I’m more of a pragmatist. Activation
is a part of Windows XP. Like it or not, you have to live with it. What
I’m going to do is show you how you can simplify the XP activation process
This script allows you to activate Windows XP on remote machines.
This script uses WMI to connect
to the local or
remote computers and activate
Dim objWMI, objWindows, objOS
Each objOS in objWindows
Now, If Only I Could Use WMI To Wax My Car...
Yes, there seems to be no end to WMI’s usefulness in scripting.
It has a ton of objects that can be used for virtually any task. In this
case, I’m using WMI’s Win32_WindowsProductActivation object to, well…activate
Windows. The script is simple enough. Here’s how it works:
- Connecting—This script uses a moniker to connect to the target
machine (the machine being activated). When I first started discussing
WMI, I told you that I preferred connecting via a moniker. However,
over the last three months, my scripts have used the WbemScripting.SWbemLocator
object to connect—just to show you an alternative. Remember that it
doesn’t really matter which method you use. Using a moniker saves space,
and I’m all for that.
- Retrieving the Activation Object—The next step is to execute
a query to return a collection of all operating systems in the activation
object—which, in this case, is only one. This is for consistency in
- Executing the Activation Method—Finally, I loop through the
collection and activate every (well, only one) operating system it contains.
The remainder of the script consists of the standard XML script code
required for .WSF scripts. You’ll notice I hardwired the computer name
into the GetObject line. This can be replaced with a variable that can
store data retrieved from a file. Just refer to August’s column, “Getting
Beyond the Subnet,” to see how this can be done using an Excel spreadsheet.
You can also use the file system object to read this data from a text
file. The choice is yours.
If you opt to code this to activate several machines at once, you’ll
want to be sure to include an error handling code. You’ll want to trap
errors right after the GetObject line (in case the computer you’re attempting
to connect to is offline) and right after the ActivateOnline method, just
in case a robust user has decided to activate XP.
One More Thing
With only one change, this script can be used to activate Windows
XP offline. The Win32_WindowsProduct Activation object contains a method
called ActivateOffline. This method requires an argument: a valid Windows
activation number. Other than that, the usage is the same.
Keep It Handy
Like the IP functionality covered over the last few months, this
is a script you’re not likely to use every day. Once you activate Windows,
it stays activated. Still, if you happen to perform a mass upgrade from
Windows 2000 to XP (or add a bunch of new machines), you’ll find it a
real time-saver. Anything that keeps you from having to walk from machine
to machine and wait for the user to finish typing his or her e-mail (or
whatever) just to click a button is OK in my book!
Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to firstname.lastname@example.org.