Ken, If you have the latest and greatest Avast running then effectively you DO HAVE a firewall running, albeit not by name. The latest versions of Avast have packed in so much more than the standard AV software that they are in danger of becoming a "Norton AV" and bloating themselves out of all reason. I would suggest disabling everything but the standard AV features from the control panel. We have seen similar "unusual side effects" here
Dave -----Original Message----- From: ProFox [mailto:[email protected]] On Behalf Of Ken Dibble Sent: 30 October 2015 14:47 To: [email protected] Subject: [NF] Network Discovery Broken; Missing Assumptions? Hi folks, I have been going nuts for the past week researching this on the web and discussing it with our IT consultants. I am not getting the results I would like. I thought maybe some people here could fill in the missing links. "Network discovery" is the process that enables some devices on a network to "see" other devices on the network. And I mean "see", not "connect to". There are a lot of permutations of this. It is not a concept that is limited to Windows-only networks or domains. There are a lot of pieces to the puzzle of what makes it work, and apparently it's very easy for one or more pieces to go missing, temporarily or permanently, and then it doesn't work. I have a SAMBA 3 "domain", and the domain controller is a CentOS linux box, although I have been told that my domain controller is not really a domain controller, it's an LDAP server. *shrugs*. All of the workstations on the domain except one are running Windows 7 SP1 Ultimate or Pro (there's an XP Pro that I have to use because the support tools for the SAMBA 3 domain won't run on anything later). There are a few Windows Server machines of various vintages as well. It used to be that I could use the "Network" app, or the "Network" treeview on Windows Explorer, on any Windows 7 machine to reliably "see" a list of all of the machines that were running and connected to the network. This has suddenly stopped working reliably. Typically there are 80 to 90 machines connected on any given workday. Now only about half of them show up. The only 100% reliable way to fix this is to shut down the entire network (PDC last), and then restart it (PDC first). It used to happen about once every 6 months or so. It happened a couple weeks ago, I shut down and restarted the network, and it only worked for about 3 days. Now, I'm going to give you a LOT of information about this. (Remember, I said I've been researching and experimenting for over a week.) I hope you'll have time to read it and, perhaps, not ask the obvious questions because I've already answered them. I'm looking for the stuff I haven't already tried. The machines ARE connected. I can get to them using \\[machine name]. Note, I said \\[machine name], not \\[IP address]. Therefore, some aspect of DNS lookup is working. This is NOT a master browser election gone wrong. There is, in fact, no master browser on the network. I verified this by running a batch file to execute nbtstat -a for every machine that was connected and outputting the results to a text file. No "MSBROWSE" appeared in the stats for any machine. There never was a master browser on the network, and, as I said, up until a week or two ago, this feature worked reliably 99% of the time. SAMBA can be a WINS server. However, setting it up as such and configuring machines to access it does NOT solve the problem. In \etc\smb.conf, under [global], we added: wins support = yes name resolve order = wins lmhosts hosts bcast and restarted SAMBA. We then configured a couple of machines that weren't showing up as WINS clients. It did not help. We never used WINS on this network until I started confronting this problem, and we never needed to. As I said, until a couple weeks ago, it "just worked". There's a lot of stuff on the web about how MS has broken various aspects of network discovery in Windows 7, 8, 8.1 and 10. My research indicates that there are five services that are, at least potentially involved: DNS Client Function Discovery Provider Host Function Discovery Resource Publication SSDP Discovery uPnP Device Host MS says that all of these have to be running in order for network discovery to work. There's a few problems with that statement. First, some of them don't exist on Win XP, but network discovery used to work just as well on that box as it did for the Win 7 boxes, until a couple weeks ago. Second, lots of the Win 7 boxes have only some of those services running at any given time. (I can use Server Manager, the old NT utility, on the Win XP box to check and see what's running and what's not on any machine that is connected to the network, regardless of whether they show up in the "Network" app.) And again, until a couple weeks ago, all of this "just worked". This is NOT a Windows update problem. Automatic updates are not enabled on any of the machines, and only a small subset of the machines received any updates in October. We have a periodic maintenance schedule for manually updating machines, and we always and only apply "important", not "recommended" or "optional" updates. Some of the machines that were updated this month show up reliably on the network and always have; others used to but no longer do. There is no relationship between updates and this change in behavior. And there is nothing on the web indicating that any particular Windows update broke network discovery. I am pretty darn sure that if it had happened, somebody would have written about it. (There's a lot of stuff about those services not running when they allegedly should be, but nobody has flagged a Windows Update as being the culprit.) I can use a variety of tools to start those services remotely on the machines that don't have them running. I've tried various combinations. The brief summary is that nothing works reliably. Machines that have all of them running don't necessarily show up. Turning some of them on will sometimes cause some machines to appear. Those that work best, but not 100% reliably, seem to be Function Discovery Provider Host and Function Discovery Resource Publication. But sometimes machines that I cause to show up in this manner will disappear a few seconds or minutes later (yes, they are still running). It gets worse. MS says that some of these services have dependencies on the others, and if services are turned on and their dependents are off, the services will be automatically turned off. Except that doesn't happen reliably, and even when it does, it doesn't always affect the network discovery situation. And sometimes simply resorting the list by machine name (ascending to descending and back again) on a Win 7 machine will cause machines that were invisible to appear--for a while. Finally, we have a good network malware system running (Avast). It has not reported any problems with these machines beyond the usual, typically infrequent, email attachment and nasty website detections, which it effectively blocks. I have a network console where I can monitor everything it does. Why do I need this? Because I do. Yes, there are other ways to do things, but nothing beats the speed and ease of being able to go to a list of 90+ machines, double-click them one at a time, and instantly have access to shared resources on them. If I can't get this working reliably, my productivity on certain tasks is going to go way down. And because I hate it when people tell me that when stuff that I have come to rely on is taken away from me it's for my own good. I am not a child. I am the one who determines what is for my own good, nobody else, and especially not Microsoft. So. What am I missing? Do any of you know how network discovery really works, including all of the missing pieces? Preferably any solution proposed should include an explanation of why a thing that "just worked" suddenly stopped working for no identifiable reason a couple of weeks ago, and why it is impossible to restore that functionality, before proposing that I do something that I wasn't doing before the problem occurred. Thanks. Ken Dibble www.stic-cil.org [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
