What's up with IVMGuestOS::ExecuteCommand?

What's up with IVMGuestOS::ExecuteCommand?

  • Comments 5

A number of people have noticed that the guestOS.executeCommand() exists but makes no sense.  It takes no parameters, and always returns an error.  This API was originally intended to allow you to execute a command inside the guest operating system.  This is incredibly useful, but it also had a significant security issue.  Namely - the command would get executed under the context of whichever user was currently logged in - which may not be the same user as the person who was issuing the command.

Unfortunately this issue was discovered after the beta version of Virtual Server 2005 had been released.  This meant that removing this API would break compatibility with any custom applications that users had developed against the beta version of Virtual Server.  Rather than doing this the API was left in place, to maintain the same COM interface, but all functionality was removed.


Leave a Comment
  • Please add 4 and 4 and type the answer here:
  • Post
  • Hi Ben,

    What about the future of the command? Is it likely to return with security additions making it safe to use, or will it be killed completely?



  • What do you mean "whichever user was logged on"? What if no users were logged on? What if multiple users were logged on?


  • Adam: He means the user who executed the script.

  • Betas are betas.  In all of the arguments I've seen about whether backwards compatibility is important or not, I've never seen anyone say that backwards compatibility to a beta is important.

  • Ben,

    I noticed this ExecuteCommand() fact when I was researching for my Virtual Server 2005 scripting article*, as well as talking to IT Pro peers interested in this area. There is no direct means to call even native FindWindow() Windows API in the gust OS from the Virtual Server COM API, which would certainly be very useful to automate and control guest OS (without having to resort to WMI for simple operations for instance).

    Will this behavior change or learning WMI will be the only way forward, especially when Windows Virtualization core will have no COM API interface (but WMI support only)?

    * Part I is at http://go.microsoft.com/?linkid=5461095 or http://mcpmag.com/features/article.asp?editorialsid=623 and Part II should be on its way soon.

Page 1 of 1 (5 items)