Remote Possibilities

Be the King of the Castle by executing tasks from the comfort of your own throne.

• By Chris Brooke
• May 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.