For the benefit of any looking for a solution.
The X-windows nature of the tools and the installer do not place a requirement on the Guest.
Rather you simply need to run the install [from] a system that is hosting an X-server.
For example:
X-ming is a free X-server for Microsoft Windows.
A companion program called X-launcher has a wizard for creating logon connections to a foreign or remote server (like the target you want to install VMware Tools on).
If you launch X-term (from Microsoft Windows running X-launcher) on your target (where you want to run the VMware Tools installer) you will get a Bash command shell prompt.
When you start the VMware Tools installer script or binary (on the target) the target will "Fling" the output of the X-Windows display back to your local Microsoft Windows desktop, X-Ming will accept the remote call and create a window for the application on your local display (the windows desktop) and procede to "install" the tools on the remote target.. which is what you are trying to do.
The install will succeed, the local Microsoft Window for the VMware Tools program running on the remote target will close. And you will have installed the VMware Tools on your remote target which continues to [not] have any portion of X installed, and does not need to have an X-server installed in order to run the VMware Tools Installer.
You could of course do the same thing using SSH from a remote Linux workstation with an X-server, as most SSH clients also have a side channel configured to "accept" foreign calls to start an X-session once authenticated on request.
Hope the explaination clarifies a few concepts.
This is not "out of the ordinary" for installing applications with a GUI user interface on a remote "server" it was quite the norm in the 1980's, 1990's, 2000's all the way up until today. Placing the Windows "server" on the same box as where the apps were running was the "oddball" thing to do because usually you wanted your long term running processes on a big secure machine with lots of uninterruptable power supplies and big iron. The local "display" server was only meant to "host" graphics -- much like serial modem "Terminals" only displayed character screens -- or "Line printers" and Keyboards only displayed output and took input.. they weren't expected to be powerful enough to [do it all].
Microsoft Windows RDP is similar except it displays a [whole] desktop by default ["weird"] RDP can "launch" and display only a single app window from a remote system.. we just are not accustomed to doing it that way. You could have lots of windows from lots of workstations, and in that way "benefit" from running the hard stuff on the remote CPUs of those systems.. "offloading".. again.. we just are not accustomed to thinking that way.
Hope this helps.
