No Access to Fileshare after installation of new DC

Question

I have a customer who has a Windows 2012R2 domain controller installed.

I have had synchronization problems for a long time and have therefore installed a Windows 2022 domain controller.

I have moved FSMO to the new DC.

The customer has a fileshare in Azure where data is located.

Problem:

Every time I correct the DNS setup on the customer's network so that DNS points to the new DC, they cannot access the fileshare

I need a hint :-)

Answer 1

Hi Johnny Broe,

Thanks for reaching out to Microsoft Q&A.

This sounds like a potential issue with DNS resolution or authentication against the new domain controller. Here’s a structured approach to help you troubleshoot this:

1. DNS and Name Resolution

• Verify DNS Forwarders: Ensure that the new Windows 2022 DC has the correct DNS forwarders and settings to resolve Azure fileshare URLs.
• DNS Zone Replication: Make sure that the DNS zones are correctly replicating between the old and new DCs. Sometimes stale records from the old DC can create inconsistencies.
• Flush DNS Cache: On both the DC and client machines, try clearing the DNS cache using ipconfig /flushdns to ensure they are resolving names correctly from the updated DC.

2. Network Share Authentication

• Review SMB Authentication Levels: Windows Server 2022 might have stricter security requirements for SMB connections than 2012R2. Check the authentication level and permissions on the Azure fileshare to ensure compatibility.
• Kerberos Ticket Caching: Sometimes, clients cache Kerberos tickets tied to the old DC. You can clear cached tickets on client machines using the klist purge command and retry the connection to the fileshare.
• NTLM Fallback: Ensure that NTLM fallback is allowed temporarily if required. Windows Server 2022 defaults to stricter security policies that might prevent older clients from authenticating.

3. Check Fileshare DNS Resolution

• Since the fileshare is hosted in Azure, confirm that it can be resolved and accessed from the new DC. Test this by using the fileshare's FQDN directly from the new DC and other network clients.
• Test Connectivity: Try using the direct IP address (if available) of the fileshare for troubleshooting to see if the issue is indeed DNS-related.

4. Logs and Event Viewer

• DC Logs: Check the Event Viewer on the new domain controller for any errors related to authentication or DNS.
• Client Logs: Similarly, review the logs on client machines for SMB errors or DNS resolution errors. Look for Event ID 5719 (netlogon), which might indicate domain controller connectivity issues.

5. Revert and Test in Stages

• After confirming the DNS and network configurations, make changes in stages. First, set up the DNS on only a few client machines to point to the new DC and test access to the fileshare.

I have listed out all the probabilities, this approach should help pinpoint where the issue lies, whether it’s with DNS configuration, authentication, or network settings between the new domain controller and Azure fileshare.

HTH!

Please feel free to click the 'Upvote' (Thumbs-up) button and 'Accept as Answer'. This helps the community by allowing others with similar queries to easily find the solution.