techie17 Posted December 4, 2019 Author Posted December 4, 2019 Has the Sophos XG box at the remote site got any DNS servers or forwarders listed? Demoting the DC won't have removed anything from there (I imagine). If you are getting a round robin DNS lookup happening then sometimes it will grab a correct listing, others it will find the old address Ive had a Look and under the DNS tab in networks, its got 8.8.8.8 8.8.4.4 and 1.1.1.1
TechMonkey Posted December 4, 2019 Posted December 4, 2019 Just to confirm. On your DHCP, when you select Server Options, 006 DNS Servers does not have the old server listed. On any of your DHCP servers?
techie17 Posted December 4, 2019 Author Posted December 4, 2019 Just to confirm. On your DHCP, when you select Server Options, 006 DNS Servers does not have the old server listed. On any of your DHCP servers? We actually use the sophos XGs dhcp server as there aren't windows servers on site but in the DHCP settings, ive definitely set only DC01 and DC02
themightymrp Posted December 4, 2019 Posted December 4, 2019 Apologies if you've already answered this. Do you have any issues with devices at the main site connecting to the web services at the main site? Is it only devices at the remote location having troubles? Is there any way you can do a full ipconfig /all on one the of the devices that can't connect to the services?
techie17 Posted December 4, 2019 Author Posted December 4, 2019 Apologies if you've already answered this. Do you have any issues with devices at the main site connecting to the web services at the main site? Is it only devices at the remote location having troubles? Is there any way you can do a full ipconfig /all on one the of the devices that can't connect to the services? Clients at the main site can connect to web services and everything else at the main site perfectly fine. I’ve done an ipconfig on the good clients and bad ones and they show the same settings
mavhc Posted December 4, 2019 Posted December 4, 2019 1. Why is it thinking it's a new network? NLA provides the following network location information: Logical Network Identity NLA first attempts to identify a logical network by its DNS domain name. If a logical network does not have a domain name, NLA identifies the network from custom static information stored in the registry, and finally from its subnet address. So make sure your dns suffixes are correct. 2. The Windows Client finds the DC using DNS, but specifically things like _ldap._tcp.domain.name If you're using Sophos XG for the DNS that's going to require a lot of manual config, forward the dns to the other Windows DCs 3. Why does that cause the ip not to connect, if it does. Did you try telnet port 80?
Shadow_Walker Posted December 4, 2019 Posted December 4, 2019 Just looked at all the DHCP server and all look fine. I have noticed however that some clients network adapters are showing as DOMAIN.internal 2 (Unuthenticated) Some clients are fine though. Just thinking from a different angle have any of your clients got photoshop installed? May sound strange but had a similar issue.
techie17 Posted December 5, 2019 Author Posted December 5, 2019 (edited) Just thinking from a different angle have any of your clients got photoshop installed? May sound strange but had a similar issue. No we dont have photoshop installed. We have however change the computer at the remote site to a different VLAN and this worked. We were able to put it back on the domain successfully. Nothing has changed on the switching nor the XG to warrant why this works on the wifi vlan and not the wired vlan. Just found out that even some wifi clients are affected and still showing the mat.internal 2 (unauthenticated) so again nothings is making sense. Edited December 5, 2019 by techie17
techie17 Posted December 6, 2019 Author Posted December 6, 2019 I think i seem to be narrowing down the issue to possibly a Hyper-V networking config issue. I have 2 hosts in a cluster and on each host i have 2 x 10gb SFPs connected into the switch and 4 x 1gb NICs in a team. I only have one Virtual switch in hyper-v which is using one of the 10gb SFP ports and not the NIC Team. The VM's are using the only VSwitch (the 10gb SFP) so is this correct? i thought the VMs should be using the NIC team of the 4 x 1gb NICs? My next step was to update the drivers of the NICs on the host.
techie17 Posted December 11, 2019 Author Posted December 11, 2019 Im still no further forward with this. Yesterday i put the clients at the remote site on a single VLAN which at first appeared to work. However this morning a few a getting the MAT.internal 2 (Unaithenticated) message again. If multiple remote sites are having the same behavior, and all those switches have the same setup, is this more pointing to an issue with the switch, firewall at our main site? Again it seems strange that as soon as i demoted a DC at the main site, the issues started to occur. One thing i did notice in DNS is that an old remote site appears in mat.internal\ _sites\School1\ _tcp but has a DC in in it that also exists in mat.internal\ _sites\MainSite\ _tcp . Not sure if this has anything to do with it and if it can be cleaned up? In sites and services, only MainSite exists and not School1 Thanks
mavhc Posted December 11, 2019 Posted December 11, 2019 try https://blogs.technet.microsoft.com/ashleymcglone/2010/12/22/a-dickens-of-a-dns-puzzle-how-to-clean-up-those-stale-ad-site-dns-records-with-powershell-of-course/
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now