1

I have a requirement to disable the Windows DNS Cache on a new Windows Server 2022 RDS VM.

Trying to access a SMB share hosted on a Windows Server 2022 file server, all my servers are joined to a AD domain and on the same network with a permit any to any on same subnet firewall rule.

When I disable the DNS cache on 2022 RDS server, I am unable to access any SMB shares. The share works perfectly fine when the DNS cache is enabled. SMB error

This isn't a network, firewall or permissions issue as all the required ports are open and security permissions setup. File and printer sharing is enabled on both sides, on the Server 2022 file server I tried enabling the SMB-QUIC-In and iWARP-in built in Windows firewall rules so that all file and printer sharing built in inbound rules are enabled on the file server.

From the Server 2022 RDS server I can successfully resolve and ping the hostname of the file server with the cache disabled, successfully ping the IP of the file server too just can't seem to establish SMB session.

When I disabled the DNS cache on the old Server 2019 server years ago SMB share access worked perfectly fine and continues to work with it disabled to this day.

Running a packet capture from the file server side and the RDS server side with the cache disabled - there is no traffic generated when clicking into the mapped SMB share on file explorer.

Does anyone know why SMB shares stop working with DNS cache disabled on Server 2022 but this works on Server 2019?

Improve this question
14
  • 1
    Run a capture when you use the following from the command prompt: dir \\n.n.n.n\sharename
    – Greg Askew
    Nov 18 at 15:15
  • Same as before 'the network path was not found' - nothing on either side for the packet capture The same result with the hostname or IP address, I am open to any further suggestions, thanks
    – tezx
    Nov 18 at 15:29
  • What does both nslookup SMB.server.host.name and nslookup IP from the SMB client show?
    – Andrew Henle
    Nov 18 at 15:33
  • 1
    nslookup with hostname resolves A record to the correct internal IP nslookup for the IP resolves back to the hostname Thanks Andrew - I did find the article whilst researching this issue but I'm mapping the share with the FQDN of the file server not a CNAME Is there anything else I could try?
    – tezx
    Nov 18 at 15:42
  • 1
    I doubt any of those things will address the inability to access the share using the IP address. At a minimum, there should at least be an arp request. Talk about the number of policy settings are present that are different from the default?
    – Greg Askew
    Nov 18 at 16:42

0

Reset to default

You must log in to answer this question.