Source

Level

Description

The system failed to register host (A) resource records (RRs) for network adapter
with settings:

   Adapter Name : {02C23FBC-7048-4752-89FA-2ADAD732F5D4}
   Host Name : SERVICE
   Primary Domain Suffix : mydomain.local
   DNS server list :
     192.168.16.2
   Sent update to server : 192.1.1.1
   IP Address(es) :
     192.168.16.48

The reason the system could not register these RRs was because the DNS server failed the update request. The most likely cause of this is that the authoritative DNS server required to process this update request has a lock in place on the zone, probably because a zone transfer is in progress.

You can manually retry DNS registration of the network adapter and its settings by typing "ipconfig /registerdns" at the command prompt. If problems still persist, contact your DNS server or network systems administrator.

Comments

 

User travels to different states with different time zones. It never happened before but suddenly started getting the mentioned error and he was unable to browse to data on server. He could browse data on other computer (not servers). As suggested by Brian Collins we removed the laptop from domain and deleted its account on server. We re-joined the laptop to domain and it fixed the problem. So it worked without any registry changes or time change.

As one of the previous posts suggested, check the permissions for the A record are not owned by the wrong machine or a deleted account (characterized by unknown SID message). Delete the A record from DNS server and then ipconfig /registerdns from the relevant machine, it will then be able to successfully create a new A record with the correct security permissions.

We got this message on some random clients in a network with about 100 clients. So it seemed that the DNS Server was not the problem. Trying to solve the issue with some hints of the comments below doesn't work at all. In our case the root of the problem was an incorrect registry value. When we changed the value of HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface ID}\RegisterAdapterName from one to zero and deleted the Registry Key HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DNSRegisteredAdapters\{Interface ID} the message never occurred again.

See this link EV100147 to an article on a blog by Rod D. It fixed our issue.

This problem can also occur on machines which have been cloned. This will result in the machine`s A PTR record being unreadable/writeable by the relevant machine. As per Brian Collins' comment, check the permissions for the A record are not owned by the wrong machine or a deleted account (characterised by unknown SID message).

On a machine here, we tried "ipconfig /registerdns" and it did not work. We changed the zone updates to “unsecure and secure” and while that worked, I did not want to have to live with it. Eventually, what worked was un-joining the machine from the domain, deleting the disabled computer account, and re-joining the computer to the domain. What tipped us to this was that the A- and PTR- records had an unidentified SID listed in the security tab. That should have been the AD name. After un-joining and re-joining, the AD name was listed instead of just the SID.

I found this problem could also manifest itself when the time on the client is uncoordinated. On my machine, I had this problem and my client clock was 12 hours behind. I reset the clock, rebooted, and the problem was fixed.

I had this problem after re-installing an XP Pro machine. Renewing the IP address did not resolve the problem, nor did “ipconfig /registerdns”. I resolved this by first removing the host (A) and pointer (PTR) records from DNS and then running “ipconfig /registerdns”.

On a Windows XP client, create the following registry entry “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters”
Key: UpdateSecurityLevel. Type: REG_DWORD. Value:0x00000100. Set the Value to 0x00000100 to use secure dynamic update only. This parameter can be used to control the security that is used for DNS dynamic updates.

This can be fixed by releasing then renewing the DHCP address, which forces a correct update to the DNS records. ipconfig /registerdns does not work in solving this issue.