Export (0) Print
Expand All

Part 1: Introduction

Published: July 19, 2004

Looking down from the CIO's office, networks based on Transmission Control Protocol/Internet Protocol (TCP/IP) are the nervous systems of many organizations. Their healthy functioning is critical to corporate communications, customer satisfaction, employee morale, and the bottom line. Because of the scale and complexity of such networks and the accessibility of the TCP/IP protocol stack to scripting, the tasks involved in configuring and maintaining TCP/IP networking components are often good candidates for automation.

Looking up from the administrative trenches, the work of managing a TCP/IP network sometimes seems to consist of hours of drudgery interrupted by moments of frantic damage control. This paper primarily discusses ways to make those uneventful hours pass in a more reliable, structured, and productive way, which should help reduce the incidence of crises in the bargain.

By scripting administrative operations, you can relieve the boredom of repetitious tasks and free more time to deal with less routine issues. Replacing manual procedures, which run the risk of operator error or forgetfulness, with automated maintenance can also alleviate the risk of attacks by malicious viruses and worms and of hardware failures. Scheduling your scripts to run during off-peak hours and without administrator intervention can relieve network traffic jams and reduce user inconvenience. Overall, a well-designed ensemble of scripts, in concert with appropriate Microsoft® Windows® graphical user interface (GUI) and command-line tools, can standardize and systematize network operations, increasing productivity, reliability, and morale.

As with most useful things, the kind of scripting discussed in this paper has associated costs. The language, Microsoft® Visual Basic® Scripting Edition (VBScript); the scripting environment, Microsoft® Windows® Script Host (WSH); and the automation library, Windows Management Instrumentation (WMI), typically involve more study to master than the GUI or command-line tools. Nevertheless, although scripting is a form of programming, it is one that does not require four years of computer science study to become proficient and productive. Thousands of system administrators and engineers around the world have learned scripting, used it to great advantage, extended it, and now constitute a community that offers Web sites, newsgroups, and other invaluable resources for those who want to profit from their experience.

On This Page

Scope and Organization of This Paper
Running the Sample Scripts
System Requirements
Other Important Resources


Scope and Organization of This Paper

The Windows operating system family provides a variety of tools for managing TCP/IP networks. This paper focuses on the tools that enable you to automate tasks on TCP/IP clients. It covers scripting tools and techniques that enable you to work with the client side of most important elements of TCP/IP networking, including Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Windows Internet Name Service (WINS). Each section provides detailed explanations and script examples, with relevant command-line tools and registry keys listed in tables at the end.

Beginning with basic scripting techniques, this paper shows increasingly complex variations that open up new functionality. In some areas, it discusses common practical scenarios that require combining different scripting approaches. Its aim, however, is not to show cool scripting tricks for their own sake, but rather to provide flexible ways to automate real-world networking tasks that commonly confront system administrators.

This paper covers the following topics:

  • Scripting basic TCP/IP networking on clients, including comparisons of GUI and command-line tools to analogous scripting techniques.

  • Extending these scripting techniques to remote and multiple computers.

  • Scripting IP address allocation with DHCP and static IP addresses.

  • Scripting DNS client management.

  • Scripting WINS client management.

  • Scripting TCP/IP filtering, Internetwork Packet Exchange (IPX), and other network protocols.

  • Advanced scripting techniques that include managing system time and scripting network settings in the registry.

  • A final scenario that combines many previously illustrated techniques in a complex script that adds new clients to a network.

  • A list of important resources that can help you in scripting network clients.

Use of VBScript, WSH, and WMI in Scripting Examples

Because VBScript is the most popular language for automating Windows administration, all script examples in this paper are written in this language. If you prefer to work in Microsoft JScript®, Perl, or another scripting language, the translation in most cases is simple, because similar techniques apply. These scripts all run under Windows Script Host, the Windows administrative scripting environment; so you can use any language for which a WSH scripting engine is available.

VBScript and WSH, however, provide only the language and environment for scripting. Most of the functionality for retrieving configuration information and making changes is included in WMI, which provides hundreds of classes that allow you to work with hardware and software.

This paper focuses on just a few WMI classes — ones that include nearly all the TCP/IP client functionality in WMI. The most important class is Win32_NetworkAdapterConfiguration, which contains most of the settings that this paper discusses. Instances of Win32_NetworkAdapterConfiguration have a one-to-one relationship to instances of Win32_NetworkAdapter; in other words, each object representing the configuration settings for a network adapter has a corresponding object representing the hardware of that network adapter. Win32_NetworkAdapterSetting, an association class, represents the relationship between the previous two classes.

Win32_NetworkAdapterConfiguration includes 61 read-only properties and 41 methods for changing the properties; Win32_NetworkAdapter and Win32_NetworkAdapterSetting, on the other hand, contain only read-only properties.

Table 1 highlights these important classes as well as a few additional classes that contain varying numbers of read-only properties. Among them, only Win32_ComputerSystem and Win32_OperatingSystem contain methods and a few read/write properties.

