| Managing Windows Networks Using Scripts - Part 7: Troubleshooting the Mystery Error |
|
|
|
|
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 If WScript.Arguments.Count = 0 Then strComputer = "xp2" 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? The Easy SolutionOne 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 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 MessageError 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 GatewayI previously showed you how to use MSDN to learn how to use the properties and methods of the Win32_NetworkAdapterConfiguration class. give it a quick go and I'll bet by doing this you can write such a script yourself. Try it! INTERMISSION (and coffee break) 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:
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: '========================= Option Explicit Dim objWMIService 'Check for missing arguments If WScript.Arguments.Count = 0 Then strComputer = "xp2" 'Display result or error code If errGateway=0 Then 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 Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : 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 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 Host Name . . . . . . . . . . . . : XP2 Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : 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" C:\> Yep, it works. |
| < Prev | Next > |
|---|
