Windows Can’t See Other PCs: Make Network Discovery Actually Work

February 7, 2026 • February 7, 2026 • Read: 20 min • Views: 0

Was this helpful?

It’s always the same scene: you open File Explorer, click Network, and it’s a ghost town. Meanwhile you can ping the other PC, browse the internet, and Teams will happily eat your CPU like it’s being paid by the cycle. So why can’t Windows “see” a box that’s clearly right there?

Because “Network Discovery” is not one thing. It’s a pile of services, firewall rules, name resolution paths, legacy SMB browsing behavior, and whatever your router thinks is a good idea today. We’re going to make it boring again—the good kind of boring.

What “Network Discovery” really is (and why it lies)

When users say “Windows can’t see other PCs,” they usually mean one of these:

Explorer’s Network view is empty or missing specific machines.
Mapping a drive by name fails (e.g., \\FILES01\Share).
Access by IP works (e.g., \\192.168.1.50\Share) but names don’t.
Ping works but SMB doesn’t.
SMB works but the computer doesn’t show up in browse lists.

Those are different failure modes. Treat them differently.

Here’s the uncomfortable truth: the Network folder in File Explorer is not a reliable monitoring system. It’s a UI fed by discovery mechanisms that can be blocked by network profiles, firewalls, service state, or modern security posture. It can be wrong even when file sharing works fine.

So the goal isn’t “make icons appear.” The goal is:

Hostnames resolve consistently.
SMB ports are reachable on the right network.
Shares are accessible with correct auth.
Discovery works where you actually want it (usually Private LAN), and is blocked everywhere else (Public/Wi‑Fi at airports, etc.).

One quote worth taping to your monitor: “Hope is not a strategy.” — Gordon R. Sullivan. (If you’re running production systems, you already learned this the expensive way.)

Fast diagnosis playbook (check this first)

This is the “get me unstuck in five minutes” sequence. Run it on the PC that can’t see others and, if needed, on the target PC that should be visible.

1) Confirm you’re on the right network profile

If it’s set to Public, discovery is supposed to be crippled. Fix that before you touch anything else.

2) Test name resolution vs. reachability

Try ping TARGET and ping TARGET_IP.
Try Test-NetConnection TARGET -Port 445 and by IP.

If IP works and name fails: it’s DNS/LLMNR/mDNS/NetBIOS, not “sharing.”

3) Check firewall rule groups and network discovery services

Windows can happily say “Network discovery is on” while the firewall rules are disabled, or while the Function Discovery services are stopped.

4) Ignore Explorer and test SMB directly

Open \\TARGET\Share. If it works, you’ve got a browse/discovery problem, not a file-sharing problem.

5) If this is a corporate domain, assume GPO

Especially if it “worked yesterday.” Group Policy can revert services, firewall rules, and name resolution behavior. Don’t fight it manually—fix the policy.

Interesting facts & quick history (you’ll stop blaming the wrong thing)

Some context helps because Windows networking is a museum where the exhibits are still plugged in.

The “browse list” tradition comes from NetBIOS/Computer Browser, a legacy system that used broadcast elections to decide who lists machines. That’s why it was flaky on multi-subnet networks.
SMBv1 used to be tied to old browsing behavior. When SMBv1 was disabled broadly for security reasons, many people interpreted the resulting emptier Network view as “the network broke.”
WS-Discovery (WSD) became a more modern discovery method for devices and some Windows discovery scenarios, but it depends heavily on firewall and multicast behavior.
LLMNR exists because DNS isn’t always present on small networks. It’s handy, and also a common target for credential interception attacks in hostile environments.
mDNS is no longer “just for Apple”. Windows supports mDNS in modern builds, and it shows up in mixed-device homes more than most people realize.
Network profiles (Public/Private/Domain) were introduced to reduce “I joined café Wi‑Fi and exposed my laptop shares to strangers” incidents. Discovery failures are often a feature, not a bug.
SMB over TCP/445 replaced the old NetBIOS over TCP/139 path for most modern Windows environments, but some tooling and habits still poke at the older stack.
Explorer’s Network view is intentionally conservative in modern Windows. It’s not a canonical directory; it’s a convenience UI that prioritizes security and reduced noise.

The core principles: profile, firewall, services, names, SMB

1) Network profile decides the default security stance

If your NIC is set to Public, Windows will block or limit the very traffic used for discovery and file sharing. You can toggle “Network discovery” in Settings all day and still get inconsistent results if the underlying profile is wrong.