Table 1   WMI Classes That Provide TCP/IP Client Functionality

WMI Class

Properties

Notes

Win32_NetworkAdapterConfiguration

61 read-only properties;
41 methods for changing properties

The most important class for scripting TCP/IP tasks. Contains most of the settings discussed in this paper.

Win32_NetworkAdapter

Read-only properties

Has a one-to one relationship with instances of Win32_NetworkAdapterConfiguration

Win32_NetworkAdapterSetting

Read-only properties

An association class that represents the relationship between the Win32_NetworkAdapterConfiguration and Win32_NetworkAdapter classes.

Win32_NetworkProtocol

Read-only properties

 

Win32_ComputerSystem

Some read-only and a few read/write properties;
some methods

 

Win32_OperatingSystem

Some read-only and a few read/write properties;
some methods

 

Win32_PingStatus

Read-only properties

 

Win32_LocalTime

Read-only properties

 

Win32_UTCTime

Read-only properties

 

Win32_TimeZone

Read-only properties

 


Although the names of the WMI classes Win32_NetworkClient, Win32_NetworkConnection, and Win32_NetworkLoginProfile suggest a relationship to topics in this paper, these classes are not directly relevant to our subject matter. Win32_NetworkConnection, for example, retrieves settings relating to shared network resources currently connected to the computer — not the kind of network connections managed by Network and Dial-up Connections.

This paper provides many but not all details about selected WMI classes. For more detailed information about WMI classes, including a more complete list of classes, see the WMI SDK on the Microsoft Developers Network (MSDN) at http://go.microsoft.com/fwlink/?LinkId=24766.

Technical Level of This Paper

This paper is intended for system and network administrators, engineers, and architects who use or want to use scripting in their work. It assumes some familiarity with scripting and a basic level of networking knowledge. Although it does not try to teach basic scripting or networking, it does explain scripting techniques in detail as they are used.

What This Paper Does Not Cover

This paper does not cover basic scripting or basic TCP/IP networking. To learn basic system administration scripting techniques, see the Microsoft® Windows® 2000 Scripting Guide and the many example scripts on the TechNet Script Center at http://go.microsoft.com/fwlink/?LinkId=24771. For information about TCP/IP networking on Windows, see Microsoft® Windows Server™ Help, which is included with your Windows Server operating system, and the Microsoft® Windows 2000 Server Resource Kit.

The scope of this paper is restricted to scripting TCP/IP clients. Scripting DHCP, DNS, and WINS servers, routers, and network monitoring are not covered.

The related subjects of scripting domain administration and directory services are also not covered in this paper. However, you can find some content relevant to these topics in the Windows 2000 Scripting Guide and also in the example scripts on the TechNet Script Center at http://go.microsoft.com/fwlink/?LinkId=24771.

note.gif  Note
This paper covers only scripting for IPv4 networks; it does not provide script examples for IPv6 networks.

Command-Line Tools and Batch Files

Because this paper focuses on scripting WMI with VBScript and WSH, it does not describe how to use the command-line tools included with the Windows operating system or the Windows 2000 Resource Kit; nor does it cover how to write batch files. Those topics are covered in the documentation for those products and in many other books.

At the end of each section, however, a tools section lists the relevant command-line tools.

Organization of Scripts

The sample scripts in this paper follow some general patterns:

Constants and variables

In most cases, constants and some variables (usually ones that you want to change) are initialized at the beginning of the script. However, not all variables are initialized before they are used. Almost no variables are declared because VBScript does not require it, which helps keep the scripts shorter.

As a debugging aid when writing your own scripts, you may want to explicitly declare all variables with the Dim statement and verify this with the Option Explicit statement.

Connecting to the WMI service

Nearly all scripts begin by connecting the WMI service and then getting a reference to instances of one or more WMI classes.

Linear execution path

Most scripts follow a relatively linear execution path to make them simpler and easier to follow. Only a few of the longer and more complex scripts are broken down into subroutines and functions.

In some situations, a modular approach may be more adaptable and flexible. If you think you will use a section of code more than once or if you might call it from different places in the script, consider transforming that section of code into a subroutine or function that you can reuse in other scripts.

For IT groups where more than one person writes or uses scripts, standardizing scripting formats and conventions can help to reduce confusion and improve code consistency.

VBScript error handling

Scripts that make changes or that connect to remote computers use the VBScript On Error Resume Next statement along with simple forms of error handling. On Error Resume Next masks errors in the script by allowing the script to continue execution after the line on which the error occurred.

