FiveTech Support Forums

THIS IS NOT A FWH ISSUE SPECIFICALLY BUT IT IS CRITICAL

It seems like we've had networking via the Microsoft Peer to Peer working forever ( well over 35 years ) under DOS and Windows. FWH handles everything beautifully.

In the past few weeks we have discovered that Microsoft made changes within Windows and now we are seeing ( at many installs ) that one or more workstations can no longer connect to the "server" where data files reside. Using Windows Explorer, suddenly on some computers the server, fully shared, password protection off, access granted to Everyone for Read/Write, can no longer be seen.

This is happening as Microsoft is now rolling out there 2025 Q1 updates.

I know this is NOT a FWH issue ... but many of us use this networking capability for the benefit of our clients.

I am asking if anyone has knowledge, or resources, on how to resolve this problem. It appears Microsoft has now moved to a new networking by software model and it is likely a "permissions" problem, but I can't see how, or where, to resolve the connection loss.

Any / All input will be greatly appreciated. We have to fix THIS new issue, not move to some alternative method of accessing the server ( ie. Remote Desktop isn't a solution ).

Tim

I understand your frustration with the sudden networking issues you're experiencing, especially as they coincide with Microsoft's 2025 Q1 updates. Given that you're using Microsoft Peer-to-Peer networking (likely relying on SMB - Server Message Block - for file sharing) and that this setup has worked reliably for decades with FiveWin (FWH) and your applications, it’s reasonable to suspect that recent Windows updates—particularly those related to Windows Server 2025 or client-side updates—are introducing changes affecting visibility or connectivity to the server. Let’s break this down and explore potential causes and resolutions based on the information available and common networking behavior in Windows.

Potential Cause: SMB or Permissions Changes in 2025 Q1 Updates
Microsoft has been incrementally tightening security around SMB and networking protocols over the years, and with Windows Server 2025 (released November 1, 2024) and associated client updates rolling out in Q1 2025, it’s plausible that changes to SMB configuration, default security settings, or network discovery mechanisms are at play. Here are some likely culprits:
SMB Protocol Hardening: Windows Server 2025 includes enhanced SMB security features (e.g., SMB over QUIC, hardened firewall defaults, and protections against attacks). Even if your server isn’t yet on 2025, client machines receiving updates might enforce stricter SMB requirements (e.g., requiring encryption or signing) that your server doesn’t meet.
Network Discovery or Permissions: Updates might have altered default settings for network discovery, firewall rules, or the "Everyone" share permissions, making the server invisible in Windows Explorer despite being fully shared.
Deprecation of Legacy Features: Microsoft has a history of phasing out older, less secure networking components (e.g., SMBv1 was disabled by default years ago). Peer-to-Peer networking relying on older mechanisms might be impacted if a 2025 update further restricts legacy support.

Group Policy or Update Bugs: The unexpected upgrades to Windows Server 2025 reported in November 2024 (due to third-party tools or misclassified updates) suggest that Q1 updates might introduce similar quirks, like altered permissions or connectivity settings.
Since your setup has password protection off and "Everyone" granted Read/Write access, it’s unlikely a credential issue, but rather a discovery or protocol compatibility problem triggered by the update.
Steps to Diagnose and Resolve

Here’s a structured approach to troubleshoot and potentially fix this, keeping your Peer-to-Peer setup intact:

1. Verify Server Visibility
Ping the Server: From an affected workstation, open a Command Prompt and type ping [server IP] (e.g., ping 192.168.1.100). If it responds, the server is reachable, and the issue is likely at the SMB or Explorer level.
Manual Connection: In Windows Explorer, try manually connecting to the server by typing \\servername or \\serverIP in the address bar. If it works, the server is still accessible, but network discovery is failing.

2. Check SMB Settings
Server SMB Configuration: On the server, open PowerShell as Administrator and run:
Get-SmbServerConfiguration
Look for EnableSMB1Protocol (should be False), RequireSecuritySignature, and EncryptData. If EncryptData is True and clients don’t support it, this could block access.
Client SMB Configuration: On an affected workstation, run:
Get-SmbClientConfiguration
Check if RequireSecuritySignature or EncryptData is enabled post-update. If so, and the server doesn’t match, connectivity fails.
Temporary Fix: On the server, disable encryption (if it’s safe in your environment) with:
Set-SmbServerConfiguration -EncryptData $false
Restart the "Server" service (Restart-Service LanmanServer) and test.

3. Review Network Discovery and Firewall
Network Discovery: On both server and workstation, go to Control Panel > Network and Sharing Center > Advanced sharing settings. Ensure "Turn on network discovery" and "Turn on file and printer sharing" are enabled for the current network profile (Private or Public).
Firewall Rules: Updates might have reset firewall settings. Check Windows Defender Firewall:
Allow "File and Printer Sharing (SMB-In)" on the server.
Allow outbound SMB (ports 445, 139) on the client.
Command to check: netsh advfirewall firewall show rule name="File and Printer Sharing (SMB-In)"

4. Investigate Update Impact
Installed Updates: On an affected workstation, go to Settings > Windows Update > Update history. Look for updates installed around the time the issue began (likely KB numbers from January or February 2025, e.g., KB5051987 from February 11, 2025). Cross-reference with Microsoft’s update catalog or release notes for networking changes.
Server Updates: If the server received updates, check its update history too. Windows Server 2025’s February 11, 2025, update (KB5051987) resolved some networking issues (e.g., iSCSI boot errors), but others might persist.

5. Permissions and Sharing
Reapply Share Permissions: On the server, right-click the shared folder, go to Properties > Sharing > Advanced Sharing, and re-verify "Share this folder" with "Everyone" permissions. Then, under Security tab, ensure "Everyone" has Full Control.
Check Effective Permissions: Updates might enforce stricter NTFS permissions over share permissions. Use the "Effective Access" tool in the Security tab to confirm "Everyone" still has access.

6. Roll Back or Test Updates
Uninstall Updates: If a specific update correlates with the issue, uninstall it from an affected workstation via Settings > Windows Update > Update history > Uninstall updates. Test connectivity afterward.
Pause Updates: Temporarily pause updates (Settings > Windows Update > Pause for 1 week) to prevent further changes while troubleshooting.

7. Resources and Further Checks
Microsoft Documentation: Check "Resolved issues in Windows Server 2025" or "Windows Server 2025 update history" on Microsoft Learn/Support for notes on networking fixes (e.g., February 11, 2025, KB5051987 resolved some issues, but new ones could emerge).
Event Viewer: On the workstation, open Event Viewer (eventvwr.msc), go to Windows Logs > System, and filter for errors related to "Server," "SMB," or "Network" around the time of failure.
X Search: I can search X posts for real-time reports of similar issues. Would you like me to do this?

Hypothesis and Recommendation
Given the timing with 2025 Q1 updates and your description, I suspect a client-side update (e.g., Windows 10/11 receiving January/February 2025 patches) is enforcing SMB encryption or signing that your server (possibly still on an older version like Windows Server 2019/2022) doesn’t support by default. Alternatively, network discovery might be disrupted by tightened firewall rules or a bug in the update rollout.

Start with steps 1-3: verify reachability, check SMB settings, and ensure discovery/firewall are intact. If that doesn’t resolve it, pinpoint the update (step 4) and consider rolling back or adjusting server settings to match client expectations (e.g., enabling SMB signing if required).

Community Input
Since you’re asking for knowledge from others, I’d encourage you to share specifics (e.g., server OS version, client OS version, exact update KB installed) to get tailored advice. I don’t have direct FiveWin community insights here, but the issue aligns with broader Windows networking changes, not FWH itself.

Check SMB Protocol Settings
Microsoft has been deprecating older versions of the SMB (Server Message Block) protocol, which could be causing connectivity issues.

Ensure that SMBv1 is disabled (for security reasons) but that SMBv2 and SMBv3 are enabled.

Open PowerShell or Command Prompt as Administrator and run:

shell
Copy
Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol
If SMBv2 is disabled, enable it with:

shell
Copy
Set-SmbServerConfiguration -EnableSMB2Protocol $true
Verify that all machines are using compatible SMB versions.

Antonio,

These computers are using Windows 11 as Servers for the network, not Windows Server. The response, therefore, is not engaging that limitation.

Otto,

I have also noticed Remote Desktop is losing the connection after a period of inactivity. My main computer is an Apple Mini ( M4 ), and I use RD to access a Beeline Windows 11 computer and an Ace Magician Windows 11 box. The first is my primary Windows programming computer and the second is a Celeron processor running Advantage Database Server ( final release ). It allows me to work on all 3 computers using my 27" Apple Studio display. The super strong resolution is easier on my aging eyes.

I will run the check on SMB Protocol settings. Thanks.

Tim

Tim:

Tuve un problema similar (Conectar Windows 11 a otro Windows 7)

En mi caso se solucionó de esta manera:

1) Win + R -> gpedit.msc