2) Firewall rules matter more than the Settings app

Windows has firewall rule groups like Network Discovery and File and Printer Sharing. If those are disabled, discovery won’t work. If they’re enabled on the wrong profile, you can accidentally advertise your machine on networks where you really shouldn’t.

3) Services are the engine room

Two services are frequent culprits:

Function Discovery Provider Host (FDPHost)
Function Discovery Resource Publication (FDResPub)

If these are stopped/disabled, your machine may not publish itself, and you may not discover others reliably.

4) Name resolution is a multi-headed beast

When you type \\TARGET, Windows may resolve that name using:

DNS (best option in managed networks)
LLMNR
mDNS
NetBIOS name service (legacy)
Hosts file (manual override)

Different environments disable different ones (often for good security reasons). You need to know which one you rely on.

5) SMB sharing can work even when discovery is broken

Discovery is about finding things. SMB is about connecting. Don’t confuse the two. If you can access \\IP\Share, your share is fine. You’re looking at a naming or browsing issue.

Joke #1: Windows Network Discovery is like office gossip: fast, unreliable, and it stops the moment Legal shows up (aka the firewall).

Practical tasks with commands: diagnose and decide

These are real tasks you can run. Each includes: a command, what the output means, and what decision you make next. Run them in an elevated PowerShell when possible.

Task 1: Check the network profile (Public vs Private)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | Format-List Name,InterfaceAlias,NetworkCategory,IPv4Connectivity"
Name            : Corp-WiFi
InterfaceAlias  : Wi-Fi
NetworkCategory : Public
IPv4Connectivity: Internet

Meaning: NetworkCategory : Public explains why discovery and SMB might be blocked by default.

Decision: If this is your trusted LAN, switch to Private. If it’s truly untrusted, stop expecting discovery to work and use VPN + DNS instead.

Task 2: Switch a network to Private (only if appropriate)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetConnectionProfile -InterfaceAlias 'Wi-Fi' -NetworkCategory Private; Get-NetConnectionProfile -InterfaceAlias 'Wi-Fi' | Select-Object InterfaceAlias,NetworkCategory"
InterfaceAlias NetworkCategory
-------------- ---------------
Wi-Fi          Private

Meaning: The NIC is now Private, so Windows will allow discovery rules (if enabled) on that profile.

Decision: Re-test discovery/SMB. If it works now, you were fighting policy, not packet loss.

Task 3: Confirm basic IP configuration

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPConfiguration | Format-List InterfaceAlias,IPv4Address,IPv4DefaultGateway,DnsServer"
InterfaceAlias      : Ethernet
IPv4Address         : {192.168.10.21}
IPv4DefaultGateway  : {192.168.10.1}
DnsServer           : {192.168.10.10}

Meaning: You’ve got an IP, gateway, and DNS. Good. If DNS is a random router IP, name resolution may be weak.

Decision: If DNS points somewhere wrong (or empty), fix DHCP/DNS before doing anything fancy.

Task 4: Test name resolution (DNS path)

cr0x@server:~$ powershell -NoProfile -Command "Resolve-DnsName FILES01 -ErrorAction SilentlyContinue | Select-Object Name,IPAddress"
Name   IPAddress
----   ---------
FILES01 192.168.10.50

Meaning: DNS can resolve the hostname. That’s ideal.

Decision: If this fails, you either need working DNS, or you’ll fall back to LLMNR/NetBIOS/mDNS (which might be disabled). Decide whether to fix DNS (recommended) or accept peer-to-peer hacks.

Task 5: Test reachability to SMB port 445 (by name and by IP)

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection FILES01 -Port 445 | Select-Object ComputerName,RemoteAddress,TcpTestSucceeded"
ComputerName     RemoteAddress   TcpTestSucceeded
------------     -------------   ---------------
FILES01          192.168.10.50   True

Meaning: TCP/445 is reachable. Firewall and routing likely permit SMB.

Decision: If False, stop. Fix firewall rules on the target, VLAN isolation, or router “guest network” settings. Discovery won’t fix blocked SMB.

Task 6: If name fails but IP works, prove it

cr0x@server:~$ powershell -NoProfile -Command "Test-NetConnection 192.168.10.50 -Port 445 | Select-Object RemoteAddress,TcpTestSucceeded"
RemoteAddress   TcpTestSucceeded
-------------   ---------------
192.168.10.50   True

Meaning: The service is reachable; your issue is name resolution or identity (SPNs/credentials), not connectivity.

Decision: Fix DNS or use a hosts entry as a temporary band-aid. Don’t keep teaching users to type IPs forever.

Task 7: Check required discovery services

cr0x@server:~$ powershell -NoProfile -Command "Get-Service FDResPub,FDPHost,SSDPSRV,upnphost | Select-Object Name,Status,StartType"
Name     Status  StartType
----     ------  ---------
FDResPub Stopped Manual
FDPHost  Running Automatic
SSDPSRV  Stopped Manual
upnphost Stopped Manual

Meaning: If FDResPub is stopped, your machine may not publish itself for discovery. Some environments don’t need SSDP/UPnP; don’t enable them blindly.

Decision: On a small LAN where you want discovery, set FDResPub to Automatic (Delayed Start) and start it. In a locked-down corporate network, check policy first.

Task 8: Start and set Function Discovery Resource Publication properly

cr0x@server:~$ powershell -NoProfile -Command "Set-Service FDResPub -StartupType Automatic; Start-Service FDResPub; Get-Service FDResPub | Select-Object Name,Status,StartType"
Name     Status  StartType
----     ------  ---------
FDResPub Running Automatic

Meaning: The service is running and will persist across reboots.

Decision: Re-check the Network view after a minute. If still empty, the firewall or profile is still wrong—or the network blocks multicast.

Task 9: Verify firewall rule groups are enabled for Private profile

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -DisplayGroup 'Network Discovery' | Select-Object -First 5 DisplayName,Enabled,Profile | Format-Table -Auto"
DisplayName                                              Enabled Profile
-----------                                              ------- -------
Network Discovery (NB-Name-In)                            True    Private
Network Discovery (NB-Datagram-In)                        True    Private
Network Discovery (NB-Session-In)                         True    Private
Network Discovery (SSDP-In)                               True    Private
Network Discovery (UPnP-In)                               True    Private

Meaning: Discovery rules are enabled for Private. Good. If they’re disabled, Windows can’t “see” devices using those methods.

Decision: Enable the group for Private if you want discovery; keep it off for Public.

Task 10: Enable the firewall rule groups (Network Discovery + File and Printer Sharing)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetFirewallRule -DisplayGroup 'Network Discovery' -Enabled True; Set-NetFirewallRule -DisplayGroup 'File and Printer Sharing' -Enabled True; 'done'"
done

Meaning: This flips a large set of inbound rules on. That’s why you only do it on Private/Domain networks you trust.

Decision: If enabling these “fixes everything,” you’ve identified the bottleneck: firewall configuration, likely managed by GPO in business environments.

Task 11: Confirm SMB server is enabled on the target machine

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol,EnableSMB2Protocol,RejectUnencryptedAccess"
EnableSMB1Protocol EnableSMB2Protocol RejectUnencryptedAccess
------------------ ------------------ ------------------------
False              True               True

Meaning: SMB2 is enabled (good). SMB1 is disabled (also good, usually). Some truly ancient devices require SMB1; treat that as a containment problem, not a feature request.

Decision: Don’t turn on SMB1 unless you’re isolating that device/network and you understand the risk. Prefer upgrading the device or using a different protocol.

Task 12: List shares and validate you’re not chasing a non-existent path

cr0x@server:~$ powershell -NoProfile -Command "Get-SmbShare | Select-Object Name,Path,Description | Format-Table -Auto"
Name   Path                 Description
----   ----                 -----------
IPC$                        Remote IPC
Public C:\Shares\Public     Common drop

Meaning: The share exists. If users can’t access it, that’s permissions or auth—not discovery.

Decision: Confirm share permissions and NTFS ACLs; confirm the user is authenticating with the expected identity.

Task 13: Verify you can enumerate the target via SMB (client-side)

cr0x@server:~$ powershell -NoProfile -Command "net view \\FILES01"
Shared resources at \\FILES01

Share name  Type  Used as  Comment
----------  ----  -------  -------
Public      Disk           Common drop
The command completed successfully.

Meaning: SMB negotiation, auth, and share enumeration worked by name. If Explorer’s Network view still doesn’t show it, ignore Explorer. You’re operational.

Decision: Teach users to pin/mount by UNC path or map drives via GPO/script. Don’t rely on browsing.

