Source

Level

Description

The system failed to register network adapter with settings:

   Adapter Name : {EFA042E1-E7E8-4D50-8E1D-69541C03F4AC}
   Host Name : <server name>
   Adapter-specific Domain Suffix : <domain name>
   DNS server list :
     <ip address>, <ip address>
   Sent update to server : <ip address>
   IP Address(es) :
     <ip address>

The reason it could not register was because the DNS server refused the dynamic update request. This could happen for the following reasons: (a) current DNS update policies do not allow this computer to update the DNS domain name configured for this adapter, or (b) the authoritative DNS server for this DNS domain name does not support the DNS dynamic update protocol.

To register a DNS host (A) resource record using the specific DNS domain name for this adapter, contact your DNS server or network systems administrator.
Data:
0000: 2d 23 00 00               -#..    

Comments

 

This happened to me on a Win2K machine that was otherwise functioning perfectly. The issues arose due to the fact the PC was built in the domain prior to the implementation of AD integrated DNS. No matter what options were tried (ipconfig, etc) the machine would not register correctly using Dynamic DNS (DHCP updates were disabled). The only way to solve the problem was to remove the machine from the domain and re-join. Then all entries were generated and DNS dynamic updates functioned perfectly.

Newsgroup posts indicate that this problem may occur if there is no reverse-lookup zone configured in the DNS for the computer experiencing this issue.

In one instance, this occured when a server using an Active Directory DNS tried to register its name without being part of that Active Directory domain.

In my case this event appeared on clients machines (DHCP), when the server was reconfigured with different IP address and subnet mask. I''ve checked DNS server, it has outdated Reverse Lookup Zone. After deleting the old Reverse Lookup Zone, and creating a new integrated AD Reverse Lookup Zone, the event is gone. Much easier way to figured out why this happening, to get a command Prompt and using nslookup command check DNS settings on the clients.

This is what happened in my case: I made a master image, ran sysprep utility and then deployed it to the network. A few months later, made a second master image, ran sysprep utility and then deployed it to the network. In the sysprep utility I allowed for the computer name to be entered at setup. The same name is assigned to the computer after recieving the image. Before naming the computer, we must manually delete the computer account in the Active Directory, because the computer has the same NIC, same name, but a different SID. Windows 2000 server does not like this. (security) When the computer account is deleted, DNS entries are not. The computers are configured to gain an IP via DHCP.  When submitting info to DNS, computer now have multiple or incorrect IPs associated.  DNS would not allow the machines to make changes.  Solution: Delete the DNS entries manually or run ipconfig /flushdns  and then ipconfig /refreshdns from the effected workstation.

This problem occurs in our case because we have the DNS under UNIX platform and our sysop tells that everything is ok with its setup. Still, I have no idea now on how to resolve these warnings. Samba is setup on all unix machines.

This problem occured on a new server where the NIC was allowed to DHCP and register an address with DNS on first boot. When the address was later hard coded the server was unable to dynamically change the original DNS entry. Manually removing the incorrect address listing from DNS (and WINS if appropriate) and running "ipconfig /registerdns" fixed the problem.

In our case, the server experiencing the problem was an Exchange Server which did not have MX or A records in the forward lookup zone, or a PTR record in the reverese lookup zone of the DNS server. Added these records to the SOA DNS server. Also, there was no DNS reverse lookup zone for that subnet. We believe that this happened because the credentials provided when joining the computer into the AD were different from the ones used to attach to a server in AD (and used by the secure channel between the server and the Domain Controller). For example, you may have a drive mapped to a server in the AD and you provided some credentials (i.e. your user id/password) and then, when you joined the AD you used a different set of credentials (i.e the domain Administrator).
Please check the following:
1. Under which user account did you try to join the computer into the AD? I assume that you're using local Administrator.
2. Do you have any mapped drive on the workstation to the DC? If so, please disconnect all of them and then try to join again.
3. If you cannot find any mapped drive from the workstation, launch Command Prompt and type this command:
    net use * /d
Press Y to confirm when you're prompted. This command will terminate all the active session between this workstations and other computers (including the DC, of course).