Active Directory Sites not showing up in DNS (Win2003)

First thing is to run DCDiag.exe and Netdiag.exe on both servers and look for any Replication or DNS errors.
These tools can be installed from the Windows CDRom from the \SUPPORT folder.

DCDiag and Netdiag only showed one error significant error (not including WINS errors - no WINS servers are on our network)...

On our AD server in New York (which is also running DNS), the following entry came through from netdiag.  I'm not sure where it's looking in DNS for this entry...

DNS test . . . . . . . . . . . . . : Failed
    [WARNING] The DNS entries for this DC are not registered correctly on DNS server '192.168.1.10'. Please wait for 30 minutes for DNS server replication.

I ran NSLOOKUP using 192.168.1.10 as the name server and was able to resolve the name of the NY server correctly.  I guess I'll wait 30 minutes and try this again.

I should also point out that for some reason, DNS is now reflecting the changes to sites that I made.  Once I run the NETDIAG test again and see if that DNS error goes away, I'll post up what I did so that the resolution isn't lost in the ether.

I should also add:

Leave the original servers for the main site in Default-First-Name-Site - this is important.  The root servers are tied to this site.  If you need to, you can rename this site to whatever you like without breaking anything, but if you move the root servers from there you are in for a world of hurt.

All DCDIAG and NETDIAG tests now show clean... for some reason one "A" record and one "SRV" _gc entries were missing for the New York server under the forest root zone, but those were easy enough to manually create (and checking the "allow authenticated updates" checkbox).  A quick forced AD replication and those changes were reflected across all AD / DNS servers.

The existing DNS entry that was probably causing the NETDIAG issue...
Forward Lookup Zones\_msdcs.DOMAIN.NAME\gc\_sites\NYSite\_tcp\Service Location (SRV) record for NY Global Cat. Srvr.

The DNS entries manually applied to resolve the NETDIAG issue were...
Forward Lookup Zones\_msdcs.DOMAIN.NAME\gc\Host (A) record for NY Global Catalog Server
Forward Lookup Zones\_msdcs.DOMAIN.NAME\gc\_tcp\Service Location (SRV) record for NY Global Catalog Server

Ok... so that's the NETDIAG issue resolved... but back to the original question... NETMAN66 was correct.  I needed to be patient when recreating my site structure for the site entries to be populated into DNS.  Also, those sites don't show up until you apply a subnet to them.

The trick though was that prior to doing all this, I had a whole mess of sites that were created by a consultant, and when those were cleaned out of Sites and Services, they WEREN'T removed dynamically from DNS, and those sites show up all over the place in DNS.  So here's what I did and the order I did it in...

1.  Moved all AD servers from the site they were in into "default-first-site"
2.  Reassigned all subnets to "default-first-site"
3.  Deleted all sites from Sites and Services EXCEPT default-first-site
4.  Manually replicated AD across all AD servers using REPLMON.  Logged into each AD server using Remote Desktop and verified that the changes were reflected locally.
5.  Verified in DNS that the SRV records in each section of each forward lookup zone had been moved into default-first-site.
5.  Ignored all calls from remote offices wondering why login was taking so long.
6.  Manually deleted all site entries (again, except for default-first-site) in DNS in all Forward Lookup Zones (there are a TON).
7.  Manually replicated AD across all AD servers using REPLMON again.  (DNS is AD integrated after all)
8.  Recreated appropriate sites, applied subnets, moved AD servers to correct sites.
9.  Went and had a cup of coffee so I wouldn't sit at my desk and hit F5 waiting for sites to appear in DNS.
10.  Verified that all sites were created correctly in DNS.  All SRV and A record entries were created to direct clients to appropriate LDAP, KERBEROS, etc services at each site.  Replicated AD one last time and logged in locally to each AD server to verify the changes locally as well.

I think that's all I did.  I feel a little nervous that I horsed around so much manually with our DNS, but it makes a bit more sense to me now.  As long as things don't suddenly start dissappearing I think we should be cool.  

I suspect the reason that the sites weren't updating in DNS may have occured if the consultants that wound up spraying sites all over AD also converted the DNS zones (both domain and forest root zones) from AD integrated to standard primary zones on each AD/DNS server.  No AD Integration = no dynamic updates.

