Using a VBScript to control Virtual Server on a remote computer

Using a VBScript to control Virtual Server on a remote computer

  • Comments 9

I was surprised to find out the other day that while I have posted many sample VBScripts - I have never discussed how to configure one of these scripts to operate on a remote server running Virtual Server.  This is really quite simple to do.  Each script starts by creating a COM object for Virtual Server - usually with a line like this:

set vs = wscript.CreateObject("VirtualServer.Application")

To operate on a remote server you just need to change this line to:

set vs = CreateObject("VirtualServer.Application", "serverName")

And you can then continue to script against the remote Virtual Server instance just like it was a local instance.  Note - however - that in order for this to work you will need to:

  1. Either be an administrator on the remote computer - or do some funky DCOM configuration (that frankly makes my head hurt - search for information on Dcomcnfg.exe if you really want to know more)

  2. Ensure that your firewall is configured correctly.  If you are using the Windows Firewall this can be done by opening TCP port 135 on the computer that is issuing the command (this is used for DCOM - and can be done by running 'netsh firewall add portopening protocol=tcp port=135 name=DCOM_TCP135') and enabling remote administration on your target computer (this can be done by running 'netsh firewall set service RemoteAdmin enable')

Cheers,
Ben

Leave a Comment
  • Please add 8 and 4 and type the answer here:
  • Post
  • I know I have asked this before... but where the heck is SP2?  The random keyboard failures of VPC are pushing me and my team over the edge.  

    Basically the issue is that if you switch back and forth between VPC and the host, VPC "looses" the keyboard.  I heard it has to do with the right-alt key getting stuck... but other than random button smashing and time fixes the problem.
  • Hi Aaron,

    Unfortunately I cannot talk about future release plans.

    Cheers,
    Ben
  • Thanks for this clue, if was look for the way to start a remote virtual machine.

    Am I right if I add to your post that you need MS Virtual PC or MS Virtual Server to be installed on the machine you use to run the script?

    If yes, is there a way to do it from any computers?

    Thanks, Alexandre
  • Alexandre - you need Virtual Server to be installed on the machine which runs the script. Virtual PC is insufficient because it does not have the scriptable interface.

    You can't instantiate VirtualServer.Application ProgId without installing Virtual Server. And you need that ProgId to DCOM to the remote Virtual Server.

    //David
  • Hi Ben,

    Thanks for posting this, and for the prompt reply when I asked about this a few days ago.  As a software tester that uses VS quite a lot, it is extremely helpful to me.  It appears to me, based on the registry entries, that the VirtualServer.Application object is in the VS executable (vssrvc.exe).  This means that I have to have VS installed and running in order to use the COM object, right?  I've tried to work around that, but no success so far.  Ideally, I would like to run scripts from a guest OS, but it doesn't really make sense to install VS and have it running on a guest OS just so I can run scripts.

    Additionally, I cannot get WSH remote scripting to work with the VS object.  Since it is a test environment, security is not an issue and I've opened up the DCOM perms as much as possible, but remote scripting still fails anytime I use the VS object.

    I have managed to duct tape some things together to make a working solution, though.  I run REMOTE to start a command prompt on a server that has VS installed and running, and then from the guest OS I'm using I run a VBScript that runs REMOTE on the client, piping in the command I want from a text file.  Unfortunately, the @Q to kill the client session doesn't seem to work with this method, so the VBScript waits a few seconds after executing the command and then terminates the remote.exe process.

    I.e., it would be nice to just register a .dll (or install a client) on a machine, which would make the COM object available on that system.  If there's a way to do that, please let me know!

    Thanks,

    Tony

    **GANYMEDE is the server running VS, where a REMOTE session named "cmd" is running.  The scripts switch the state of THEBE-1 (a guest OS) between paused and running.

    SwitchThebe-1.bat
    ==================
    remote /C GANYMEDE "cmd" /L 0 < \\ganymede\scripts\vmcontrol\switchthebe-1.txt

    SwitchThebe-1.bat
    ==================
    \\ganymede\scripts\vmcontrol\SwitchState.vbs thebe thebe-1 //nologo


    SwitchThebe-1.vbs
    ==================

    Set objWScript = CreateObject("WScript.Shell")
    Const strLaunchCmd = "\\ganymede\scripts\vmcontrol\switchthebe-1.bat"

    Set objExec = objWScript.Exec(strLaunchCmd)

    WScript.Sleep 5000

    strComputer = "."
    Set objWMIService = GetObject("winmgmts:" _
        & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

    Set colProcessList = objWMIService.ExecQuery _
        ("Select * from Win32_Process Where Name = 'remote.exe'")

    For Each objProcess in colProcessList
        objProcess.Terminate()
    Next
  • Forgot to list the SwitchState.vbs above...


    Set objArgs = WScript.Arguments
    strHostOS = objArgs(0)
    strGuestOS = objArgs(1)

    'Connect to the host OS and get a collection of the guest OSes
    Set objVS = CreateObject("VirtualServer.Application", strHostOS)
    Set objVM = objVS.FindVirtualMachine(strGuestOS)


    If objVM.State = 5 Then
    objVM.Pause
    Else
    If objVM.State = 6 Then
    objVM.Resume
    End If

    End If
  • Tony - it looks like you are hitting a problem with constrained delegation.  Your credentials get exchanged when computer A tells Computer B to launch a script - but Computer B cannot reuse these credentials to connect to Computer C unless you enable constrained delegation.

    Cheers,
    Ben
  • Thanks for the tip--I've been looking at that and playing around with it and haven't been able to get it to work yet.  The point I'm *really* trying to make here is that a "client only" install feature would eliminate the need for users to ever hear about constrained delegation or try to do this with remote scripting.  I can think of a number of scenarios (besides mine) where customers would want to install client-only for automation purposes.  I'll be glad to list them if you're interested (just leave a note on this thread and I'll respond), but I need to get some work done right now.
  • ---------------------------

    Windows Script Host

    ---------------------------

    Script: D:\Documents and Settings\Muhamad\Desktop\vbs\hi.vbs

    Line: 2

    Char: 5

    Error: The remote server machine does not exist or is unavailable: 'GetObject'

    Code: 800A01CE

    Source: Microsoft VBScript runtime error

    ---------------------------

    OK  

    ---------------------------

Page 1 of 1 (9 items)