Task 14: Check credential/session state if access is weird

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use'"
New connections will be remembered.

Status       Local     Remote                    Network
-------------------------------------------------------------------------------
OK                     \\FILES01\Public          Microsoft Windows Network
The command completed successfully.

Meaning: There’s an existing session. If the wrong creds were used earlier, Windows will reuse them and keep failing in confusing ways.

Decision: Delete the session and reconnect with the right identity if needed.

Task 15: Clear SMB connections (use with care)

cr0x@server:~$ powershell -NoProfile -Command "cmd /c 'net use \\FILES01\Public /delete'"
\\FILES01\Public was deleted successfully.

Meaning: The cached connection is gone.

Decision: Retry access. If it now works, your “network discovery problem” was actually an auth/session problem.

Task 16: Check Windows features/services that often break discovery in “hardened” images

cr0x@server:~$ powershell -NoProfile -Command "Get-Service LanmanServer,LanmanWorkstation,Browser | Select-Object Name,Status,StartType"
Name            Status  StartType
----            ------  ---------
LanmanServer    Running Automatic
LanmanWorkstation Running Automatic
Browser         Stopped Disabled

Meaning: Server and Workstation services are running (required for SMB). The old Computer Browser is disabled (normal on modern Windows).

Decision: Don’t try to resurrect the Browser service as your fix. Solve name resolution and SMB reachability instead.

Task 17: Confirm your machine is actually listening on SMB (target-side)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetTCPConnection -LocalPort 445 -State Listen | Select-Object -First 5 LocalAddress,LocalPort,State"
LocalAddress LocalPort State
------------ --------- -----
0.0.0.0      445       Listen
::           445       Listen

Meaning: SMB is listening on IPv4 and IPv6. If nothing is listening, file sharing won’t work regardless of discovery.

Decision: If not listening, check LanmanServer service and server configuration; verify file sharing is enabled and not blocked by endpoint security.

Task 18: Check event logs for discovery publication failures

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 20 | Where-Object {$_.ProviderName -match 'FDResPub|FDPHost'} | Select-Object -First 3 TimeCreated,ProviderName,Id,Message | Format-List"
TimeCreated  : 2/5/2026 9:10:22 AM
ProviderName : FDResPub
Id           : 7023
Message      : The Function Discovery Resource Publication service terminated with the following error: Access is denied.

Meaning: The service is failing; “Access is denied” often points to permissions, hardening, or endpoint security interference.

Decision: Stop toggling settings. Fix the service failure (image hardening baseline, GPO, or security product policy) or accept that discovery is intentionally disabled.

Three corporate mini-stories from the trenches

Mini-story #1: The incident caused by a wrong assumption

We had a small office site with a file server, a handful of Windows 10 machines, and a “simple” requirement: everyone should see the server in File Explorer under Network. A ticket came in: “Server disappeared. Must be down.” Users were panicking. Management was asking for an ETA.

The server was fine. SMB by IP worked immediately. Even SMB by hostname worked from PowerShell. Only the Network view was empty, and that’s what users were trained to trust.

The wrong assumption was that the Network view is authoritative. It’s not. It’s an opportunistic discovery UI. Once we explained “connect by UNC path; don’t browse,” the urgency dropped. But we still had to fix the perception problem.

The actual cause was that a security baseline update flipped the NIC profile to Public after a Wi‑Fi driver reinstall. That one toggle silently disabled the discovery firewall rules. The system didn’t break; it just stopped advertising itself.

We fixed the profile via policy, ensured discovery rules were enabled only on Domain/Private, and published a desktop shortcut to \\FILES01\Public. The outage ended the moment we stopped treating UI behavior as service health.

Mini-story #2: The “optimization” that backfired

A different environment tried to “clean up network noise.” Someone read that LLMNR and NetBIOS are insecure (they can be), and pushed a hardening GPO: disable LLMNR, disable NetBIOS over TCP/IP, and aggressively restrict inbound rules. The intention was reasonable: reduce attack surface.

Two weeks later the helpdesk queue filled with “can’t find computer,” “can’t map drive,” and “printer disappeared.” The kicker: DNS wasn’t consistently configured for the workstations at smaller sites. They had been leaning on broadcast/multicast name resolution without realizing it.

So the “optimization” removed the fallback mechanisms without providing the replacement. The network didn’t get more secure; it got more chaotic. Users started sharing IP addresses in chats like they were trading baseball cards.

