What's behind the scenes of Windows network discovery?
-
I'm setting up a Windows application that is multi-user but the losers made it so the installation program sets up file shares (UNC paths \server\share\folder), despite it being based on having SQL Server.
I had it working but changed a few things and now it's broken.
The error I get on DesktopB is: Can't find path \DesktopA\share\folder..What's going on behind the scenes in Windows for desktop B to find desktop A? There is no AD, just a couple of Windows 10 PC's. Static IP's, not using dhcp no DNS. Is it netbios, upnp, some kind of broadcasting or something else?
-
I thought it was Simple service discovery, but other sources are saying it's based on SMBV1....
-
@DustinB3403 said in What's behind the scenes of Windows network discovery?:
I thought it was Simple service discovery, but other sources are saying it's based on SMBV1....
yeah, that sounds familiar - if SMBv1 is disabled (and it should be) then that networking crap might be broken.
you can try setting up HOSTS files to see if that solves your issue.
-
@Pete-S said in What's behind the scenes of Windows network discovery?:
I'm setting up a Windows application that is multi-user but the losers made it so the installation program sets up file shares (UNC paths \server\share\folder), despite it being based on having SQL Server.
Sounds like those losers were at following the licensing. You can't publish SQL server via it's own port on Windows non Server editions, not legally. But you can publish shared SMB folders til the cows come home. So while it's crappy that it's not pulling directly from a published DB, at least it seems they are trying to follow the licensing.
-
I had a look and it looks like SMBv1 is disabled.
Wikipedia says Simple service discovery is using multicast behind the scenes. It looks like the "SSDP Discovery" service is what is running it and it's running right now.
A hosts file might be the answer. And just disable the other crap. Since it's all static IPs it should work.
I could probably disable netbios crap as well.
-
@Dashrender said in What's behind the scenes of Windows network discovery?:
You can't publish SQL server via it's own port
It's port or its own port aren't relevant. How you connect to SQL Server doesn't matter. That you are connecting to it and using its resources, does.
-
What I wonder now is how access to the shared files is granted. I have to look into that. AFAIK I didn't enter any passwords anywhere during installation.
-
@scottalanmiller said in What's behind the scenes of Windows network discovery?:
@Dashrender said in What's behind the scenes of Windows network discovery?:
You can't publish SQL server via it's own port
It's port or its own port aren't relevant. How you connect to SQL Server doesn't matter. That you are connecting to it and using its resources, does.
It's looks like the Express edition if it matters. Technically speaking one of the Windows 10 PCs acts as a server, so it could be a violation. Right now I don't care though.
-
@Pete-S said in What's behind the scenes of Windows network discovery?:
@scottalanmiller said in What's behind the scenes of Windows network discovery?:
@Dashrender said in What's behind the scenes of Windows network discovery?:
You can't publish SQL server via it's own port
It's port or its own port aren't relevant. How you connect to SQL Server doesn't matter. That you are connecting to it and using its resources, does.
It's looks like the Express edition if it matters. Technically speaking one of the Windows 10 PCs acts as a server, so it could be a violation. Right now I don't care though.
Old QuickBooks had a server too - but it was all filesharing based - so there was no violation. But they changed that at some point, and now a service is running and that's being shared, so that's the violation - as long as you don't have a service, and all the work is done solely through SMB, you're fine, legally.
-
@Pete-S said in What's behind the scenes of Windows network discovery?:
What I wonder now is how access to the shared files is granted. I have to look into that. AFAIK I didn't enter any passwords anywhere during installation.
The install could have created local accounts with or without passwords.
-
I had some success.
- I disabled netbios in the network settings.
- I disabled LLDP, IPv6 and the rest of the layer discovery stuff in the network stack and left "Client for MS Networks", "File & Printer sharing", QoS and IPv4.
- I disabled SSDP service (simple service discovery).
- I disabled Function Discovery Provider Host & Function Discovery Resource Publication services.
Then I put in the computer names & IPs in the DNS. And voila, the application works again.
Of course you can't browse the network in the file explorer but that is just a benefit IMHO.
-
Just found out with some network sniffing that Win 10 is not using DNS to find the IP for hostnames. It's using multicast queries. WTF.
First something called LLMNR (Link-local Multicast Name Resolution). If you ping xyz, it will ask for xyz.
Secondly it will use mDNS (multicast DNS). If you ping xyz, it will ask for xyz.local.
-
@Pete-S said in What's behind the scenes of Windows network discovery?:
Just found out with some network sniffing that Win 10 is not using DNS to find the IP for hostnames. It's using multicast queries. WTF.
First something called LLMNR (Link-local Multicast Name Resolution). If you ping xyz, it will ask for xyz.
Secondly it will use mDNS (multicast DNS). If you ping xyz, it will ask for xyz.local.
Well, I found out why.
If you don't have a DNS suffix in the network settings, Win10 will use multicasting to try to resolve a hostname that doesn't have a top-level domain suffix (such as xyz).
If you have a DNS suffix in your settings, it will use standard DNS.
