gbohn's Posts

You might have an issue similar to that seen in VMware Workstation 15.1 mouse issue with RDP and Windows 10 1903 host . In my case, changing to disable the WDDM graphic driver use on RDP session (for the 'RDP target') solved my issue (although that option is going away if it hasn't already).

For what it's worth, I had some odd behavior recently where my Host (Windows 10 1909)  USB devices weren't showing up in the Guests removable devices list. I noticed that the vmware-usbarbitrator64.exe wasn't running, so I started that from Windows 10 Services. That didn't seem to help, but a reboot did.

As an aside, you might be able to delay the nagging by going to Windows Setting/ Update & Security/ Advanced Options and Set the 'Feature Update' deferral to max. (365 days ?). Windows keeps changing how this stuff works, but I was at 14.1.7 on 1809 and setting to this to a large value was keeping 1903 at bay... (It was the current version at the time). I then went to 14.1.8 on 1903 (by setting a small value). Also, I would think that setting the right value here (large enough to avoid 1909 but small enough to allow 1903)  would allow you to move to 1903 (instead of 1909) if you wanted to do that. But I don't know for sure since I'm currently on 1903 (and holding off 1909 this way).

Thanks, I tried this and was able to make it work. It's too bad that this comes with a bunch of baggage... As best as I can tell you lose various capabilities That is, access to local shared folders, copy and paste functionality, encrypted VMs, etc. And you apparently have to put the files for all shared guest systems as folders under one directory. (So, limiting if you have several drives and large Guests). (I've never user Shared VM's before, so maybe I'm just missing something).

For what it's worth, I just updated from Workstation 14.1.7 / Windows 1809 to Workstation 14.1.8 / Windows 1903 and things seem to be working (at least on my system). I Updated Workstation first, then Windows (to only 1903). Windows did not block the update, or prevent Workstation from launching. Before trying to launch Workstation, I did various 'check for updates'. (But, I have set to wait 14 days for Quality updates and 120 days for feature updates. So I didn't get the very latest updates).

I just went through the same pain, and this tip seems to have saved the day. I was running a Win-10 1809 system as a Host for a Centos 7.7 Guest. I would RDP in to this system from a remote 1903 system, and things worked as expected. After updating the 'target' system to 1903, I had a horribly unusable 'jumpy' mouse in the remote controlling systems RDP session (when contolling the vmware Workstation Guest). After making the change with gpedit.msc on the target system (hosting the Workstation 14.1.8 guest), the mouse is once again usable in the Workstation Guest (when RDPing in). I changed from Workstation 14.1.7 to 14.1.8, from Windows 10 1809 to 1903, and updated the Nvidia Video drivers to 441.21 (studio) all around the same time. So, which one (or combination) was responsible is not clear to me. But, it seems like there is some issue with 1903 and Workstation Guest. Thanks.

For what it's worth, I'm trying this out now. I had 14.1.7 installed on Win 10 1809. I updated to Workstation 14.1.8, then let Windows 10 update to 1903. At least so far (with all of about 5 minutes of testing done), I was able to start a few Windows Guests without apparent issue! Hurray!

I sympathize, but suspect that no such thing is available. I don't know what happened in the past few years, but we seem to be going backwards in UI usability, for both Windows and Web pages. (I guess this 'took off' with Windows 8). I also find the 'Metro' style UI uglier, less usable, and inferior in almost every way to the prior 'Windows 7' style interface. (Where you had some color, and some depth, and visual cues, and rounded edges, and could tell what was clickable,  etc. etc.)

> Do you know how to go back and forth to the machine when freerdp is in full screen mode on windows 10? I'm not sure it applies in your environment or not, but I use the xfreerdp client from a Linux environment  (X11 freerdp client version 2.0.0-rc4), and I can use Ctrl-Alt-Enter to switch between fullscreen and windowed mode.

> The problem I have is that it is difficult to justify continuously purchasing vmwware licenses just because Windows has changed, both financially and technically. > ..., but we'd be interested in hearing from the community about how folks would like to see us handle the situation. Well, I'd like to see a compatibility update for Workstation 14 . I have several licenses that I pay for with my own personal funds and having to upgrade all of them solely because Windows 10 'upgrades' are being forced on us is an unpleasant pill to swallow... It's giving me pause to consider my alternatives.

> Which quite frankly makes sense. In this case, Microsoft is pushing everyone 'forward' on their Windows 10 update treadmill, so it's relatively hard to hold back upgrading Windows in the long term. (You lose MS patch and general support faster than in the old days). So, it seems reasonable to me that they would should fix this given that they appear to still be (or at least were until recently) issuing 14 updates. This particular case aside, 1903 is starting to be pushed on those at Windows 10 1803 as I understand it. If that's the case, you would have to actively try to swim against the tide to avoid it. And, it still sounds like version 15 is more problematic than 14 for at least some of those reporting here in these forums...

I tried many things without success. I eventually found a work-around though. Some of the things that didn't work: *) I restored the Host Windows 10 back to 1803, removed Workstation, updated to 1809, re-installed workstation. *) Various flavors of installing with '/clean' or '/r'. Various 'repair installation' attempts. *) Manually deleting registry keys and vmware directories on C: between re-installs. *) Installing Workstation 15.1 At least for the moment, it appears that changing the services        'VMWare USB Arbitration Service' and 'VMWare Workstation server' from starting as 'Automatic' to 'Automatic (Delayed start)' seems to prevent the Event logs. And, the arbitration service now auto starts (after a few minutes anyway...) I don't have any antivirus other than the built-in Windows Defender. So why I am seeing a 'File not found' error when the file seems to clearly exist is not obvious to me (when using regular auto-start). And, things previously seemed to be working fine at Windows 10 1803 (before it updated to 1809). Maybe a timing issue. I tried this work-around thanks to the similar sounding topic (for Workstation 15) at VMware Workstation 15.0.3 USB Arbitration Service Won't Start Automatically .

Just a guess on my part, but maybe the file benchmark data is getting cached in the host memory. If so, that might account for the better results (delayed physical writes and just re-reading the read data after the very first read caches it).

This question seems similar to the discussion at Stretch Guest display options in WS15 not available for any guest OS after Windows Vista . Apparently VMWare decided (for some reason) that no one needs this capability for post XP OS's. I'm also hoping that they change their minds...

I would like to add my voice to also request that they return the 'stretch' guest option for Windows 7 and later guests. It's beyond me as to why this should only be available for earlier OS versions. It's annoying how they seem to keep dropping features with each successive version.