Speaking the Same Language
This month, Chris takes you through a handy script that discovers and enumerates what networking protocols are installed on a host.
Let’s go back to the days when you couldn’t imagine needing more than 30GB of hard drive space. Back to the “Golden Age” of Information Technology when Networking Essentials was the most feared exam and Internetworking with TCP/IP was an elective. Visualize that moment in time. Do you remember NetBEUI? That must have been, what, 50 or 60 years ago?
Actually, the year was 2001. That was when Microsoft released Windows
XP without NetBEUI (NetBIOS Extended User Interface), making it clear
that a perfectly good networking protocol no longer had a place in the
Windows operating system. Oh, you can install it manually, but not from
the Networking applet. You have to go to the XP installation CD and copy
over the .sys and .inf files from the \Valueadd folder. (Value add? This
thing used to be the default protocol!) It’s also officially “not supported.”
My intention isn’t to rant about how Big Bill and the Redmond Rockets
always seem to assume that the whole world upgrades (or should upgrade)
the moment they release a new product. Instead, I’ll follow the advice
of my daughter when she says, “Don’t be hatin’, daddy.” What I will do
is realize that there are many organizations out there that likely still
use antique systems like NT 4.0 and outdated protocols like NetBEUI, regardless
of whether Microsoft “supports” them or not.
strComputer = "."
Set objWMIService = GetObject("winmgmts:\\"
& strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select
* from Win32_NetworkProtocol",,48)
For Each objItem in
Wscript.Echo "Caption: " &
Wscript.Echo "Connectionless Service: "
& objItem. ConnectionlessService
Wscript.Echo "Name: " &
objItem.Name & vbCRLF
In the current IT climate, reorganization is a fact of life. Chances
are good that in the last 12 months, your computer inventory has changed.
For instance, you might have inherited a sales division that used to be
in its own building but moved to yours in an effort to cut overhead. Each
salesperson in this division has her own laptop computer, and it now falls
upon you to make sure that those boxes are up to snuff. You’ve got to
ensure that their virus-scanning software is current, that they have the
latest and greatest version of your in-house software, and that they can
communicate with all the appropriate servers (some of which may actually
have the nerve to not have TCP/IP installed!).
This month’s script handles that last task by enumerating all networking
protocols installed on a machine. Because it uses WMI, it can perform
this task remotely, giving you a complete picture of the internetworking
capabilities of every computer in your organization. Well…every Windows
computer, at least. The script is based largely on the code created using
the WMI Scriptomatic tool to list the Win32_ NetworkProtocol namespace.
(We looked at Scriptomatic in the January issue.) It creates a listing
of each installed protocol. How it presents that list varies depending
upon the protocol itself. I’ve programmed the script to only display the
information we need to determine what protocols are installed—the complete
listing generated by the original Scriptomatic script contained a great
deal of information that’s overkill for our current task.
Figure 1 shows some sample output from this script. I’ve highlighted
the NetBEUI section to show how it differs from the NetBIOS over TCP/IP
entries (shown immediately after the highlighted area). NetBEUI, while
non-routable, is a fast and efficient networking protocol excellent for
enabling computers on a LAN to communicate with each other. It’s probably
installed on most of those sales laptops you just acquired. Use it. It
still has value, no matter what Microsoft thinks.
|An example of the script, comparing
NetBEUI and NetBIOS. (Click image to view larger version.)
Grading Your Homework
Last month I asked you to improve on our “MyCompChange Name.wsf” script
to validate the OS. Here’s how I solved the problem:
Step 1: Removed the “OS” named argument from the XML section.
Step 2: Deleted this line: strOSArg=WScript.Arguments. Named.Item(“OS”)
Step 3: Added the following code in its place:
strComputer = "."
Set ob-+jWMI = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colItems = objWMI.ExecQuery("Select * from Win32_ OperatingSystem",,48)
For Each objItem in colItems
If Left(objItem.Name, 22)="Microsoft Windows 2000" Then strOSArg="2K"
If Left(objItem.Name, 20)="Microsoft Windows XP" Then strOSArg="XP"
Is left(objItem.Name, 20)="Microsoft Windows NT" Then strOSArg="NT"
By using WMI to query the Win32_OperatingSystem object, the possibility of human error is reduced when running the script. The above section automatically assigns the correct value to strOSArg. The only command-line argument that needs to be specified is whether to change “My Computer” to the Username, the Computername or both. Make sure you have WMI installed if you run this on an NT box.
Next month, we’ll be creating a new script in response to a “Scripting Question” e-mail. Stay tuned! This one’s gonna be good!
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@example.com.