My main box can see a Win 7 box. The Win 7 box can see and connect to the drives on the main Win 10 box. The Win 10 box can see 2 of the other Win 10 boxes and the Win 7 box but it will not allow it to connect. To really stir it up. The Video Box that is Win 10 can see and share with the Win 7 box.... The only difference on it that I can even see is that I do not require a Sign on Password on the Video Box. ( I tried setting one of the other Win 10 boxes this way but it still could not connect to the Win 7 box) I have also went through and matched the local policy items. The GPO items are all "not selected".
After having tried all of the suggested fixes, I'm at a loss and can only think that MS has something that is killing me. I have turned off all of the spyware reporting back to them but I guess I can turn on the updates again if they ever solve it.
Any ideas would be appreciated.
It is a Microsoft network issue and a fix is supposedly being worked on. Problem apparently is that Win 10 does not broadcast NetBT request over a LAN when searching for devices thus all devices are not being discovered.
Many thanks for the advice which worked perfectly. I am always appreciative of really smart folks like yourself who also take the time to help other less gifted users but still passionate users like myself.
If you want to check it out, open SERVICES on EACH PC or server on your workgroup or domain, scroll to "Function Discovery Resource Publication", and start it. Then check to see if all your pc's show up in explorer. There is also a "Function discovery Provider Host" that may play into it. There are a few other settings that may play into other device discovery that I'll have to look into. All my devices actually show up though.
If this works for you, change the start up for the service to automatic and it should stay on. I don't know the ramifications of changing this setting so Ill be monitoring to see if there are any obvious ones.
My guess is that some change that was implemented in the latest insider builds has affected network discovery. I know that my servers all had this ("Function Discovery Resource Publication") turned off for as long as they've been in service, which is a matter of years, and it always worked, so it isn't the other pc's, it's the Win10 boxes.[/QUOTE]
Disabled Samba 3 on the PC not showing in the network list, rebooted it and now it's showing. Thanks.
I too had network devices no longer visible in the Network folder of a Windows 10 desktop PC, although I could navigate to them by typing \\devicename in the address bar. Strangely though my Windows 10 laptop showed part of my network in its Network folder, but not the other part. A Windows 7 laptop could see everything without a problem. This strange behaviour began around the time of the 1511 update last year. I managed to solve it after some digging.
My network was configured as 2 workgroups; one Windows 10 laptop and a NAS running in a workgroup called MSHOME, and a Window 10 PC, a Windows 7 laptop and 2 further NASs in another workgroup called WORKGROUP.
The MSHOME Windows 10 laptop didn’t show the WORKGROUP devices in its Network folder, but did show the MSHOME NAS.
The WORKGROUP Windows 10 PC only showed itself in the Network folder, although I could navigate to both of the MSHOME devices and to one of the WORKGROUP NASs without a problem. However, when I tried to navigate to the second WORKGROUP NAS, which ran under NAS4Free, I got an error saying that the PC did not have the necessary protocol to do so.
Following advice elsewhere, I moved all my devices into WORKGROUP. And guess what? Now the Windows 10 laptop only showed itself in its Network folder. Things had got worse. At least the Windows 7 laptop still showed everything.
I tried most of the solutions suggested in this thread and elsewhere, but nothing seemed to work. Then I stumbled upon a post that talked about Master browsers, something I had not heard of before. Basically, the devices on a TCP/IP network get together and choose one of them to hold a map of the addresses of all the devices, and what workgroups they belong to. This speeds up network discovery. Windows 10 seems to depend on it much more than Windows 7.
I came across a very handy description here:
It also provides a simple tool to help you determine what you have on your network, and which device has the Master browser. I ran this tool and discovered that my workgroup had TWO devices claiming to be the Master: one was the NAS4Free NAS and the other was my Belkin router. Although one of the devices should have backed off, neither would. NAS4Free gives you the option in its CIFS settings to stop it becoming a Master. I did this, rebooted the PC and laptops, and everything worked. The Network folders of both Windows 10 machines showed all devices, whether in WORKGROUP or MSHOME. The protocol error disappeared as well. So if you are still having problems, give this solution a go.
Just sits forever and doesn't do anything -- running latest build 1511 W10 x-64 pro.
Network currently - One Linux server, W7 ultimate x-64, XP Pro (as a VM on Linux Host) , 2X W10 systems, one Linux test box.
The W10 systems have the network problems - even the XP VM on a Linux Host sees the W10 machines.
All I can say is that the little routine worked for me. All it does is automate the steps in Scott Orgin's explanation. You can try to duplicate the individual steps using the CMD prompt (run as administrator to be sure).
"net view /domain" gives a list of the workgroups on your network
"net view /domain:WORKGROUP" for each workgroup (substituting WORKGROUP with the name of the workgroup you are interested in). This eventually comes back with a list of devices in the workgroup in the format \\DEVICENAME.
Then for each device: "nbtstat -a DEVICENAME". This gives you a table of information for the device.
One or more of the devices in a workgroup should show a property in the format __MSBROWSE__. This is a Master browser. If you have more than one in a workgroup, you have found your problem...
If you need more help, you could try looking through the comments on Scott's website - you'll see others had problems. Otherwise, you could try this site: