Skip to main content

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.

Comments

  1. I'd say it is too much work ... for just making a machine work.

    I am working for Reimage - reimaging a PC without lossing anything, will take you about 20 minutes.

    take a look (www.reimage.com) hope is saves you some time in the future.

    -- Jason

    ReplyDelete
  2. did you read the entire thing? i realize this is probably a spam comment... but no matter what image method you're using, you're going to want to clear the machine sid. reimaging a machine in the environment mentioned above means you will be getting a new sid and hence run into this issue.

    ReplyDelete
  3. Thanks Marcus! Great article as usual!
    In a variation of method 5, deleting the lease in DHCP will force the client to refresh. The original DNS object still needs to be scavenged but the client side of things are proper.

    ~ Aaron

    ReplyDelete

Post a Comment

Popular posts from this blog

using preloadpkgonsite.exe to stage compressed copies to child site distribution points

UPDATE: john marcum sent me a kind email to let me know about a problem he ran into with preloadpkgonsite.exe in the new SCCM Toolkit V2 where under certain conditions, packages will not uncompress.  if you are using the v2 toolkit, PLEASE read this blog post before proceeding.   here’s a scenario that came up on the mssms@lists.myitforum.com mailing list. when confronted with a situation of large packages and wan links, it’s generally best to get the data to the other location without going over the wire. in this case, 75gb. :/ the “how” you get the files there is really not the most important thing to worry about. once they’re there and moved to the appropriate location, preloadpkgonsite.exe is required to install the compressed source files. once done, a status message goes back to the parent server which should stop the upstream server from copying the package source files over the wan to the child site. anyway, if it’s a relatively small amount of packages, you can

How to Identify Applications Using Your Domain Controller

Problem Everyone has been through it. We've all had to retire or replace a domain controller at some point in our checkered collective experiences. While AD provides very intelligent high availability, some applications are just plain dumb. They do not observe site awareness or participate in locating a domain controller. All they want is the name or IP of one domain controller which gets hardcoded in a configuration file somewhere, deeply embedded in some file folder or setting that you are never going to find. How do you look at a DC and decide which applications might be doing it? Packet trace? Logs? Shut it down and wait for screaming? It seems very tedious and nearly impossible. Potential Solution Obviously I wouldn't even bother posting this if I hadn't run across something interesting. :) I ran across something in draftcalled Domain Controller Isolation. Since it's in draft, I don't know that it's published yet. HOWEVER, the concept is based off

sccm: content hash fails to match

back in 2008, I wrote up a little thing about how distribution manager fails to send a package to a distribution point . even though a lot of what I wrote that for was the failure of packages to get delivered to child sites, the result was pretty much the same. when the client tries to run the advertisement with an old package, the result was a failure because of content mismatch. I went through an ordeal recently capturing these exact kinds of failures and corrected quite a number of problems with these packages. the resulting blog post is my effort to capture how these problems were resolved. if nothing else, it's a basic checklist of things you can use.   DETECTION status messages take a look at your status messages. this has to be the easiest way to determine where these problems exist. unfortunately, it requires that a client is already experiencing problems. there are client logs you can examine as well such as cas, but I wasn't even sure I was going to have enough m