When debugging, it can be helpful to temporarily comment out the On Error Resume Next statement by putting a single quotation mark (') at the beginning of the line. Commenting out this statement causes any errors to result in termination of the script with an error message, which can help you locate problems.

Most such scripts check to see if the computer is available on the network. If it is, they also check to see if they can connect to the WMI service on that computer because clients with older versions of the operating system might not have WMI installed. You may want to add more robust error handling in other areas where you expect to encounter frequent run-time errors.

Sample scripts are code examples, not tools

The sample scripts in this paper are offered as code examples that focus on one or a few tasks. You can dissect, analyze, and recombine these samples to create scripts that meet your own needs. These scripts are not designed as complete, robust tools capable of accomplishing many different tasks and handling many contingencies.

An implicit assumption behind the scripts is that they will be run by administrators with some knowledge of scripting, who are capable of editing scripts to change parameters, where necessary. With few exceptions, the scripts do not accept command-line arguments, as many of the more complex scripts included with Windows do, and they do not try to handle all contingencies or possible errors.

caution.gif  Caution
Sample scripts are not designed to be run as is or by non-scripting support personnel or end users.

Running the Sample Scripts

To run any of the sample scripts contained in this paper, follow these steps:

  1. Log on with required administrative credentials.

  2. Copy the script code to a text file

  3. Save it with a .vbs extension.

    important.gif  Important
    Do not copy the line numbers that appear in the left margin (along the left side of most sample scripts).

  4. Open a command prompt and navigate to the folder where the script is located.

In this paper, the script is always assumed to be in C:\Scripts; however, you can place the script in any folder.

When you set up your scripting environment, it is recommended that you set the WSH default script host to Cscript.exe, the command-line version, because all these scripts are designed to run at the command prompt. How to do this is explained below.

important.gif  Important
If you use Wscript.exe, which is the GUI scripting host, each piece of script output will open a popup that you must then close. This can be time-consuming when a script produces a lot of output and prevents scripts from running unattended.

If you are running a script that makes changes, be sure to save your current settings before making changes. How to do this is explained below.

Running Scripts with Administrative Credentials

Windows, WSH, and WMI security require that you use local Administrator credentials to run scripts on local or remote computers not joined to a domain. On computers joined to a domain, you can also use domain administrator credentials. You cannot do anything with a script that is run under your credentials that you could not do with a command-line tool or in the Windows interface.

For more information about security requirements for scripting, see “Tales from the Script – September 2003: Transform Your Workstation into a Scripting Dynamo” on Microsoft TechNet at http://go.microsoft.com/fwlink/?LinkId=24767.

Setting the Default Script Host to Cscript

To set the default script host to Cscript, suppress the logo (a couple of lines of unnecessary output), and save these settings as the default, run the following at a command prompt:

cscript //h:cscript //nologo //s

Most of the sample scripts in this paper run against the local computer, which is represented to WMI by the dot or period character (.). In some scripts, values such as computer names or IP addresses are hard-coded into variables near the top of the script. To run these scripts on your computer or network, you must first change these values to match your network and host configurations. These required changes are explained along with each script.

Saving Current Settings Before Running Scripts That Make Changes

Some sample scripts make changes on the computer against which they are run. These scripts are flagged with a caution like the one that follows.

caution.gif  Caution
This script may make changes in your computer configuration. Run it only on a test computer and note the settings involved before running it.

Before running a script that makes changes, it is a good idea to save all current IP settings in a text file. You can do this by running the following command line:

ipconfig.exe /all > ipconfig.txt

This command line redirects the output of ipconfig into a text file in the same folder from which you have run the command.

In addition to the ipconfig command, some sections of this paper begin with a script that displays the settings for that networking area. You can use Ipsettings.vbs, Dhcpsettings.vbs, Dnssettings.vbs, and Winssettings.vbs to capture configurations for these areas before running a script that may change them.

System Requirements

This paper assumes you are running the scripts on Windows 2000, Windows XP, or Windows Server 2003. Most of the WMI functionality discussed here is available on Windows 2000. However, Windows XP and Windows Server 2003 do include a number of useful new classes, properties, and methods, some of which are illustrated here. System requirements more stringent than the previous will be noted in each section.

Whenever possible, run the most recent versions of WSH and VBScript, version 5.6 build 8515, both of which are included in the Windows Script download at http://go.microsoft.com/fwlink/?LinkId=27639. This download is available for Microsoft® Windows XP, Windows® 2000, Windows® Millennium Edition (Me), Windows NT® Server 4.0, and Windows® 98.

The versions of WMI and Active Directory Service Interfaces (ADSI) depend on the operating system that a computer is running. Microsoft® Windows® Millennium Edition and later versions of the operating system all include WMI. For Windows NT Server 4.0 and Windows 98, you can download WMI version 1.5 from MSDN. For Windows NT Server 4.0 and Windows 98, you can download Active Directory Client Extensions, which allow these operating systems to function as Active Directory clients, from MSDN.

For more information about setting up a good system administration scripting environment and for a script that tells you what versions of scripting technologies you are running and whether they are up-to-date, see “Tales from the Script – September 2003: Transform Your Workstation into a Scripting Dynamo” on Microsoft TechNet at http://go.microsoft.com/fwlink/?LinkId=24767.

Other Important Resources

For more extensive background material about scripting with VBScript, WSH, and WMI, see the following essential sources:

You can find a more complete list of resources at the end of this paper.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft