не найдено описание для события с кодом 4015 в источнике microsoft windows dns server service

Профиль | Отправить PM | Цитировать

Спустя две недели полезли косяки в виде ошибок 4004 и 4015, то ли из-за отключения света в ночное время на работе, может еще почему, после запуска домен контроллеров и попытки активации клиентских систем средствами VAMT я перестал получать от клиентов ответы, полез пинговать клиентские ПК, ответа нет, пинг по DN выдает мне даже IP клиентской машины, но отклика от неё нет (превышен интервал ожидания для запроса).

http://www.eventid.net/display.asp?e. ce=DNS&phase=1 не помогает, технет тоже заглох в 2010году на эту тему.

Помогите пожалуйста, сломал голову уже.

I’ve recently installed a Windows Server 2012 domain controller in one of our branch offices; all seems to be running well but have noticed I keep getting a repeating DNS error which is very vague and I can’t find out what the problem is an how to fix:

«The DNS server has encountered a critical error from the Active Directory. Check that the Active Directory is functioning properly. The extended error debug information (which may be empty) is «». The event data contains the error.»

The domain is a mixture of 2003, 2008 & 2012 dc/dns.

Does anyone know what the issue could be?

37 Replies

Anyone come across this before?

I have the exact same issue on 4 fresh 2012 DC’s. Everything seems to be running correctly.

Any other events? 1030, 1058?

Not on mine. only the 4015.

Ran dcdiag /test:dns

All tests passed with only a warning that the test file could not be deleted.

I’m unsure why there is a best answer. I still receive the 4015 errors on all 4 dc’s. DungeonMaster3000 did you find a solution?

I never found a solution either. I’ve unchecked best answer as I don’t recall checking it. I have no other events beside normal stuff like starting up and savaging events. I also ran «dcdiag /test:dns» with no issues.

I’ve got the same error on 2 of 3 DC’s running MS Server 2012.
When i run the dcdiag /test:dns command i get this:

Thing is I upgraded to MS 2012, and demoting my W2K3 Dc’s accordingly.
the dc-sea used to be a W2K3 DC but does not excist anymore.
As you can see je still want’s to do something with this DC.

Any idea’s how to solve this?

I was able to get my Server 2012 DCs to pass the dcdiag /test:dns test by deleting old records of the demoted DCs out of the DNS MMC. Even though I had removed the DNS service and removed the site links in AD Sites and Services there were still remnants of the servers in DNS.

I’m still getting even 4015 though and can’t seem to figure out why. This is only happening on one of the 2 servers I have and it happens to not be the FSMO roles holder. I’m starting to wonder if this isn’t a problem with talking to the PDC along the line even though replication and DNS tests pass.

Thanks for the reply.
I also removed any obsolete references to the old DC’s but no success.

I’m thinking that the obsolete records in DNS have practically nothing to do with the issue. What bothers me is that the 4015 error says what the problem is. Or at least what zone or object is causing the problem, but the text is missing. only blank quotes to be seen?
I’m guessing there are some linguering objects (zones, records. ) of some kind that need to be removed. I guess playing with adsi-edit and looking in the DNS repositories could resolve the problem.

But untill now i haven’t had any success 🙁

I just figured I would check back in here. I even decided to go through the trouble of completely removing the DNS server role from my second DC, rebooting it, placing all DNS files (c:\windows\system32\dns\) in a «.old» directory, and reinstalling the DNS service to ensure a clean copy pulled over from the main DC. After all of that I’m STILL seeing this issue.

Not only that, I also appear to be having an odd IPv6 artifact popping up in my DCDIAG /test:DNS runs now where it can’t resolve the root hint servers. I suspect this is due to the fact that I don’t have a gateway set up that handles IPv6 so I’m not really concerned about it.

If I come across anything else I’ll let you know, for now I’m back to the hunt to figure out what SHOULD be in those blank quotes.

Oh, and on the removing old records thing, it took me a good 30 minutes to dig through ALL of the DNS configurations to make sure that I got all the old records torn out. Make sure to right click every zone and hit the properties to check for name servers as well as expand every subfolder in the DNS hierarchy. GL and I’ll report back in with what I find out.

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 4015 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.

My DC’s do not have the IPv6 enabled. so that’s not the issue.

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 4015 error.

Hopefully I managed to stop the spamming of my eventlogs.. 🙂

It looks like I have finally found the answer to my problem. Our sites were linked together by IPSec VPN tunnels initiated at the gateway of each location. 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 2600 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.

Источник

• ← текстуры для майнкрафт 512×512 realism
• запорный клапан код тн вэд →