*whew*

Consulting:  If you're not part of the solution, there's good money to be made in prolonging the problem.

Ok... while I was typing the above dissertation, I didn't see the whole "Never move the root servers out of DEFAULT-FIRST-SITE" message... which, of course, I've gone and done.  I know you're never supposed to DELETE default-first-site and default-site-link, but I didn't know about the whole don't move root server out of it (and by root server I'm guessing you mean the PDC emulator right?).  Can you explain the world of hurt I should expect a little bit?

When you create the first server in a new forest and domain it's tied to the Default-First-Site-Name in more ways than meet the eye.  The entire replication topology is based off this site.

You can move the root server back to this site and delete the new one you created for it (as well as the subnet).  It should correct any underlying issues by itself.

By root server, I am referring to the original server for the forest which normally holds all the FSMO roles unless you've moved them.

I'm guessing when you say "sites in DNS" you are referring to the reverse lookup zones for those subnets?

I think I'm on the same page with you as far as the root server goes.  The PDC emulator FSMO role (along with all the others) still resides on the original AD server.  By "sites in DNS" i'm referring to the _site entries that exist in the FORWARD lookup zones.  Each time a site is added in AD Sites and Services and a server / subnet is configured to use that site, it is also added to the Domain and Forest Root Forward Lookup Zones in DNS (provided the zones are AD integrated with secure updates apparently).  The sites the consultants had added were not removed from the FLZs in DNS when they were deleted in Sites and Services and consequently, the DNS entries for KERBEROS, LDAP, etc were all messed up.

I'm looking for further information on the default-first-site issue you mention above.  Even though it looks like things are now working fine the way they are, I want to make absolutely sure I'm not shooting myself in the foot going forward if I leave it that way.  I'm also looking into the site configurations on the AD server and I'll get back to you.

Ah, ok - the SRV records in _site - I completely forgot about that entry.

Here is a small quote:

"The Active Directory Topology is rooted at Sites\Default-First-Site-Name\Servers. This contains just those servers participating in a specific site regardless of domain. To view the connections for any given server, display Sites\Default-First-Site-Name\Servers\{server}\NTDS Settings. For each server, there are connections and schedules which control replication to other servers in this site."

Reference: http://asg2.web.cmu.edu/orpheus/msdocs/wt/adssmgr.doc

I'd like to think there's more reference material for this - I'm still looking.

So I did a little bit of research and on pg. 590 of Mark Minasi's "Windows Server 2003" (Sybex Publishing - 2003), under the heading of "Renaming Default-First-Site-Name" he states "This works best if you do it EARLY in your AD creation.  In fact, it's really best to rename Default-First-Site-Name when you create your first DC."

That seems like pretty good backup to what you said earlier.  However, I'm waaaaayyyyy down the road from having created my first DC in this organization and have had that original AD server / PDC Emulator sitting in a site I created for at least two years now.  All issues with DNS updating aside... are you recommending I move it back and rename D-F-S-N, or should I just let this sleeping dog lay around?

The choice is yours really.  I would put the server(s) back at the very least.  You should still be okay renaming the site as long as replication is working fine the change will make it's way around okay.

Let me see if I have this right... if my root server is in site "HQ" then...

1.  Move AD servers from HQ back into D-F-S-N.
2.  Reassign all appropriate subnets from HQ back to D-F-S-N.
3.  Make sure the changes are propogated into DNS.
4.  Force an AD replication
5.  Delete "HQ"
6.  Force an AD replication
7.  Rename D-F-S-N to "HQ"
8.  Make sure changes are replicated in DNS.

That should be about it right?

Sounds good.

Well... about six hours have passed since I follwed the steps above and I haven't suffered any noticable ill effects.  I would state that there should be a step 6a that says if you have any custom defined site links, you need to make sure that they include the D-F-S-N or the KCC will kick up a bunch of errors in the Event Log.  Other than that, everything seems to be working fine.  D-F-S-N is no where to be found in either Sites and Services or DNS and the _sites entries (and appropriate SRV records) all seem to have taken hold and updated themselves correctly.  

Thanks for sticking with me... I love tenacity in tech support!

D

No problem.

NM