Weird issue accessing netlogon

It seems like you're encountering intermittent issues when accessing the Netlogon share, where access works either for the short domain name (\\domain\netlogon) or the fully qualified domain name (FQDN, \\domain.fqdn.gov.uk\netlogon), but not consistently. The fact that this behavior is occurring both on the internal network and over VPN suggests that there may be network or DNS-related issues.

Here are a few potential areas to investigate that may resolve this issue:

1. DNS Resolution Issues

The issue with accessing \\domain\netlogon versus \\domain.fqdn.gov.uk\netlogon likely points to DNS resolution inconsistencies. When you access resources using the short name, your client machine might be resolving it differently than when you use the FQDN.

Solution:

• Check DNS Configuration: Ensure that the DNS servers configured on the client machines (both local and via VPN) are correctly resolving the domain and the full FQDN. When using short names, DNS can sometimes resolve to an internal domain controller, but using the FQDN may involve a different DNS lookup.
• Ensure Proper DNS Records: Make sure that both the short and fully qualified domain names have appropriate DNS records in the internal DNS servers, and that they resolve correctly across both internal and VPN networks.
• DNS Suffix Search Order: Verify the DNS suffix search order on the client machines. This can be configured via Group Policy (under Computer Configuration > Administrative Templates > Network > DNS Client). If your machines are not searching the correct suffixes, it could lead to intermittent failures when trying to resolve the FQDN.

You can check DNS resolution manually using:

nslookup domain
nslookup domain.fqdn.gov.uk

Netlogon Service Configuration

The Netlogon service relies on proper DNS and Active Directory connectivity, and any issues with name resolution could prevent the service from functioning properly. If there’s an intermittent issue with the Netlogon service when trying to access resources by FQDN, it's worth checking the service configuration.

Solution:

• Check the Netlogon Service: Ensure the Netlogon service is running on the domain controllers, and there are no intermittent failures on the DCs that could cause these issues.
• Check Event Logs: Review the Event Viewer logs on the client machine and domain controllers, particularly under Applications and Services Logs > Microsoft > Windows > Netlogon. Look for any errors or warnings related to Netlogon or domain name resolution failures.

3. Kerberos Authentication Issues

When accessing Netlogon via the FQDN, Kerberos authentication might be having trouble, especially in hybrid environments with both on-prem and Azure AD-connected devices. This can sometimes happen if there are DNS mismatches or if the client machine has trouble with domain controllers over VPN.

Solution:

• Check Kerberos Configuration: Ensure Kerberos is properly configured on both the client machines and domain controllers. Check for any issues with service principal names (SPNs) that may prevent proper authentication when using the FQDN.
• Check for DNS Resolution of SPNs: Use the setspn command to check if the domain controllers have the correct SPNs registered:

Thanks for that, all that has been checked and everything is fine from a DNS and kerberos perspective. NSLOOKUP and ping on both the short and full fqdn always respond even when the netlogon share of one of them doesnt work.

Thanks for replying, i have checked all of this and DNS and kerberos is all working as it should be, i can get to other network shares and also can ping both the short and full fqdn address when the netlogon share is failing...... i can also run to netlogon on both the long and short address on all domain controllers directly :/

1. Check ODJ Connector Logs

On the server hosting the ODJ Connector Service:

1. Open Event Viewer.
2. Navigate to:
   Applications and Services Logs → Microsoft → Windows → OfflineDomainJoin → Operational.

Logs in this section may reveal:

• Failed connection attempts from the clients.
• Certificate or authentication issues.
• Problems creating device accounts in Active Directory.

2. DNS-Related Errors

If AAD devices cannot resolve domain names properly, this could also be reflected in these logs, as the ODJ process relies on functioning DNS and access to domain controllers.

3. Check Netlogon Logs

Since you mentioned Netlogon issues, also review the following:

• On the server, go to Windows Logs → System.
• Filter logs by the source Netlogon.

Specific errors to look for:

• Event ID 5719: "This computer was not able to set up a secure session with a domain controller."
• Event ID 5783: "The session setup to the Windows NT or Windows 2000 Domain Controller failed."

4. Look for Communication Errors Between Intune and ODJ Connector

Since Intune manages the hybrid device domain join via the ODJ Connector, failed communication can cause problems. Check:

1. ODJ Connector Certificate: Is the certificate for the service valid, and does both Intune and AD DS trust it?
2. Communication: Are port 443 (for Intune) and the necessary ports for AD DS open?

Troubleshooting Tips

• Run the following command on the ODJ Connector server to check its status:                                         Get-AutopilotDiagnosticData    This can reveal issues with connectivity or certificates.
• Check if the clients are logging any related issues in their own Event Viewer under: Applications and Services Logs → Microsoft → Windows → Provisioning-Diagnostics-Provider.

Oh, I forgot to ask you, is the Netlogon service running?
Get-Service -Name Netlogon

Start-Service -Name Netlogon