Some scanners have stopped sending files to shared folders on Windows 11 PCs. From another computer, the affected shares work by FQDN but time out by IP. The FQDN resolves to the same IP, and ping works.
Some scanner destinations already use the FQDN, so the IP issue may not explain the scan failures. What should I check next?
Authentication is a good place to look for the IP versus FQDN difference. A Windows client normally uses Kerberos for a suitable hostname, while an IP address commonly leads to NTLM instead. If NTLM is restricted, those two tests can behave differently.
Check the NTLM operational logs and security policy on the affected PCs, then compare them with a working PC. You can configure Kerberos to use IP addresses in some environments, but I would use the FQDN rather than start registering IP-based service principal names.
I would treat the scanner failure and the IP browsing failure as related clues, not necessarily the same fault. Since some scanner destinations already use the FQDN, changing the address alone may not fix those.
Compare a working and failing destination for Windows updates, SMB signing requirements, NTLM restrictions, and share permissions for the scan account. Check the scanner's SMB authentication settings too. A signing or authentication mismatch is possible, but the timeout alone doesn't identify which one.
Ping only tells you the host responds to ICMP. Test TCP port 445 from the computer doing the browsing, using both the IP and the FQDN, and compare the results with a working destination. That helps separate a connection problem from a failure after SMB connects.
Also check the Windows event logs around a failed scan. If the scanner only reports a generic job failure, the destination PC may give you a more useful authentication or SMB error.
Answers are reviewed before publication.
h913~papertrail_2:
The scanner is configured for NTLM v1 or v2, so a successful Kerberos connection from a Windows computer would not prove the scanner can authenticate by FQDN.