2) Configuración del equipo -> Plantillas administrativas -> Red ->Estación de trabajo LANMAN

3) Activar Habilitar el acceso de invitados no seguros

No se cual es su equivalente en ingles, pero seguramente lo encontraras facilmente.

Espero que sirva

My thanks for the responses. They were all helpful and I also did more searches on AI.

The problem was created by Microsoft on their latest updates as they attempted to improve security. However, they did not provide any helpful documentation so it has created problems for many people. I have talked with several IT techs who have seen the problem with many software packages who need peer to peer networking.

The post by cmsoft points to the very best First Step. If that does not work, then the other steps outlined by Antonio's post will need to be tried. Using these, we have now managed to get everyone working again.

Tim

Me alegro mucho que todo vuelva a funcionar Tim...

Hi guys, I'm having problems with a client that uses ads12, on the server everything works, but the computers with windows 11 that have updated are giving error 6420...

Regards.

It may be the same problem. On your workstations, follow the steps above.

Also, make sure PORT 6262 is open ( UDP ) on the server. I open it for outgoing and incoming.

In addition, make sure the Server has a STATIC IP, then create an ads.ini file on the workstations specifying that IP. There is info in the ADS docs on how to setup that file ... it's quite simple.

Tim

TimStone wrote: It may be the same problem. On your workstations, follow the steps above.