That is kind of weird. I get the same results.
Also, when you write a VIX_GUEST_ENVIRONMENT_VARIABLE, it does not show up in computer/advanced. But it is available to VIX.
I still have not had a resolution on this issue. I called up VMWare technical support and they told me to email them with the problem. I used this form:
If I get any feedback I will let everyone know.
I've created VMWareTools part of the VMWareTasks library that implements wrapper functions that make this kind of stuff simple. Specifically ReadFile, ReadFileLines, ReadFileBytes, RunCommandInGuest that returns StdOut and StdErr output and GetEnvironmentVariables.
VMWareVirtualHost virtualHost = new VMWareVirtualHost();
VMWareVirtualMachine virtualMachine = virtualHost.Open("C:\Virtual Machines\xp\xp.vmx");
Shell guestShell = new Shell(poweredVirtualMachine);
Dictionary<string, string> guestEnvironmentVariables = guestShell.GetEnvironmentVariables();
Uploaded 1.2 daily build.
Much easier! I'd be glad to hear about other feature requests for covering common VMWare tasks scenarios.
Pretty effective !
I have the same issue: vmrun.exe readVariable method returns only TEMP and TMP variable values. It returns empty string for all other variables.
This happens on one VM (Windows 7 64-bit), while on other VMs it works as expected...
What I noticed:
- On problematic VM there is only one process vmtoolsd.exe ("C:\Program Files\VMware\VMware Tools\vmtoolsd.exe")
- On other VMs there are two processes vmtoolsd.exe:
a. vmtoolsd.exe ("C:\Program Files\VMware\VMware Tools\vmtoolsd.exe")
b. vmtoolsd.exe ("C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr)
I've tried to launch vmtoolsd.exe with this parameter, but the process doesn't appear.
Have you figured out why this happens/how to fix this?
Results will depend on the guest user being used, and whether or not you use interactiveSession. interactiveSession isn't exposed by vmrun, but can be used if you use VIX directly. Its also possible you've hit a (fixed) bug, since we had issues with Windows env variables a few years back. We'd need some version details to know.
vmtoolsd with -n vmusr means someone is logged into the console, so a second, user-mode copy of tools is running. This copy runs as the logged-in user, and handles drag&drop and other UI related things. The other copy of vmtoolsd is running as SYSTEM, and as such will only see things SYSTEM sees (like most env variables). The SYSTEM copy also has no access to the desktop.
VMware Tools version on "problematic" VM was older than on other VMs. Upgrade to a newer version of VMware Tools solved the issue.
Thank you much for pointing me to the cause and vmtoolsd process role explanation!