imaged machines and the dnsapi event id 11163

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.

synopsis

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

 

some background

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

MYCOMPUTER$ (myDomain\myComputer$)

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 problem

you’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…

1. the original dns object was created by the computer through dynamic dns update
2. ace is placed on the dns object by AD
3. computer is reimaged with the same name
4. computer objectsid changes during this operation causing a mismatched ace on the dns object*
5. computer attempts to create/update the dns object in the zone
6. 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

1. the easiest/quickest fix is to go into the zone and delete the record. 
2. you could also configure dns scavenging.  however, there is a lag period of when the record would get cleaned out.
3. 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.
4. modify your imaging process so that the record is deleted prior by an account w/ elevated privileges to the record.
5. utilize the dhcp lease-expiration process that automatically unregisters the dns record.

i haven’t tried the method in step 5.  i’m curious how well it works.  leave me a comment if you have it in place.

---

marcusoh.blogspot.com