Troubleshooting the mystery error -- Managing Windows networks using scripts, part 7

In the previous article, Remote scripting first steps, we took our ChangeIPAddress.vbs script developed earlier and modified it to use it to change the IP address on a remote computer. Here's what our modified script looked like:

Option Explicit
Dim objWMIService
Dim objNetAdapter
Dim strComputer    
Dim strAddress    
Dim arrIPAddress
Dim arrSubnetMask
Dim colNetAdapters
Dim errEnableStatic

If WScript.Arguments.Count = 0 Then
     Wscript.Echo "Usage: ChangeIPAddress.vbs new_IP_address"
     WScript.Quit
End If

strComputer = "xp2"
strAddress = Wscript.Arguments.Item(0)
arrIPAddress = Array(strAddress)
arrSubnetMask = Array("255.255.255.0")
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colNetAdapters = objWMIService.ExecQuery("Select * from Win32_NetworkAdapterConfiguration where IPEnabled=TRUE")
For Each objNetAdapter in colNetAdapters
     errEnableStatic = objNetAdapter.EnableStatic(arrIPAddress, arrSubnetMask)
Next

The line:

strComputer = "xp2"

tells us that the computer targeted by the script has the name XP2. The remote computer XP2 initially had an IP address of 172.16.11.43.

Now when we ran this script by typing ChangeIPAddress.vbs 172.16.11.65 from an admin workstation named XP, the following happened:

How do we deal with these results?

One thing we could do is to say, "Well, since it worked let's just ignore the error." There's something to be said with this

Digg This!     StumbleUpon     Del.icio.us

RELATED CONTENT Network Management Virtualization: The next generation of application delivery challenges Improving the performance of Web traffic and application delivery The link between network management and application delivery How to align network usage information to business processes How network management can use ITIL best practices to battle recession How to monitor and manage your data center network Building the network infrastructure in your data center Power and cooling considerations for data center network design Network performance and throughput in server virtualization environments Return-all-values script: Managing Windows networks using scripts, Part 13 Working With Servers and Desktops Understand Windows tracert output to troubleshoot network connectivity Test your TCP/IP protocol stack to troubleshoot network connectivity Checking IP configuration to troubleshoot Windows network connectivity Physical network security key to fighting low-tech threats Using ping command for troubleshooting Windows network connectivity Bandwidth allocation: How can I give a download limit for each user? How to use Netsh WLAN to configure Windows Server 2008 and Windows Vista wireless connections from the CLI How to upgrade Windows Server 2003 to Server 2008 Top Windows Management Instrumentation (WMI) scripting books, websites HTTP error code troubleshooting, Part 3: Disabling IE friendly error messages Network Performance Management Virtualization: The next generation of application delivery challenges New skills emerge for network engineering and administration careers Improving the performance of Web traffic and application delivery Network performance management evolution: Involving other IT domains Formula for proper bandwidth utilization on a T1 line The link between network management and application delivery IT automation, automated network management becoming essential Network management and monitoring market remains crowded, fragmented Network configuration flaws block server access and wireless printing Xangati help desk 'DVR' feature speeds up trouble ticketing resolution

RELATED GLOSSARY TERMS Terms from Whatis.com − the technology online dictionary four-way server  (SearchNetworking.com) mail user agent  (SearchNetworking.com) netstat  (SearchNetworking.com) Technical Office Protocol  (SearchNetworking.com) Telnet  (SearchNetworking.com) two-way server  (SearchNetworking.com) virtual network adapter  (SearchNetworking.com) virtual network computing  (SearchNetworking.com) virtual systems management  (SearchNetworking.com) VxWorks  (SearchNetworking.com)

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary

approach. After all, any real-world administrator knows that IT is not an exact science and we often end up applying "workarounds" to issues when proper solutions for them can't be devised.

So how can we ignore the error? Just add the following line near the beginning of the header section:

On Error Resume Next

In other words, our header section will now look like this:

Option Explicit
On Error Resume Next
Dim objWMIService
etc.

