#1
|
|||
|
|||
Virtual Server 2005 Script issues
At my company, we use Virtual server 2005 for our build machines. I am currently looking at ways to include our virtual machine code into VBP. Unfortunately, we have run into scripting issues that are causing us to create work arounds that are not pretty.
I have created a step that will start a virtual machine (vm) on our server. If I attempt to run this code throught a script step, I recieve an error utilizing the VM object. (javscript) If I take the same code and execute it with cscript, I recieve no errors. Therefore, we are currently writing our code to a javascript file, and then executing it with cscript. I would like to add some exception handling, and macro definition within my script. Anyone have any thoughts? Example Script: var vmServerName = "MYVIRTUALSERVER"; var buildVmMachine = "Test Virtual machine"; var vmServer = new ActiveXObject("VirtualServer.Application", vmServerName); var oBuildVM = vmServer.FindVirtualMachine(buildVmMachine); //See if machine is running. HBeatFlag = oBuildVM.GuestOS.IsHeartbeating; //Tell user WScript.echo("HBeatFlag = " + HBeatFlag); |
#2
|
|||
|
|||
We will be installing Virtual Server 2005 to test this in the near future, but in the meantime, what error do you receive using the VM object in a Run Script step?
For now you can pass parameters to cscript.exe/wscript.exe so you could pass MACRO values as arguments to your script. This will at least make your jscript be more modular and reuseable. I've attached some simple sample jscript that could be used to provide some exception handling while using cscript.exe to execute your jscript and have Visual Build Professional detect when an exception occurs. |
#3
|
|||
|
|||
Virtual Server 2005
Thank you for the suggestions. We currently use the workaround you provided. We create a .js script file, and execute it ustilizing cscript.
The error that is returned is Error line 6, Column 1. |
#4
|
|||
|
|||
Kinook support was able to find a resolution for this issue. The issue appears to be due to the Virtual Server COM interfaces requiring the security level be set to Impersonation or higher [1]. By default, COM uses the Identification security level VBP and scripts executed within it will run at the system-wide setting since it doesn't explicitly set a security level. Changing the default security setting to default or higher should resolve any issues.
• Run dcomcnfg from the run dialog • Navigate to Component Services • Navigate to My Computer • Right click on my computer & select properties • Switch to default Properties tab • Set Default Impersonation Level to Impersonate. • Click ok and restart machine. |
|
|