i wonder if this is going to end up a long-winded post. i never intend for that to happen because somewhere i picked up that technical information should be succinct. however, when i started looking into this problem, it seemed like there just wasn’t good information on it.
synopsisa user in your environment needs to have their machine reimaged. as a loyal IT citizen, you promptly do so by any manner that happens to be your favorite (e.g. mdt, swimage, ghost, etc). you bring up this machine as the same name. later on, you try to remotely manage the machine but realize that the ip it once had is different. you spin your wheels a bit trying to figure out why the new ip hasn’t registered in dns. upon reviewing the event log of the machine, you discover events that look eerily similar to these:
Event Type: Warning Event Source: DnsApi Event Category: None Event ID: 11163 Date: 8/12/2008 Time: 5:32:32 PM User: N/A Computer: myComputer Description: The system failed to register host (A) resource records (RRs) for network adapter with settings: Adapter Name : myAdapterGuidorName Host Name : myComputer Primary Domain Suffix : myDomain.com DNS server list : 10.x.x.x, 10.x.x.x Sent update to server : 10.1.1.1 IP Address(es) : 10.x.x.x
thanks to this blog post, i stopped chasing the elusive message “sent update to server : 10.1.1.1”. so let’s leave that alone and move on to the actual problem.
alright, so the prerequisite for this condition happening above is that you would need an AD-integrated zone that has secure-only dynamic updates. when you do this, acls are placed on the dns objects in ad. also, you’ll notice your dns objects will have an available security tab.
if a zone has secure-only set, the security tab will show an ace for the machine. so, as it’s stated above, i’d see an ace for
in a zone with nonsecure and secure dynamic updates, there will be no such ace for the computer object. what’s this mean? anyone can make updates to that record. sounds okay so far, right?
the real problemyou’re probably way ahead of where i’m getting with this. essentially, the reimaged machine is no longer the same computer object as before. stepping through this, in a secure-only zone…
- the original dns object was created by the computer through dynamic dns update
- ace is placed on the dns object by AD
- computer is reimaged with the same name
- computer objectsid changes during this operation causing a mismatched ace on the dns object*
- computer attempts to create/update the dns object in the zone
- attempt fails because the computer no longer has access to the dns object.
* you can verify this condition pretty easily. check the security tab of the dns object. do you see something that says "account unknown" followed by a long string of numbers?
the not-so-real solution
- the easiest/quickest fix is to go into the zone and delete the record.
- you could also configure dns scavenging. however, there is a lag period of when the record would get cleaned out.
- reimage the machine as a new computer name so that a new dns object is created instead of hitting a conflict against an existing object.
- modify your imaging process so that the record is deleted prior by an account w/ elevated privileges to the record.
- utilize the dhcp lease-expiration process that automatically unregisters the dns record.