Now we don't see the error, and our script works. But it still takes a long time to execute, in fact well over a minute. What's going on?

Error messages are sometimes cryptic, and this is one of them. Here's the error message again:

SWbemObjectEx: The remote procedure call failed.

And here's the line of code that generates it:

errEnableStatic = objNetAdapter.EnableStatic(arrIPAddress, arrSubnetMask)

Now this line of code works (i.e. the IP address gets changed on the target computer) but then it throws an error. Why?

Let's start by trying to understand what SWebObjectEx means. A quick search on MSDN finds this page which says the following:

Extends the functionality of SWbemObject. This object adds the Refresh method for SWbemRefresher objects.

OK so SWbemObjectEx basically just adds more functionality to SWbemObject. So what's SWbemObject?

Contains and manipulates a single WMI object class or instance.

OK what does that mean? This page tells us more but it's awfully geeky. In simple words however, SWbemObject (and hence SWbemObjectEx) is anything you manage or query in WMI. In our script we're querying the Win32_NetworkAdapterConfiguration class and returning a collection of objects called colNetAdapters representing the network adapters on the computer. So the SWbemObjectEx (or SWbemObject) referred to in this error message is simply the object representing the network adapter itself i.e. objNetAdapter.

OK so objNetAdapter is generating the error. Why?

Well I had to talk to some friends of mine who are scripting "gurus" to try and figure that one out. And the best response I've gotten to date isn't completely satisfying, but hey when was "satisfaction" part of the job description for an IT administrator anyway?

Anyway, here's what seems to be the problem. According to one of these gurus, it seems that "something" in one of the hotfixes for Windows XP may have changed the way the return call is created and submitted when the statement causing the error is executed. Normally if the call to the EnableStatic method of the instantiated object of the Win32_NetworkAdapterConfiguration class completes successfully, it returns 0 which means no error, while if the call returns 1 then it means a reboot is required (see this page under Return Value for more info). Of course, with Windows XP no reboot is required when you change the IP address on a network adapter. If for some reason a hotfix may have changed something in the WMI provider or some other under-the-hood element so that Windows thinks a reboot is required before the new address can "take" on the target machine, and this generates an error because the network adapter configuration on the machine is left in an indeterminate state until the machine can be rebooted. But since the script is still running on the admin workstation when the target computer's network adapter configuration enters this indeterminate state, the RPC connection between the two machines is severed before the script can finish running. Hence the error.

At least that's the best answer I have to this issue at present, and I'll keep investigating. But meanwhile let's see if we can confirm somehow that this issue is isolated i.e. that the error is associated only with the EnableStatic method of Win32_NetworkAdapterConfiguration and not something more general. What if we try writing another script that does something different with the network adapter on the target machine instead of changing its IP address? For example, how about trying to change the default gateway instead of the IP address on the target machine? If that works then at least we know we can successfully connect from our admin workstation to the remote machine and call a WMI method to change a network setting on it.

At this point I'd like to suggest that you stop reading this article and look back at part 4 of this series, where I show you how to use MSDN to learn how to use the properties and methods of the Win32_NetworkAdapterConfiguration class. I'll bet by doing this you can write such a script yourself. Try it!

INTERMISSION

Okay, now you've tried writing your own script and maybe it worked and maybe it didn't. If it didn't work, follow these steps:

You've learned that the target computer has to have a static address before you can call this method against it. Reading further, you find that the syntax for calling this method looks like this:

SetGateways(A,B)

Here A is a string variable containing the IP address for the gateway, and B is an integer of value 1 to 9999 specifying the metric.

Now you should have enough info to write your script. The easiest way is to start with our original ChangeIPAddress.vbs script found in Part 2 of this series and modify it a bit until we get a new script (which we'll call ChangeGateway.vbs) that looks like this:

'=========================
' NAME: ChangeGateway.vbs
'
'AUTHOR: Mitch Tulloch
'DATE: February 2007
'
'ARGUMENTS:
'1. gateway_address
'2. metric
'=========================-

Option Explicit

Dim objWMIService
Dim objNetAdapter
Dim strComputer
Dim strGateway
Dim arrGateway
Dim intMetric
Dim arrMetric
Dim colNetAdapters
Dim errGateway

'Check for missing arguments

If WScript.Arguments.Count = 0 Then
     Wscript.Echo "Usage: ChangeGateway.vbs gateway_address metric"
     WScript.Quit
End If

strComputer = "xp2"
strGateway = Wscript.Arguments.Item(0)
arrGateway = Array(strGateway)
intMetric = Wscript.Arguments.Item(1)
arrMetric = Array(intMetric)
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colNetAdapters = objWMIService.ExecQuery("Select * from Win32_NetworkAdapterConfiguration where IPEnabled=TRUE")
For Each objNetAdapter in colNetAdapters
     errGateway = objNetAdapter.SetGateways(arrGateway, arrMetric)
Next

'Display result or error code

If errGateway=0 Then
     Wscript.Echo "Adapter's gateway has been successfully changed to " & strGateway
Else
     Wscript.Echo "Changing the adapter's gateway was not successful. Error code " & errGateway
End If

Copy this script into Notepad (with Word Wrap turned off) and save it as ChangeGateway.vbs. Now let's test it. Let's log onto the remote machine XP2, open a command prompt and type ipconfig /all and here's the result:

C:\>ipconfig /all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : XP2
        Primary Dns Suffix  . . . . . . . : contoso.com
        Node Type . . . . . . . . . . . . : Unknown
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Intel 21140-Based PCI Fast Ethernet
Adapter (Generic)
        Physical Address. . . . . . . . . : 00-03-FF-21-88-8C
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 172.16.11.80
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 172.16.11.1

C:\>

Now on the admin workstation XP, let's open a command prompt and run the new script as follows:

C:\tools>ChangeGateway.vbs 172.16.11.2 5
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

Adapter's gateway has been successfully changed to 172.16.11.2

C:\tools>

The script takes about five seconds to finish, and no errors are thrown. (Note that I omitted On Error Resume Next from the header of my script as I want to see any errors if they occur).

Now let's return to the remote machine XP2 and run ipconfig /all again:

C:\>ipconfig /all

Windows IP Configuration

        Host Name . . . . . . . . . . . . : XP2
        Primary Dns Suffix  . . . . . . . : contoso.com
        Node Type . . . . . . . . . . . . : Unknown
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : Intel 21140-Based PCI Fast Ethernet
Adapter (Generic)
        Physical Address. . . . . . . . . : 00-03-FF-21-88-8C
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 172.16.11.80
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 172.16.11.2

C:\>

It worked. No errors, nothing mysterious—we've run a script remotely against another computer and it changed the target machine's default gateway.

Well, we didn't check if the metric was changed, did we? The ipconfig command doesn't show this information, but we can use netsh to get this as follows:

C:\>netsh interface ip show address

Configuration for interface "Local Area Connection"
    DHCP enabled:                         No
    IP Address:                           172.16.11.80
    SubnetMask:                           255.255.255.0
    Default Gateway:                      172.16.11.2
    GatewayMetric:                        5
    InterfaceMetric:                      0

C:\>

Yep, it works.

About the author:
Mitch Tulloch is a writer, trainer and consultant specializing in Windows server operating systems, IIS administration, network troubleshooting, and security. He is the author of 15 books including the Microsoft Encyclopedia of Networking (Microsoft Press), the Microsoft Encyclopedia of Security (Microsoft Press), Windows Server Hacks (O'Reilly), Windows Server 2003 in a Nutshell (O'Reilly), Windows 2000 Administration in a Nutshell (O'Reilly), and IIS 6 Administration (Osborne/McGraw-Hill). Mitch is based in Winnipeg, Canada, and you can find more information about his books at his website: www.mtit.com.

[TABLE]

WindowsNetworking.com contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles and tips by a team of leading authors, it remains a favorite within the networking community.