Managing Windows Networks Using Scripts - Part 7: Troubleshooting the Mystery Error

If you would like to read the other parts in this article series please go to:

In the previous article 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.

Pre-order your copy of the Microsoft Windows Vista Resource Kit today!

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

The script worked i.e. the address of XP2 changed from 172.16.11.43 to 172.16.11.65.
The script took a long time to execute.
The script returned the following error: C:\tools\ChangeIPAddress.vbs(23, 6) SWbemObjectEx: The remote procedure call failed.

How do we deal with these results?

The Easy Solution

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 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?

Troubleshooting the Error Message

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.

Changing the Default Gateway

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

OK 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:

First go to the MSDN page for the Win32_NetworkAdapterConfiguration class.
Look on the page for a method that has to do with changing the gateway on a network adapter. A quick examination of this page will turn up this:
SetGateways – Specifies a list of gateways for routing packets destined for a different subnet than the one this adapter is connected to.
That must be what we want, so click on SetGateways to open the SetGateways Method of the Win32_NetworkAdapterConfiguration Class page.
On the SetGateways Method page, you’ll find this explanation:
The SetGateways WMI class method specifies a list of gateways for routing packets to a subnet that is different from the subnet that the network adapter is connected to. This method only works when the Network Interface Card (NIC) is in the static IP mode.

OK so 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:

Adapter’s gateway has been successfully changed to 172.16.11.2

C:\tools>

The script takes about 5 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

Ethernet adapter Local Area Connection:

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.

If you would like to read the other parts in this article series please go to:

Managing Windows Networks Using Scripts – Part 7: Troubleshooting the Mystery Error

The Easy Solution

Troubleshooting the Error Message

Changing the Default Gateway

About The Author

Mitch Tulloch

Leave a Comment Cancel Reply

The Easy Solution

Troubleshooting the Error Message

Changing the Default Gateway

About The Author

Mitch Tulloch

Read Next

Leave a Comment Cancel Reply