Link to home
Start Free TrialLog in
Avatar of hypercube
hypercubeFlag for United States of America

asked on

Function Discovery Resource Publication Service running but not always working to gain Network listing.

Function Discovery Resource Publication service set to Automatic seems to fix listing of workstations that drop off the Network list in Windows 10.
However, even when the service is running, we see some computers still falling off the list.
Then, restarting the service brings the computername back again right away.

If we can just focus on the issue, and not my dumb desires to have this work, are there any ideas?
All I can think of is a scheduled batch file to restart the service.  It doesn't appear that a reboot is necessary after the restart.
But, I believe that I've also seen workstations that address using IP addresses become confused by restarting this service.   I'm not sure about this....
Avatar of McKnife
Flag of Germany image

Discovery has two sides: the machine discovering and the machines allowing themselves to be discovered. Make sure that network discovery is on on all machines. Network discovery can be influenced negatively by 3rd party firewalls (if any are present).
Avatar of hypercube


McKnife:  Good point.  In this case, Network discovery is ON on all the machines.  So, now keeping the effect of Function Discovery Resource Publication being in a Running state effective in supporting discovery is the issue.  I might add that it appears to be the machine needing to be discovered that has the greatest effect on this.

Here's our experience:
1) Nothing special was done and all the computers were listed in Network.
2) Some of the workstations started disappearing (i.e. disappeared) from the list in Network.
3) We turned on (set to Automatic)  the Function Discovery Resource Publication service on the (few) missing workstations.  This seemed to fix the problem for them.  They were once more listed in Network on all the computers.
4) We discovered (!) that of the few, some workstations WITH Function Discovery Resource Publication Running had once more disappeared.  Restarting the service on these computers fixes this rather immediately.  No computers had to be rebooted for this.

So, now I want to prevent the latter from happening......
Avatar of McKnife
Flag of Germany image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
McKnife:  No 3rd party firewalls as such.  Only Malwarebytes and Windows Defender and Windows Firewall.
Anyway, MOST computers aren't affected by this.  It's more like 1 or 2 out of 30.
All of my research (mostly here) suggests that the computer list in Network is going away - that was until I was told about Function Discovery Resource Publication service which by default appears to be Disabled.

I rather doubted that assertion really as, unless one is relying on a Server-based service or has a fundamental notion that computers should be heard and not seen (at all) then I don't see it going away.  But then I'm a hick in the sticks using peer-to-peer networks.

Now, I do understand that NetBIOS has been deprecated and, therefore, the Network list might be flaky as a result of THAT - because NetBIOS has been the traditional source of the list
But saying that NetBIOS has been deprecated isn't the same thing as to say that the list won't be there or won't be populated (in some other manner), etc. does it?

I guess we agree on what might be done.  If the workstations are rebooted daily then that might do the trick.  Or we could add a scheduled task to restart the service.
I did restart the service on one computer that had mysteriously dropped off the list with the service Enabled (thus this question) and directly thereafter all sorts of communication issues with that computer ensued.  I can't prove cause and effect but it was just too coincidental to ignore.

As background on that one:
The workstation is accessed using either Windows file sharing OR some sort of programmed accessed via DCOM.
With recent Windows updates we found that accessing it using the computername didn't work and resorted to using its fixed IP address on the LAN for addressing and access.
At the moment, some "clients" are set up with IP addresses and some are set up with computername.  So, when I reset the service, I wonder if that didn't do something strange?  That is, mess up the connections to the "computername"-configured clients?  Hypothesis being that even though it was missing from the Network list, it remained working as if there were some kind of name service available.
Anyway, with that experience, I prefer to restart the service during non-working hours - like at 7 a.m.
"So, when I reset the service, I wonder if that didn't do something strange? " - I don't expect problems. Try it.
McKnife:  I did try it.  I was trying to describe something strange that DID happen in the broader context of the network and app's.  The point was to not restart the service during working hours is all.  We agree.
Thank you!
Thanks again!