Did you try just disabling smbv1 and not actually removing the windowsfeature?
edit: by running this command in an elevated powershell prompt:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
EruvWeather, TheEther, guys, this is driving me nuts...
As it stands NOW my wife's PC continues to have NET VIEW work properly, and has since I did a clean install of her X64 W10 Pro Ver. 1709. On the other hand mine will only work IF I reboot the Router and her PC is not on. Once her's comes on, it no longer works, and will never work again until I reboot the router.
I opened the POWERSHELL on both PC's and ran "get-smbserverconfiguration" and compared results.
Interesting, on mine EnableSMB1Protocol is set to True, but on her's, it is set to False?
Checking Features installed I have SMB1 Server checked where her's has Client checked?
Odd, what do you have?
I've set mine to Client now but need to re-boot. Will update when I come back on.
EDIT:
FIXED IT!!!!
GET-SMBSERVERCONFIGURATION now matches her's and it WORKS as expected!!!
C:\>net view
Server Name Remark
---------------------------------------------
\\IRV8700 Irv's 8700
\\LARAINE-XPS8500 Laraine's XPS8500
\\READYSHARE readyshare
The command completed successfully.
I don't KNOW how my SMB1 features were set or when, or even why.
Suspect at this point a change happened during one of MS's Updates?
Searching the web I found this page, https://community.spiceworks.com/topic/1995592-disabling-smb1-stops-domain-authentication marked SOLVED.... in it:
-------------
M Boyle May 17, 2017 at 10:37 AM
Did you try just disabling smbv1 and not actually removing the windowsfeature?
edit: by running this command in an elevated powershell prompt:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
---------------------
Wonder if I did that it would have fixed it as well?
EruvWeathergive this a try... might just work!
Oh, sorry. Ok, I can view it with Wireshark.
AFAICT, I can see standard NetBios Queries and responses. I also see a successful connection to READYSHARE. So, it looks good there.
I also see LLMNR queries, but no responses. As I mentioned earlier, LLMNR is kind of dead, so it's no great surprise that the router is ignoring them. Nor is there any harm.
The next bit is where NET VIEW comes into play. For reference, these two articles are pretty good at describing how the Windows Computer Browser service works:
Name Resolution and Browsing (look for Browsing in a Windows Network)
How Computer Browser Service Works
In the packet capture, you can see packets 56 and 58 are Computer Browser Service packets. Packet 56 is a Get Backup List Request from 192.168.1.30. This is a request to find a server that can provide the list of Windows servers on the network. Packet 58 contains a Get Backup List response from the Netgear, stating that READYSHARE is a server.
Now, it's my understanding that what should happen next is that 192.168.1.30 should contact the server (in this case READYSHARE) and ask for the list of Windows servers via a NetServerEnum request. It appears that 192.168.1.30 never does this. This might explain why the NET VIEW command is returning nothing. The command has nothing to display because the computer never sent a NetServerEnum request. Why? I don't know.
Anyway, it looks like the Computer Browser Service operates on 12 minute cycles. That is, every 12 minutes computers that have File Sharing enabled will announce their presence. You could run Wireshare through an entire 12 minute cycle and see what happens, although I'm not sure if a whole lot will be learned from it.
Both of my Win10 systems are up to v1709. The one with the issue is hard-wired into the router, the one not exhibiting the issue is connecting via WiFi on the 5GHz network.