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

asked on

Master Browser Missing One Computer?

We are running a fairly large peer-to-peer network.  
Recently, the Master Browser failed to list ONE of the computers on the network.
The missing computer is pingable using its IP address.
And, if one uses Start  \\computername it shows up and is added to the local computer's Network list.
When the network list is closed and reopened, it is again missing.
When the computer acting as the Master Browser is turned off, eventually the ONE computer shows up on the Network list .. coming from the new Master Browser.
Nothing else seems out of order.  Everything seems to be working as expected.
But, since the missing computer is *important* to operations, having it missing is problematic.

What could cause this?
What is the fix beyond what we did (which was to turn off the Computer Browser service on the computer which had been the Master Browser)?
Avatar of Darr247
Darr247
Flag of United States of America image

We're forced into total guesses, since you didn't tell us what operating system[s] any of the computers are running...
if the one that doesn't show up is running the Win10 Creators Update (running winver in a command prompt window will produce a popup showing Version 1703), see if you can uninstall the creators update until microsoft issues a fix.
ASKER CERTIFIED SOLUTION
Avatar of Davis McCarn
Davis McCarn
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of hypercube

ASKER

OK.  So I am now experimenting with the LMHOSTS.SAM file.  
It does make one wonder if there isn't a handy script for updating them wholesale.

It does make one wonder if the #INCLUDE can't be used to point to any old workstation file?
Naw; that would have been too nice of Micro$oft and we all know which side of the bread is buttered, don't we?
BTW, you'll need to save it as just plain LMHOSTS (no,SAM) for it to work.
If I add a connected subnet's computer xxx.xxx.xxx.xxx name #PRE
Should it end up in the Network list?  It seems not automatically.....
Davis McCarn:  NAW to both questions or only the last one?

It does make one wonder if there isn't a handy script for updating them wholesale.

 It does make one wonder if the #INCLUDE can't be used to point to any old workstation file?
Thanks! for the tip re: .sam
I have had mixed results with whether or not the PC appears in the network listing; but, it becomes always accessible which is, to my mind, more important.  On most networks, I tend to map one of the drives as "S" (for Shared) and that becomes solid as a rock once the LMHOSTS entry is in place.

But; no, I haven't found any script to do it and I sure wish there was one, too.
Davis McCarn:  Well, to you and me, acquiring is more important.  But some folks really rely on the Network list and that's a harder problem.  I'll have to think a little harder about "why?".

I discourage MAPping.  I prefer to use shortcuts which, I believe, only create a connection when they are opened and close their connection when closed.
As the number of peers increases this reduces the number of connections statistically.  Miraculously, most people tend to close windows when they aren't in use.  But MAPs are always connected.
There may also be some small advantage to NOT mapping where ransomware processes are concerned - but that's really conjecture on my part.  Certainly it doesn't make it easier...
If the shared PC is using a fixed ip address and the entry is in the LMHOSTS file, those shortcuts will work forever, too.

The newer ransomware, BTW, gets its foothold on PC's that have not been updated and won't give a hoot if its a mapped drive or a shortcut.  The one that took out Maersk and Nestle in late June would have been blocked if the PC's had the April 2017 update installed.
A mapped drive shows up as a *drive*.  A shortcutted drive or folder doesn't.  That seems an important difference.
OK, so the share isn't actively connected; but, the ransomware can still get to it so, on that subject, its no protection at all.
How does the ransomware get to it if it's not mapped or connected?
It looks for things that are available on the network and its as simple as that.
That's what I thought.  The issue becomes what constitutes "availability".

- ability to connect is one
- credentials are another
- connection established using credentials already done is another
and so forth....
It would then be up to the specific flavor of the ransomware.
If the login credentials are stored, the user has already established a connection, or the share(s) credentials match the user's login , the share is 100% available.
If the user has to enter a password each time they access the share (which they will not like, at all), then it will be up to the sophistication of the attack.  If it can decrypt the password from that users registry, then its in, too.

I try to make sure the backups are to a storage device that is never shared and, if it is truly mission critical data, that a backup is disconnected and removed from the premises on a frequent basis.
Davis McCarn: sez:
I try to make sure the backups are to a storage device that is never shared and, if it is truly mission critical data, that a backup is disconnected and removed from the premises on a frequent basis.
What I've done similarly is to set up backups that can only be read by users.  Then, the backups are written according to quite strict and time-windowed permissions.  As far as premises go:  we use identical backups at 3 sites (via MPLS) and a cloud-based backup of one of those.

When you say:
If the login credentials are stored, the user has already established a connection, or the share(s) credentials match the user's login , the share is 100% available.
I want to make sure I understand:  The user has established a connection (and terminated it).  The credentials are stored for the next connection.  The credentials don't match the user's own local login (and it wouldn't matter if the login used on the file source computer were ever used by any human user on that computer of course).
"The credentials are stored for the next connection."  The bad guys have been able to extract stored credentials for over a decade now so you'd be in deep kimchi though your backup strategy ought to make it recoverable.
Thanks!