The fix wasn’t “turn everything back on.” The fix was to finish the job: make DNS reliable (including dynamic updates where appropriate), ensure clients use the right DNS servers via DHCP, and document the supported connection method (hostnames, not browsing). Then we could keep LLMNR off for most networks and still have a predictable experience.

Security improvements that break basic operations don’t get adopted—they get quietly bypassed. Build the runway before you ask pilots to land.

Mini-story #3: The boring, correct practice that saved the day

A finance department had a small “files on a desktop” setup (yes, still) that we were migrating to a proper server. We knew discovery would be fragile because the office had segmented Wi‑Fi, multiple VLANs, and a router that treated multicast like a personal insult.

So we didn’t aim for browsing at all. We did three boring things: stable DNS records, a single UNC path that never changes, and mapped drives deployed via policy. We also made sure the Windows Firewall rule groups were explicitly configured for Domain/Private profiles instead of “whatever the default is.”

Months later, someone replaced the router. Discovery got weird on several subnets. Explorer’s Network view became a haunted house again. But nobody noticed, because the operational path—drive mapping and direct UNC access—kept working. Tickets stayed low. The migration looked “magically smooth.”

That’s not magic. That’s choosing deterministic systems over vibes. Browsing is vibes.

Common mistakes: symptom → root cause → fix

This is where most time gets burned. Don’t.

1) Symptom: Network folder is empty, but internet works

Root cause: Network profile is Public, or discovery firewall rules are disabled for the active profile.

Fix: Set the network to Private (if trusted). Enable “Network Discovery” firewall group for Private. Confirm FDResPub is running.

2) Symptom: You can access `\\IP\Share` but not `\\HOST\Share`

Root cause: Name resolution failure (DNS missing/wrong; LLMNR/NetBIOS disabled; multicast blocked).

Fix: Make DNS authoritative (preferred). For temporary triage, add a hosts file entry or use IP while you fix DHCP/DNS.

3) Symptom: Ping works, but SMB fails (port 445 closed)

Root cause: Firewall on the target blocks inbound SMB, or the network is segmented (guest Wi‑Fi isolation, VLAN ACLs).

Fix: Enable File and Printer Sharing rules on Private/Domain. Fix network isolation. Don’t “fix discovery” when SMB is blocked.

4) Symptom: One PC can see others, but others can’t see it

Root cause: The “invisible” PC isn’t publishing (FDResPub stopped/disabled), or its firewall blocks inbound discovery traffic.

Fix: Start/enable FDResPub. Enable Network Discovery rules on the publishing PC for Private/Domain.

5) Symptom: It worked until a Windows update or image refresh

Root cause: Services reset to Manual/Disabled, firewall rules reverted, NIC profile changed, or a security baseline applied.

Fix: Make desired state enforceable (GPO/Intune). Stop relying on local tweaks that updates can undo.

6) Symptom: Domain environment, but discovery is flaky across subnets

Root cause: Discovery protocols often rely on broadcast/multicast and don’t cross routers cleanly.

Fix: Use DNS + direct UNC paths. If you need directory-like behavior, use AD, DFS namespaces, or managed inventory—not browsing.

7) Symptom: “You don’t have permission” or repeated credential prompts

Root cause: Credential mismatch, cached sessions, NTLM restrictions, or share/NTFS ACL mismatch.

Fix: Clear existing net use sessions and reconnect. Validate share permissions and NTFS ACLs. Align auth policy with reality.

8) Symptom: New Windows 11 PC can’t access an old NAS

Root cause: The NAS requires SMB1 or weak auth; modern Windows blocks it by default.

Fix: Upgrade NAS firmware/config to SMB2/3. If you must enable SMB1, isolate that device/network and accept the risk explicitly.

Joke #2: Turning on SMB1 in 2026 to “fix discovery” is like fixing a leaky faucet by installing a fire hose.

Checklists / step-by-step plan (make it work reliably)

Checklist A: Home or small office (workgroup) where you actually want browsing

Put devices on the same LAN (not guest Wi‑Fi, not isolated SSIDs). If your router has “AP isolation” or “client isolation,” turn it off for the trusted network.
Set the network profile to Private on each Windows PC that should share/discover.
Enable Network Discovery + File and Printer Sharing (firewall rule groups) for Private profile.
Ensure FDResPub and FDPHost run (Automatic is fine for a home LAN).
Confirm SMB works directly: access \\HOST\Share and \\IP\Share.
Fix name resolution:
- Best: your router provides DNS entries (some do), or you run a small DNS server.
- Acceptable: hosts file entries for a couple machines.
- Avoid: relying on “whatever Windows discovers today.”
Make access user-friendly: create shortcuts or map drives; teach users to use them instead of browsing.

