You got it - these records are a result of DCs saying "I am authoritative for this site" (whether as a result of being located in the site, or by being close to the site if it has no DCs). The actual subnet-to-site mappings only live in AD, and "nltest /dsgetdc" is the best way to confirm that a client knows its site. If you have some clients with no site, they will appear in windows\debug\netlogon.log on the DC.
--Steve On Mon, Jan 30, 2012 at 11:00 PM, Richard Stovall <rich...@gmail.com> wrote: > Oh. I think I get it.* Am I looking for the static records for each DC in > zonename |_sites | default-first-site-name | _tcp ? If so, they were > already there for all the DCs by the time I looked. > > * And if I'm wrong, then I'm even more embarrassed... > > > On Mon, Jan 30, 2012 at 8:38 PM, Richard Stovall <rich...@gmail.com> wrote: >> >> Thanks very much, Steve. I've created the properly defined subnet, but >> I'm confused about exactly which DNS registrations I should be looking for. >> >> Richard >> >> On Mon, Jan 30, 2012 at 7:38 PM, Steve Kradel <skra...@zetetic.net> wrote: >>> >>> Yes, AD and things that depend on AD will generally do fine with one >>> site and no subnet mappings at all. Once there are two or more sites, >>> you must map every client to a site via ADS&S or things will start to >>> go off the rails. >>> >>> Go ahead and create a second, larger subnet for the site, wait a >>> decent interval, and check the DNS registrations. If all is well you >>> can (if you like) delete the unneeded too-small subnet object. >>> >>> The question was long, but the answer is short. ;) >>> >>> --Steve >>> >>> On Mon, Jan 30, 2012 at 8:34 PM, Richard Stovall <rich...@gmail.com> >>> wrote: >>> > -- Long message below. Please pardon the verbosity. -- >>> > >>> > Part one - one question at the end. >>> > >>> > I am incorporating a second physical location to $work. I had been >>> > pondering a child domain for the new location, but the reasons for >>> > possibly >>> > going in that direction have been mitigated, and I have decided to just >>> > join >>> > the second location to my single domain forest. >>> > >>> > In preparation for installing a DC at the new location, I created a >>> > subnet >>> > and site in ADSS. I have not yet added the machine that will be the >>> > new DC >>> > to the domain. >>> > >>> > A few minutes after creating the new site, Exchange (single server with >>> > all >>> > roles) stopped accepting client connections and started borking on >>> > processing mail (14 messages wound up in the poison message queue). >>> > >>> > I gleaned from the Exchange server's Application log that Exchange >>> > could not >>> > determine what AD site it is in. (Event 2501 - Process >>> > MSEXCHANGEADTOPOLOGY >>> > (PID=1580). The site monitor API was unable to verify the site name for >>> > this >>> > Exchange computer - Call=DsGetSiteNameW Error code=800703e5. Make sure >>> > that >>> > Exchange server is correctly registered on the DNS server.) >>> > >>> > Googling led me to http://support.microsoft.com/kb/2025528 which gave >>> > me an >>> > idea of how to resolve the immediate issues with Exchange. Sure >>> > enough, >>> > nltest /dsgetsite reported "Getting DC name failed: Status = 1919 0x77f >>> > ERROR_NO_SITENAME". I deleted the new site, checked AD replication, >>> > then >>> > restarted the Exchange AD Topology service (which also restarted a host >>> > of >>> > other dependent services). Nltest /dsgetsite then reported >>> > "Default-First-Site-Name". >>> > >>> > All is seemingly back to normal, the App and System logs look good, >>> > I've >>> > released the messages that got put into the poison message queue, mail >>> > is >>> > flowing normally, OWA works again, and Outlook Anywhere is functioning. >>> > >>> > Question regarding this event - Is there anything else I should look at >>> > or >>> > be aware of as far as Exchange is concerned after an event like this? >>> > >>> > >>> > Part two - How to fix the underlying problem? - Two questions at the >>> > end. >>> > >>> > I took a closer look at ADSS and discovered a couple of things. The HQ >>> > domain was created in 2002 and has some odd quirks related to DNS name >>> > etc, >>> > but I had never noticed something about the single ADSS subnet before. >>> > It >>> > is named x.x.200.192/26, but our production subnet is really >>> > x.x.200.0/23. >>> > The Exchange server's ip is x.x.200.216, so by pure coincidence it >>> > does >>> > actually fall into the too-small /26 defined in ADSS. Also >>> > coincidentally, >>> > my 3 HQ DCs fall into the /26 range as well since they are x.x.200.246, >>> > x.x.200.247 and x.x.200.249. >>> > >>> > The next oddity is that if I view the subnet's properties in ADSS, it >>> > is not >>> > associated with the Default-First-Site-Name. I can choose that site >>> > from >>> > the drop-down list of sites, but it is blank right now. >>> > >>> > My guess is that Exchange hasn't had issues with finding the site >>> > before >>> > because there was only one. My supposition is that if I associate the >>> > existing /26 subnet definition with the site Default-First-Site-Name, >>> > that >>> > Exchange will be able to stay in the the correct site after adding an >>> > additional one for the new remote facility. >>> > >>> > Question one - are these assumptions likely correct? >>> > >>> > Question two - How can I correct the too-small subnet definition? Is >>> > it >>> > possible to edit the subnet, or should I look at creating a new, >>> > correctly >>> > defined subnet that could eventually replace the current one? >>> > >>> > I hope this all makes sense, and I apologize again for the length. >>> > >>> > Any thoughts or suggestions are most welcome. >>> > >>> > Richard >>> > --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe exchangelist
