Getting Beyond the Subnet
Moving beyond static IP addresses makes our intrepid script router-friendly and takes you to the great outdoors.
- By Chris Brooke
In my younger years, I was something of a “gamer.” Arcades were everywhere
when I was in high school, and I was usually there—dumping my paycheck
one quarter at a time into the latest shoot-’em-up, blow-’em-up, err…mess-’em-up
games. In the last 20 years (Geez! Has it been 20 years already?), I haven’t
had much time for gaming. But now that I have two boys (never mind that
Sammy doesn’t know a video game from Teletubbies, and Shawn already has
PS2), I decided to pop for an Xbox for Christmas—just to see if the old
hand-eye coordination was still there.
What does this have to do with using WMI to script IP configuration,
you ask? Well, one of the cool features of the Xbox is its promised ability
to connect via network to another Xbox for multi-player mayhem. The problem
is that the Xbox expects the other systems to be in the same subnet. In
other words, the Xbox network traffic is stopped cold at the router, unless
there’s appropriate bridging software installed on said router to forward
If you ran the
script we wrote last month, your computer is currently in the same
predicament: You can network locally to your heart’s content, but are
stopped dead at the router. Let’s see if we can’t remedy this by allowing
you to configure DNS, WINS, and gateway information in the same script.
Dim objService, objEnumerator, objInstance, intStatus,
strIPAddr, strSNMask, strXLFile, strComputer
Dim strGateway, strDNSServer, strPWINS, strSWINS,
Do While objXL.ActiveCell.Value<>""
Set objEnumerator=objService.ExecQuery("Select *
Where DatabasePath IS NOT NULL")
For Each objInstance in objEnumerator
The Abridged Version
Last month’s script was a bit long. Rather than take up a lot of
space reprinting mostly the same code, I’ve tried to conserve space by
just including the code inside the <script> tag. The rest of the
script remains the same—but be sure to merge the two parts before running
it! Remember, the XML code contains our object definitions and argument
settings. As you can see, the changes are relatively minor.
First, we had to find a way to specify the IP addresses of the DNS, WINS
and gateway servers. Previously, we entered the IP addresses into a spreadsheet,
with an entry for each computer. We used a static subnet mask, assuming
we were performing this operation only on computers in the same subnet.
(Actually, they can be in different subnets, so long as the subnet masks
are the same.) Because we’re adding even more information (and we want
our script to be flexible), we’ve added columns for the subnet mask and
default gateway to our spreadsheet.
We’ve also added entries into this spreadsheet for the DNS and WINS server
addresses. Granted, it’s likely you have only one or two DNS and WINS
servers providing hostname and NetBIOS name resolution for your entire
organization, so this results in a lot of extra cutting and pasting of
what is likely to be the same set of IP addresses. However, it’s better
to have the flexibility and not need it, than to need it and not have
For the record, the order of the spreadsheet columns is now: Computer
name, IPAddress, Subnet mask, Default Gateway, Primary WINS server, Secondary
WINS server, Primary DNS server, Secondary DNS server. Remember that everything
except the computer name needs to be in dotted decimal notation. If you
make a mistake and type a computer name instead of the IP address for
one of these servers, you’ll be sorely disappointed.
Some Minor Tweaking
You’ll recall that, in last month’s script, the IP address and
subnet mask values were converted to arrays prior to running objInstance.EnableStatic.
We have to do the same thing for the DNS server list and for the gateways.
Because you can also have multiple DNS servers and/or gateways, WMI needs
a way to get them all entered. Ironically, we don’t have to do this for
the WINS server addresses. They’re set as the separate properties of PrimaryServer
Please note: You may receive an error upon executing the IP address change
because the connection to the remote computer was based on the “ old”
IP adress, not the new one that you just changed it to. This is why we
change the IP address last. The change will take effect whether or not
an error is triggered, but you’ll probably want to put in some error-handling
code to catch this and clear the error. Your remember how to do that,
One other thing: I’m using an undeclared variable—intStatus—to execute
each WMI method. Ordinarily, you wouldn’t use the same variable to return
status codes for several operations. Feel free to declare four separate
variables for performing these methods. This will also allow you to verify
that each operation succeeds.
Go Forth And Conquer!
Congratulations! You can now network beyond your subnet. There’s
this newfangled thing out there called the “Internet”. It has these things
called “Web sites”. Now that your computer’s capable of accessing remote
networks, why not go and have a look around? There’s some pretty interesting
stuff out there.
Me? I’ll be busy trying to get to the next level of whatever Xbox game
it is that I’m obsessed with this week. No, wait—what I meant to say is:
“I’ll be busy working hard on my column for next month.” Yeah, that’s
About the Author
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 [email protected].