Did you know you can relate to remote scripting using WMI scripts written in VBScript? This can help you manage your Windows networks remotely. These two tricks on how to manage Windows networks using scripts are detailed in this tip originally published on WindowsNetworking.com.
In the last few articles we've learned about some of the concepts and issues surrounding remote scripting on Windows platforms. In this article we'll describe two tricks relating to remote scripting using WMI scripts written in VBScript.
First, how about a tip from the Windows Vista Resource Kit? This Resource Kit is the book for IT pros who plan on deploying Windows Vista in mid- and large-sized enterprise networking environments, and I was privileged to be lead author on this project and have permission from Microsoft Press to share a few excerpts with you from this terrific book.
Tip 1: Making Cscript.exe the default script host on remote machines
Here's the first tip: It's simple but smart, but we need some background info first, so here goes. I'm sure you know by now that there are a few ways you can launch scripts on Windows machines. For example, if you have the script ChangeIPAddress.vbs on a machine, you could launch it by performing the following:
Now what happens when you do these things depends on what your default settings are for the Windows Script Host (WSH) on your machine. WSH is a language-independent scripting host for scripting engines i.e. WSH uses the VBScript scripting engine to run VBScript scripts you try to run, so WSH acts as the "environment" within which your script runs. But WSH actually has two default script hosts:
Let's see the difference between them in case you're not aware or have forgotten. I'll use the ChangeIPAddress.vbs script from Part 2 of this managing Windows networks series to illustrate. Let's open a command prompt on a Windows Vista machine and use this script to change the machine's IP address to 172.16.1
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
1.173. Now the first thing to note is that changing network configuration settings requires local admin credentials on the machine, so to do this I need to right-click on the command prompt shortcut under Accessories and select Run As Administrator. When I do this a User Account Control (UAC) prompt appears, so I have to either click Continue (if my user account is a member of the local Administrators group on the machine) or enter the credentials of a local admin account (if my user account is only a member of the local Users group on the machine).
Anyway, one way or another I get an admin-level command prompt window open, and I type the command to change the machine's address (Figure 1):
[IMAGE]
Figure 1: Trying to change IP address using script
Now what happens when I press ENTER is that a few seconds later the following dialog box appears (Figure 2):
[IMAGE]
Figure 2: Output of script appears as a dialog box
Where did this message come from? Well, remember that our script Change IPAddress.vbs included the following lines at the end of the script:
'Display result or error code
If errEnableStatic=0 Then
Wscript.Echo "Adapter's IP address has been successfully changed to " & strAddress
Else
Wscript.Echo "Changing the adapter's address was not successful. Error code " & errEnableStatic
End If
So what's happening is that the Wscript.Echo statement is displaying windowed output (i.e. popping up a dialog box) instead of displaying the output within the command prompt window itself. The reason for that is that by default, Wscript.exe is the default script host and that's what this host does i.e. it displays all output using pop-up windows like this.
How can we stop this behavior and get the script output to display within the command prompt window instead? Well, one way would be to explicitly invoke the command-line script host Cscript.exe when you run the script. You can do this as follows (Figure 3):
[IMAGE]
Figure 3: Using cscript.exe to make script output appear within the command prompt window
But it's a pain to always have to type Cscript before you type the script name like this, so instead we can set Cscript.exe as the default script host for all WSH invocations by doing this (Figure 4):
[IMAGE]
Figure 4: Making cscript.exe the default script host
Now we can run the script and display its output from within the command prompt window without having to explicitly type Cscript first (Figure 5):
[IMAGE]
Figure 5: Since Cscript.exe is the default script host, the script's output is displayed within the command prompt window
Now you probably knew all this already, but here's the issue. Say we have a bunch of scripts like ChangeIPAddress.vbs that we want to run remotely by deploying them to target machines as login scripts or startup scripts using Group Policy. And say some of these scripts have Wscript.Echo statements in them to generate script output. What will happen when one of these scripts is deployed to a remote machine and runs on the machine? A series of pop-up windows will appear on the user's desktop as the script runs on the user's machine, and the user will have to click OK, OK, OK, etc. until all the pop-ups are gone and the script has finished its work. What a drag! Is there any way around this?
Well, you could get around it two ways. First, you could edit all your scripts to remove or comment out all the Wscript.Echo statements so that the script doesn't generate any output. That's a bit of a drag though, especially if you have a ton of scripts to mess around with.
So what's the second method? Aha, here's the tip I wanted to share with you, excerpted with permission from the Windows Vista Resource Kit:
Pretty cool what you can do with only a two-line batch file, isn't it? Now you can deploy any scripts you want to your targeted computers and not have to worry about users getting tons of pop-ups appearing on their screens.
Tip 2: Performing "runAs" without having to specify credentials
The second tip was submitted to me by one of our readers after he read one of my previous articles in this series. I thought it was pretty cool so I asked him if I could share it with other readers of WindowsNetworking.com and he said I could do this, so I'll just quote from his emails directly and you can hear him explain his trick:
Well, the above is not 100% true. I actually use:
Set objSWbemLocator = CreateObject("WbemScripting.SWbemLocator")
objSWbemLocator.Security_.Privileges.AddAsString("SeSecurityPrivilege")
Set objWMIService = objSWbemLocator.ConnectServer(strComputer, "root\cimv2", strComputer & "\administrator", strPWD, "", "", &H80)
Set objReg = objSWbemLocator.ConnectServer(strComputer, "root\default", strComputer & "\administrator", strPWD, "", "", &H80)
Set oReg = objReg.Get("StdRegProv")
…which accomplishes the same thing.
Connecting with the local administrator account has another interesting side effect; it does not leave a copy of your domain admin account profile on the PC under Documents and Settings. When using my domain account, I had a few users ask "Why were you connected to my PC?" and wondering what snooping was taking place. By using the local admin account, they don't realize anyone had connected (they are blocked from seeing the security log).
For the record, in practice we have a couple of different local administrator passwords in use here; so the script imports a list and tries them one by one until it is successful or runs out of options.
Pretty cool, eh? Do you have any scripting tips or tricks you'd like to share? Email me at info@mtit.com and I'll share some more submissions in a future article in my column here.
[IMAGE]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.
