I have fixed this issue on my secondary server. It appears to have been related to IPv6. Disabling IPv6 on the server has solved the issue and I have been event free for nearly 3 hours when it was occurring about every 5 to 20 minutes previously. Since my environment does not use IPv6 at all and a portion of my infrastructure doesn't support it I have opted to disable IPv6 on both servers.
Should I require IPv6 support in the future I will simply configure it at that time. For now, I'm just going to roll with good old IPv4. Hopefully this helps someone else out. Looks like this has greatly reduced the errors, but they are still present.
I'm down to once every several hours, but the errors continue. Disabling IPv6 is not the entire answer to this puzzle. The thing I did change was the SOA-records of all the zones i had.
I raised the value by 5 on 1 of the DC's After that I forced a replication from that server to all other DC's. So far More then 60 hours i haven't had a new error. It looks like I have finally found the answer to my problem. I have recently switched to a direct site link through our ISP just a layer 2 connection between the two using Ethernet over Private Line and stuck a Cisco series router between the sites.
The increased stability of the EoPL line and removing the complications that can be caused by VPN tunnels seems to have corrected my issue entirely after ensuring all of my DNS records were correct as I previously stated. I have the same issue as Brian. Interestingly, we used to have our sites connected with MPLS circuits Cisco routers and T1 lines , and never had this issue. Then a month ago we switched to VPNs on broadband internet, and that's when this issue started appearing.
It's nothing more than a nuisance even logged in the DNS log at this point, as far as I can tell. It looks like the requirement was changed in Server , in my environment there are many sites but only one with a pair of DC's and it is the only site experiencing the issue. I noticed that from 11pm to 4pm when over all internet and subsequently WAN traffic is low the error never occurs, around 4am PST when the rest of the world is already awake the errors start to manifest again.
On weekends the duration is longer the errors stop around 9pm PST. I can find no pattern what so ever to the time stamp which makes me think its a very thing line of utilization on the WAN that is affecting the error. Ultimately as there seems to be no service impact as someone else mentioned I am leaving it alone for now. Today we had a networkoutage for about 15 minutes at one site. Exactly at the same time and same timespan the errors occurred.
Could this be due to the encryption of the tunnel? If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly. If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.
If no, please reply and tell us the current situation to provide further help. Office Office Exchange Server. Not an IT pro? Resources for IT Professionals.
Sign in. United States English. Ask a question. Quick access. Search related threads. Remove From My Forums. I changed the order on all domain controllers and the number of instances reduced. I find this weird, since the only argument I have ever heard to support Microsoft's current best practice, is related to boot time of a Domain Controller and a particular disaster recovery scenario. However, it did seem to have a positive effect and that's good.
However, across our 24 Domain Controllers, I continued to have the issue around once per week. I then got to thinking about something that I have been ignoring for sometime. All rights reserved.
0コメント