Good day to all.
I'm trying to set up a means of transferring files back and forth between my Win7 Pro host and my Win98se guest. Because the guest is Win98, the Shared Folder option is not available to me.
The host machine is often not connected to either a wired or wireless network. And - the Win98 guest does NOT need Internet access. Acordingly, I figured that "Host Only" networking seems to be the most appropriate method.
But: I can't make it work and I suspect that I have missed doing some obvious tasks.
First: I went into VMware Player -> Virtual Machine -> Virtual Machine Settings -> Network Adapter and selected "Host-only". The Win98 guest has been rebooted several times.
1) I can see two different VMware connections in Win7's Networking & Sharing Center: VMware Netowrk Adapter VMnet1 and VMware Netowrk Adapter VMnet8. Both of these are shown in the "Unidentified Netowrk" section of the page and are marked as "Public Networks". I assume this is most likely a problem but I don't know how to fix it.
2) On the Win7 host, VMnet1 is shown with address 192.168.220.1 and MVnet8 has address 192.168.106.1. Both have subnet masks of 255.255.255.0
3) On the Win98 guest, the AMD PCnet family Ethernet Adapter is shown as having address 192.168.220.128
I'm not sure if should have done this, but I did install "File and printer sharing for Microsoft Networks" in the Win98 guest. The Workgroup name in both the Host and Guest machines is the same.
Opening "Network Neighborhood" shows the Win98 machine and "Entire Network". At no point do I see any sign of the WIn7 host.
Opening the Network section of "Computer" on the Win7 Host shows only the Win7 shares.
The bottom line: what I want to be able to do is have the Win98 guest have read and write access to the 😧 partition on the Win7 host. Allowing the Win7 host to have read / write access to the Win98 guest would be nice but is not essential. Besides - I can always mount the VM's hard disk in the Host machine if needed.
Several hours of searching the VMware knowledge base hasn't helped. So: would some kind soul be able to give me some guidance?
I have not use 98 for a while now but basically it is a Microsoft issue more than a VMWare issue.
First you must check connectivity between your Win7 and 98. Try to ping on each direction. Does it work (having actual replies) as opposed to unreachable.
In order for 2 MS devices to exchange files, they must be on the same workgroup.
Control Panel\System and Security\System for your Win7 Host, Somewhere in Control Panel\System for 98.
Look at the following link at it seems to explain all the details. It is a google cache of windows live.
Hope this help.
Many thanks for the pointer to the 'Extreme How-To' page for Win98 - Win networking. This did help (it reminded me that I should try pinging each machine) but I am still having problems.
My Win7 machine can see the Win98 VM 'C' drive and I can map it to a drive letter easily. But the Win98 machine can't see or even ping the Win7 host.
However, if I turn the 'Public Networks' portion of the Windows firewall OFF, I can ping the Win7 host from the Win98 VM. I can also map a drive letter to the Win7 share from within the Win98 VM.
So: how do I convince my Win7 host that the VMware Network Adapters VMnet1 and VMnet8 belong NOT in the Public Network collection? Alternatively, how do I configure the Windows firewall to allow those networks to not be blocked?
Good day to all.
I've been having problems getting Host Only networking to work with a Win98 client hosed on a Win 7 Pro system. The problem turned out to be the Windows 7 firewall treating the VMNet1 and VMnet8 as Public - and thus blocking them.
I've been fighting with this on and off for the past few weeks. However, I finally found a solution.
has all the details - and the fix. As others have mentioned in this thread, this is a Windows problem, not caused by VMware. However, no one has been able to help me find a fix or workaround for the problem.
The above link will help others in the same boat as I get their systems working.
The following is a direct copy/paste of the relevant information, however, all credit belongs to "oising" .
As you can see, the lower two connections are seen to be in a “Public network.” This has the net effect of making Windows believe the whole machine is exposed to a public network, and it will trigger the public profile for Windows Firewall. This is normally a good thing, but in this case it’s just an annoyance. These two network connections are not actually external gateways that can let in the bad guys. They are just dummy adapters for VMWare’s host bridging which allow the virtual machine to access the host machine’s network. Because they don’t identify themselves properly, they are flagged as an “unidentified network,” and your changes are never persisted.
So what do you do? The magic information is buried in MSDN:
Vista automatically identifies and monitors the networks to which a computer connects. If the NDIS_DEVICE_TYPE_ENDPOINT flag is set, the device is an endpoint device and is not a connection to a true external network. Consequently, Windows ignores the endpoint device when Windows identifies networks. The Network Awareness APIs indicate that the device does not connect the computer to a network. For end users in this situation, the Network and Sharing Center and the network icon in the notification area do not show the NDIS endpoint device as connected. However, the connection is shown in the Network Connections Folder. Also, if NDIS_DEVICE_TYPE_ENDPOINT is set, the Windows Firewall ignores the connection when Windows Firewall enforces public, private, or domain policies.
So I hacked together a PowerShell script that will scan your adapters for VMWare’s virtual NICs and make the necessary registry changes. It will also disable/enable cycle the adapters so that the changes take effect. After this is done, you will see them in your Network Connections page – albeit lacking a network category -- and the connections will no longer appear in the Network and Sharing Center nor will they affect your Windows Firewall policy no matter how many times you reboot!
Here is a copy of that Powershell script. Note that you have to run the script from an elevated admistrative level.
Hope this helps!