Tip

Remote scripting first steps -- Managing Windows networks using scripts, Part 6

Learn how to run your script remotely against a remote Windows XP computer in this tip, originally published on WindowsNetworking.com.

    Requires Free Membership to View

This article originally appeared on WindowsNetworking.com.

In previous articles in this series we explored what we could do with the Win32_NetworkAdapterConfiguration class and getting over the "hump" that many Windows administrators face when learning how to script.

Now let's go back to the script ChangeIPAddress.vbs that we developed to change the IP address of a network adapter:

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 = "."
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

Read other 'Managing Windows networks using scripts' tips
Part 1: The basics

Part 2: Cleaning up

Part 3: Understanding WMI

Part 4: Using Win32_NetworkAdapterConfiguration

Part 5: Getting over the hump

Part 6: Remote scripting first steps

Part 7: Troubleshooting the mystery error

Part 8: Troubleshooting remote scripting with Network Monitor 3.0

Part 9: Understand remote scripting

Part 10: Two tricks using WMI scripts

Part 11: More remote scripting tips

Part 12: Properties of WMI class

Part 13: A return-all-values script

Part 14: WMI scripting resources

Note that I've removed the comments, and the code at the end that displays the result.

Now remember what this script does:

  • It connects to the root\cimv2 namespace on the local computer.
  • It uses a SELECT statement to return a collection of network adapter configurations that have TCP/IP bound and enabled.
  • It changes the IP address on the adapter to the value specified as a command line parameter.

So let's say we save this script in the folder C:\localtest on a Windows XP machine that has static IP address of 172.16.11.43. Then we open a command prompt running with administrator credentials on the machine and we use this script to change the machine's IP address to 172.16.11.54:

C:\locatest>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

    Connection-specific DNS Suffix . :
    IP Address. . . . . . . . . . . . : 172.16.11.43
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 172.16.11.1

C:\locatest>ChangeIPAddress.vbs 172.16.11.54
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

C:\locatest>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

    Connection-specific DNS Suffix . :
    IP Address. . . . . . . . . . . . : 172.16.11.54
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 172.16.11.1

C:\locatest>

Gotcha #1: Remember, to change the IP address on a Windows XP machine requires local administrator credentials. So if you are currently logged on to the machine as a domain user (as I was) you need to open a command prompt and type runas /user:administrator cmd.exe to open a second command prompt running in the context of local admin credentials, and then run the script from this second command prompt.

But what if we want to run this script on one machine (say xp2.contoso.com) and use it to change the IP address of a different machine (say xp.contoso.com)? In other words, we want to run the script remotely against a remote Windows XP computer. How can we do this?

First attempt

Let's start by logging on to our administrator workstation xp.contoso.com using the domain admin credentials of Mary Jones our administrator. We'll need to do this since domain admins have local admin privileges on all machines in the domain, so when we run our script from our admin workstation against the remote machine, it should work, right?

So let's say our script ChangeIPAddress.vbs is in the folder C:\tools on our admin workstation xp.contoso.com. Let's open a command prompt on this machine and type the following:

C:\Documents and Settings\mjones>cd \tools
C:\tools>notepad ChangeIPAddress.vbs

Our script opens in Notepad, and we change this line:

strComputer = "."

to read the following:

strComputer = "xp2 "

We then select File | Save to save changes, and close Notepad. Now let's run the script:

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

C:\tools\ChangeIPAddress.vbs(20, 1) Microsoft VBScript runtime error: The remote server machine does not exist or is unavailable: 'GetObject'



C:\tools>

Note that it takes a while before the above error message is finally returned. But did the operation work? Well, if I log onto the remote machine xp2.contoso.com, open a command prompt and type ipconfig, here's what I get:

C:\locatest>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

    Connection-specific DNS Suffix . :
    IP Address. . . . . . . . . . . . : 172.16.11.43
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 172.16.11.1

C:\locatest>

So I can see that the address of this machine is still 172.16.11.43, so the script didn't work. Rats!

What went wrong? Note that the runtime error returned indicates a problem with executing line 20 of the script, and here's what line 20 looks like:

Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

So it looks like the script can't connect to the WMI service on the remote machine. What could be causing this?

Second attempt

Maybe it has something to do with Windows Firewall on the remote machine.

Remember, Windows XP SP2 has a firewall that blocks most incoming traffic except for traffic that has an exception configured for it. The simplest way to test this is to disable Windows Firewall on the target computer. Let's do this by logging on to xp2.contoso.com as administrator, opening the Windows Firewall applet from Control Panel, and selecting the Off setting on the General tab.

Now let's run the script again from the admin workstation:

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

C:\tools\ChangeIPAddress.vbs(23, 6) SWbemObjectEx: The remote procedure call failed.



C:\tools>

Hmm, another error, and again it takes a long time until this error appears. But at least it's a different error this time, and it identifies line 23 as the culprit, which is this:

errEnableStatic = objNetAdapter.EnableStatic(arrIPAddress, arrSubnetMask)
However, now when I type ipconfig at a command prompt on the remote machine, I get the following:
C:\locatest>ipconfig
Windows IP Configuration

Ethernet adapter Local Area Connection:

    Connection-specific DNS Suffix . :
    IP Address. . . . . . . . . . . . : 172.16.11.65
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 172.16.11.1

C:\locatest>

So it looks like the script worked! We're getting there! But this leaves us with two puzzles:

  • We don't want to have to disable Windows Firewall on remote machines in order to run scripts against them. So is there an exception we can open on these machines to enable remote scripts to run against them while Windows Firewall is running?
  • What about the RPC error above? The script worked but it still returned an error. Why?

Exception for remote scripting

Let's enable Windows Firewall on the remote machine again. This will block our script from running against it. Now from an admin-level command prompt on the remote machine, type gpedit.msc to open Local Group Policy on the machine, then navigate to the following policy setting (see Figure 1):

Computer Configuration\Administrative Templates\Network\Network Connections\Domain Profile\Windows Firewall: Allow remote administration exception


Figure 1: Windows Firewall policy setting for enabling remote administration

Double-click on this policy setting and enable it for the local subnet (Figure 2). We'll do this since we know that our admin workstation is on the same subnet as the target computer.


Figure 2: Enabling the remote administration exception

Gotcha #2: Of course, you may want to do this differently and configure this policy setting in a domain Group Policy Object (GPO) instead of locally. That way you don't have to touch the remote machine to enable this exception in its firewall!

Now let's run the script again from the admin workstation and try to change the remote machine's IP address from 172.16.11.65 to 172.16.11.66:

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

C:\tools\ChangeIPAddress.vbs(23, 6) SWbemObjectEx: The remote procedure call failed.



C:\tools>

Same error as before, but when I type ipconfig at a command prompt on the remote machine, here's what I get:

C:\locatest>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

    Connection-specific DNS Suffix . :
    IP Address. . . . . . . . . . . . : 172.16.11.66
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 172.16.11.1

C:\locatest>

It worked! So by leaving Windows Firewall enabled on the remote machine but using Group Policy to open an except for remote administration in the firewall, we can remotely change the machine's IP address by running a script from an admin workstation.

So we've solved the first puzzle, but what about the second?

Well, I like mysteries, so let's leave that one until the next article in this series.

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.

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.


This was first published in December 2007

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.