I should have added:
NO firewalls are running on any machine. Windows Firewall is turned
completely off in all respects. There are no third-party firewalls.
Ken
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/19.D6.09445.DB483365@cdptpa-oedge03
** 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.