Mr. Script

Controlling Network Connections

Stepping outside of the box is a good thing.

I once saw a bumper sticker that read: I know everything. I just can’t remember it all at once. I like that phrase. It’s particularly descriptive of our lives as systems administrators. Ask us a question—any question—about how to perform a specific task in NT/Win2K/XP/9x and eight out of 10 times, we’ll have the correct answer right off the tops of our heads. For the remaining two times, we’ll know exactly where to find the answer. In other words, we know it, but we just can’t remember it.

Recently, I had a brief bout of “unremembering” when it came to a scripting question I received from Doug Lippi, a senior systems manager. Doug’s question was:

I’m trying to show a NIC’s state (connected/disconnected) and set its state (enabled/disabled) using the command line for Windows 2000. Is this possible? I’ve been unsuccessful.

My first thought was, of course, you can—by using Windows Management Instrumentation, as it can do everything but make coffee in the morning. I looked through the WMI object browser (just to refresh my memory, you understand) and sure enough, there it was. You can, indeed, use WMI to enumerate each NIC and display its state. But there was no corresponding method to change that state. This had to be wrong. How could it be that WMI—the all-seeing, all-powerful, supreme being of scripting—was unable to do something as fundamental as disabling a NIC? I couldn’t accept that, so I dug deeper. MSDN search…nothing. Deeper still. Google search…nothing!

Finally, I resigned myself to looking outside WMI. It was then that I remembered the Windows Shell object. It can be done! The Shell object can be used to enumerate the NICs, display their state, then enable or disable them—all from the command line.


This script looks at your ‘Local Area Connection’
and enables it if disabled, disables it if enabled.


Script for toggling network connection on/off


C:\>cscript ToggleNIC.wsf
<object id=”
objShell” progid=”Shell.Application”/>
<script language=”VBScript”>
‘Toggle NIC on or off
Option Explicit
Dim objCP, objEnable, objDisable, colNetwork
Dim clsConn, clsLANConn, clsVerb
Dim strNetConn, strConn, strEnable, strDisable
Dim bEnabled, bDisabled

strNetConn = “Network Connections”
strConn = “Local Area Connection”

strEnable = “En&able”
strDisable = “Disa&ble”

Set objCP = objShell.Namespace(3)
‘Control Panel

Set colNetwork = Nothing
For Each clsConn in objCP.Items
If clsConn.Name = strNetConn Then
Set colNetwork = clsConn.getfolder
Exit For
End If

If colNetwork is Nothing Then
WScript.Echo “Network folder not found”
End If

Set clsLANConn = Nothing
For Each clsConn in colNetwork.Items

‘In case the LAN is named “connection 2”, etc.

If Instr(LCase(,LCase(strConn)) Then
Set clsLANConn = clsConn
Exit For
End If

If clsLANConn is Nothing Then
WScript.Echo “Network Connection not found”
End If

bEnabled = True
Set objEnable = Nothing
Set objDisable = Nothing
For Each clsVerb in clsLANConn.verbs
If = strEnable Then
Set objEnable = clsVerb
bEnabled = False
End If
If = strDisable Then
Set objDisable = clsVerb
End If

If bEnabled Then
End If

‘Give the connection time to stop/start
WScript.Sleep 1000


Digging Into the Script
This script uses the Shell object to gain access to the Network Connections folder and, subsequently, the network connection itself. It then toggles the connection on and off by using “verb” methods to invoke actions from the menu. One caveat: Since it uses the Shell object, it relies on standard naming conventions. The Windows XP control panel item is called Network Connections. Win2K calls it Network and Dial-up Connections. The script doesn’t work at all on NT 4.0 or Win 9x, because the Network applet doesn’t use the same folder-based approach to managing connections. Moreover, the individual connection will often be appended with a number such as 2 or 3.

I’ve tried to compensate for this in the script by looking for Local Area Connection inside the connection name, rather than performing an exact match comparison. If you’re the sort of person who renames these things to, say, 3COM PCI NIC and/or LinkSys PCMCIA NIC, then you’ll have to change the script accordingly. You’ll also need to take care with multi-homed machines to ensure that you’re disabling the correct connection.

As a standalone script, it doesn’t do much. Let’s face it: Sometimes the GUI is better. If all we need to do is enable/disable a network connection, we can simply right-click the network connection in our Network Connections folder and click Enable or Disable. Indeed, that’s exactly what the script is doing from within the code. However, if you put this functionality into a larger script—one that might require disabling network access at a particular point in the script execution and then enabling it again at another point—its value increases dramatically.

The Network Is Down
As of this writing, the whole world is in the midst of recovering from the Blaster worm. What made this recovery difficult is that the worm would often cause your computer to reboot (randomly) before you could finish removing it. In order to complete the fix, you had to take your computer off the network, apply the fix, delete MSBlast.exe from your system32 folder, configure your Internet Connection Firewall, reconnect to the network, and download and apply the update to fix the port 135 vulnerability. Wouldn’t it be cool to put all of these steps into a script that you simply run on every workstation? Suddenly, being able to disable a network connection from script code becomes a real timesaver, doesn’t it?

Even though Doug wrote to me before the Blaster worm hit, he was almost precognitive in identifying a task for which administrators everywhere would need a solution. Of course, I suppose you could just go around and unplug everyone’s network cable, or simply power off the hub, but where’s the fun in that?

By engaging in a bit of outside-the-box thinking, you’re sure to find yourself using the code in this script quite often as part of a larger task. Now that you know how to do it, just make sure that you always remember it.

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

comments powered by Disqus
Upcoming Events

Redmond Tech Watch

Sign up for our newsletter.

I agree to this site's Privacy Policy.