Mr. Script
Remote Possibilities
Be the King of the Castle by executing tasks from the comfort of your own throne.
- By Chris Brooke
- 05/01/2002
As a married man, I understand that there are certain things in this
life over which I have no control. My wife likes to decorate our home
with frilly lace and greenery. She puts sculpted soaps and decorative
towels in the downstairs bathroom that we aren’t allowed to use. The last
bastion of masculinity remaining is my home-theater system. With remote
in hand (it belongs to me, and woe to the creature who attempts to steal
my Scepter of Power), I am King of the Castle, benevolently allowing my
subjects to view the images inside the 70-inch Magic Box. The Scepter
of Power gives me full control to rule my kingdom from the comfort of
my La-Z-Boy custom-made throne!
Remote control is a good thing.
Power to the People
This month I’m going to discuss how you can achieve this type of power
in your kingdom, er… organization. The featured script is a modified version
of the one I used last month and demonstrates how you can accomplish administrative
tasks remotely. As you recall, ChangeFGPerf.wsf updates the Win32PriorityControl
value in the Registry, allowing you to change the way your computer handles
foreground vs. background processes. I even discussed ways to modify the
script for more granular control.
One obvious drawback to the script, as written, is that it must be run
on the local machine. Yes, running the script is still faster than making
the change through the system applet, but isn’t there a way you can make
these changes to any computer in your organization from the comfort of
your own throne, er… workstation? Thankfully, yes. As Charlie Daniels
once said, “Sit down in that chair right there and let me show you how
it’s done!”
<?xml version="1.0" ?>
<package>
<comment>
RemoteChangeFGPerf.wsf
This script updates the Win32PrioritySeparation key in the registry to
change the performance of applications running in the foreground
</comment>
<job>
<runtime>
<description>
This script allows you to change the performance role of your computer
</description>
<example>
C:\CScript RemoteChangeFGPerf.wsf /Role:[W/S] /Comp:[computer]
</example>
<named
name="Role"
helpstring="The role (server or workstation)
for the computer"
type="string"
required="true"
/>
<named
name="Comp"
helpstring="The computer to be updated"
type="string"
required="true"
/>
</runtime>
<script language="VBScript">
<![CDATA[
'Change foreground performance remotely
Option Explicit
On Error Resume Next
Dim strRole, strComputer, objRegistry,
objMethod, objInParam, objOutParam
strRole=UCase(WScript.Arguments.Named.Item("Role"))
strComputer=WScript.Arguments.Named.Item("Comp")
Set objRegistry=GetObject("winmgmts:
{impersonationLevel=impersonate}//" & _
strComputer & "/root/default:StdRegProv")
Set objMethod=objRegistry.Methods_("setdwordValue")
Set objInParam=objMethod.inParameters.SpawnInstance_()
objInParam.hDefKey=&H80000002 '="HKEY_LOCAL_MACHINE"
objInParam.sSubKeyName="System\CurrentControlSet\Control\
PriorityControl"
objInParam.sValueName="Win32PrioritySeparation"
Select Case strRole
Case "W"
objInParam.uValue=38
Case "S"
objInParam.uValue=24
Case Else
WScript.Arguments.ShowUsage()
WScript.Quit
End Select
Set objOutParam=objRegistry.ExecMethod_
("setdwordValue", objInParam)
If objOutParam.ReturnValue=0 Then
WScript.Echo "Registry successfully updated!"
Else
WScript.Echo "Registry update failed!"
WScript.Arguments.ShowUsage()
End If
WScript.Quit
]]>
</script>
</job>
</package>
Why? WMI!
Upon closer inspection, you can see that this script now uses Windows
Management Instrumentation (WMI) instead of the WSHShell object to make
the appropriate change to the Registry. You may recall that I featured
some scripts that utilize WMI in the March 2002 cover article, “Automate
Your Administration.” WMI is incredibly powerful, and I’ll be using it
in my featured scripts over the next several months. For now, though,
let’s look at how I’ve utilized it to make remote Registry changes.
Don’t Argue With Me
RemoteChangeFGPerf.wsf requires two command-line arguments: /Role:, which
determines whether you want the target computer to optimize foreground
applications or background processes, and /Comp:, which is, of course,
the target computer where the Registry change is to be made. I’ve used
(and will continue to use) named arguments, as they tend to be useful
in keeping things organized. It would be a simple matter to modify the
Select Case ... End Select section to allow for
more possibilities, thus enabling more granular control over thread management.
Set objRegistry=GetObject("winmgmts:{impersonationLevel=
impersonate}//" & strComputer & "/root/default:StdRegProv")
This line creates the initial connection to WMI using a moniker. GetObject(“winmgmts:...)
tells WMI that I’m using this moniker shortcut. The alternative is to
bind to the WbemScripting.SwbemLocator using CreateObject
and explicitly specify the connection, impersonation level and other settings
(more on this in coming months). The remainder of this line tells WMI
that I want to connect to the computer specified in the /Comp: argument
(strComputer) and access the Registry provider
(StdRegProv), which is in the root/default
namespace.
The next line tells WMI that I want to set a REG_DWORD value (which,
I already know, is the datatype of the Registry value I need to change).
Next, I create an instance of the input parameters this Registry method
requires. The root key (objInParam.hDefKey),
requires a hex value (&H80000002), which equates
to HKEY_ LOCAL_MACHINE. The rest is reasonably self-explanatory: I set
the subkey and value names as strings, then specify the data to write
to this value.
Finally, I send the object containing all of the input parameters to
the Registry provider using ExecMethod. This
then returns a value notifying me of whether or not the change was successful.
No Test This Month
I don’t expect you to fully understand WMI just yet. It’s huge and, like
ADSI, requires months to become proficient. For now, the script is useful
as-is and is an excellent launching pad into the world of WMI scripting.
Next month I’ll tackle another administrative challenge using WMI and,
I hope, you’ll learn a bit more about its inner workings. Until then,
I’ll be using my Scepter of Power to record 10 hours of TeleTubbies for
Prince Samuel.
About the Author
Chris Brooke, MCSE, is a contributing editor for Redmond magazine and director of enterprise technology for ComponentSource. He specializes in development, integration services and network/Internet administration. Send questions or your favorite scripts to [email protected].