I am dealing with some software that "wants" to be run from a system that has a desktop (call it the primary package). This software invokes other packages that also run as user level applications on the desktop (call them the secondary packages).
Most of these secondary applications are windows based programs that require their gui in order to run, and the primary package programatically pushes buttons on the secondary packages in order to achieve the desired results. One of the secondary packages is a DOS based application that uses the button pushing technique, while another can actually be invoked by OLE automation and driven directly. (For reference the secondary programs analyze data and generate reports that the primary package will email out)
The desire is to move this configuration to a VM and perhaps use something like SrvAny to shoehorn the first application into a Windows service. However I believe that when the VM starts that there will be no desktop by default, so my questions are:
How will the gui based programs react?
Will they likely crash and burn when the primary program tries to invoke them but finds no desktop?
Will windows automagically support the secondary programs?
Or do I have it totally wrong and running the VM does create a default desktop?
The guest OS will most likely be W2k3 server, hosted on ESX 3.5
BTW the reason for running headless is security policies that disallow unattended systems to be left running.
Edit
Thanks for the answers - I wasn't sure of the mechanics of the VMs virtual graphics system.
As to the security policy, in hindsight I didn't explain it in the best way possible. What I really meant to say was that an alternative solution was proposed to me as being:
Start the VM
RDP to the VM to get a desktop
Start the software
Disconnect from the VM (not logging off) so that the software keeps running in that session
The leaving a disconnected but running RDP session is seen as a no-no, not normal VM functions.
However
That does raise the question of is it possible to connect to whatever virtual desktop exists that the software will be running under? (so that I might be able to interact with it) (This is starting to sound like a "Have my cake and eat it too" request!)
Although I am note entirely sure what this program you are running is getting at - and what this misguided "security policy that disallows unattended systems to be left running" is or what problem it solves, there are plenty of VMs that run on host Operating Systems that are GUI-less.
As you stated ESX Host is gui-less. Also a good alternative is VirtualBox which has the VBoxHeadless and VBoxManage command set that runs and configures Virtual Machines on headless (GUI-less) operating systems.
The Guest operating system, W2K3 or any other, works just as it would in a GUI Host. The operating system is there, running on a "virtual" graphics adapter. You can RDP into the VM and it has the GUI-based operating system just as it would be a separate server in the datacenter.
To summarize, your gui-based programs will run perfectly fine in it's normal Guest OS with Gui, regardless if the Host OS is gui-less or not.
Just to reiterate the VM itself is not "headless" it happily believes it has a running GUI desktop running on a virtualized video adapter if you have an OS installed that runs a GUI interface. You might not have anything actually connected to the VM instance to "see" the desktop but it does exist and as far as the software is concerned it should be no different than a real physical desktop.
Whether the Host it's running is Headless or not will have no effect. In fact the same would apply to a standalone system. I'd also seriously question the unattended system security policy - how do you deal with standard servers surely they run unattended?