Checklist B: Corporate LAN (domain) where reliability matters more than icons

Decide the supported UX: direct UNC paths, mapped drives, DFS namespaces, or SharePoint/OneDrive. Pick one and standardize.
Make DNS correct and complete: clients should use corporate DNS (via DHCP), and servers should have stable names.
Enforce Windows Firewall policy:
- Enable File and Printer Sharing inbound only on Domain profile (and sometimes Private for managed Wi‑Fi).
- Keep it off on Public, always.
Set required services explicitly via GPO/Intune. Don’t depend on defaults that images and updates change.
Don’t depend on broadcast/multicast discovery across subnets. It’s fragile and often blocked for good reasons.
Monitor SMB reachability (port 445) and authentication failures. That’s your real service health, not Explorer.

Checklist C: When you need to prove where the failure is (names vs ports vs auth)

By name: Resolve-DnsName, then Test-NetConnection -Port 445.
By IP: Test-NetConnection IP -Port 445.
By SMB enumeration: net view \\HOST.
By direct path: open \\HOST\Share.
If auth fails: check net use sessions; clear and reconnect; validate ACLs.

FAQ

1) Why can I ping a PC but not see it in Network?

Ping is ICMP. Discovery is a mix of multicast/broadcast and service publication. Windows can block discovery while still allowing ping (or vice versa). Treat them as separate tests.

2) If the Network folder is empty, does that mean file sharing is broken?

No. The Network folder is not a source of truth. Test SMB directly with \\HOST\Share or Test-NetConnection -Port 445.

3) What services are actually required for Windows discovery?

Common ones: FDResPub and FDPHost. SSDP/UPnP can play a role for some discovery scenarios, but enabling them everywhere is not automatically “best.”

4) Should I enable SMB1 to fix this?

Almost never. SMB1 is a legacy protocol with a long history of security problems. If a device requires it, isolate that device/network and plan a replacement.

5) Why does `\\192.168.x.x\share` work but `\\hostname\share` fails?

Because name resolution is failing. Fix DNS (best), or temporarily use a hosts file entry. Disabling LLMNR/NetBIOS without DNS readiness is a classic self-own.

6) Why do some PCs appear and disappear randomly?

Discovery relies on periodic announcements and protocols that don’t always survive sleep, Wi‑Fi roaming, VPN clients, driver resets, or multicast filtering. Use mapped drives and DNS-based access for stability.

7) I’m on guest Wi‑Fi. Can I make discovery work anyway?

Usually no, and that’s intentional. Guest networks often isolate clients from each other. If you need access, use a proper trusted SSID/VLAN or a VPN to a network where DNS and SMB are supported.

8) How do I know if Windows Firewall is the issue?

Check whether port 445 is reachable (Test-NetConnection -Port 445) and whether the firewall rule groups for Network Discovery and File and Printer Sharing are enabled for the active profile.

9) Why does it work on Ethernet but not Wi‑Fi?

Different profiles (Private vs Public), different firewall posture, or Wi‑Fi client isolation/multicast filtering on the access point. Also, some endpoint security products apply stricter policy to Wi‑Fi.

10) What’s the “best practice” fix in a business environment?

Stop depending on browsing. Use DNS + direct UNC paths, mapped drives via policy, and explicit firewall/service configuration. Make it deterministic.

Next steps (keep it working)

If you want this to stay fixed, do the operational thing, not the hopeful thing:

Standardize access paths (UNC, mapped drives, or DFS) so users don’t depend on the Network view.
Make DNS reliable. If hostnames matter, DNS has to be correct—period.
Enforce policy (GPO/Intune) for:
- Network profile expectations (where possible)
- Firewall rule groups on Domain/Private
- FDResPub/FDPHost service startup
Test what matters: port 445 reachability and actual share access. Explorer is a nice-to-have.
Be explicit about security stance: discovery and sharing on trusted networks only; locked down everywhere else.

The win isn’t making the Network folder pretty. The win is making file access predictable—today, after the next Windows update, and during the next router replacement when everyone swears “nothing changed.”