I have legacy Windows VMs, including a Windows 98SE VM with the the "DS Client for Windows 98" installed (i.e., the Active Directory component). That means that the Windows 98 VM is configured to be able to connect to and map Host OS shares (e.g., a Windows 7 share) with appropriate login credentials (i.e., using a user name and password within the guest that matches an existing user name and password on the host, etc.).
Upon upgrading from Workstatio 7 to 9.02, I found that my legacy VM lost all ability to connect to host shares and, indeed, even to see the host system at all. After many hours of trying to discover what caused this issue, I discovered that the Visual Studio PlugIn, which may optionally be installed with Workstation, is the culprit. When installed, that plugin enables debugging of Visual Studio solutions within guest OSes, but it does so by co-opting the NTLM and NTLMv2 protocols and traffic across those between the guest and host OSes. Apparently, this also prevents legacy guest OSes (e.g., Windows 98SE with the AD componen installed) from being able to communicate with the host OS to either see the host itself or connect to the host's available shares. By uninstalling just the Visual Studio PlugIn from Workstation 9.02, this issue went away and my Windows 98SE VM was once again able to access and map host OS (e.g., Windows 7) shares! Therefore, the Visual Studio PlugIn is unacceptably interfering with NTLM and NTLMv2 traffic between the guest and host OSes when that traffic has NOTHING to do with Visual Studio or debugging.
There are several usable sources on the internet that address how to configure a legacy OS such as Windows 98SE to map to Windows 7 (for example) shares, and these sources may help VMWare to test the above issue. One such succinct source, for example, is: http://www.sevenforums.com/tutorials/92443-sharing-pcs-printers-win-7-win-98-network.html (Do note, though, that the correct name of the registry key to enable NTLMv2 traffic in Windows 7 is "LmCompatibilityLevel". With the DS Client for Windows 98 installed in the Windows 98SE guest OS, setting the Windows 7 LmCompatibilityLevel registry value to 1, 2 or even 3 should work (mine works with all those values).
The above issue affects the following Windows guest OSes: Windows 95, Windows 98 and 98SE, Windows ME, Windows NT 4.0 SP4 and later, and Windows 2000. It will also affect any other OSes that rely upon NTLM or NTLMv2 (version 2) protocols for authentication and/or session security.
The major impact this issue presently has is that one cannot both debug Visual Studio solutions within Windows guest OSes and simultaneously enable legacy guest OSes to access host resources such as enabled shares.
Disclosure: I have 36 years of experience in IT at all levels, including as an architect, engineer, DBA, CTO, etc., and have used VMWare Workstation versions 2, 3.x, 4.x, 5.x, 6.x, 7.x and 9.02, as well as other VMWare and Microsoft virtualization products (e.g., ESX Server, etc.).