[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
?
Solved

Active Directory Sites not showing up in DNS (Win2003)

Posted on 2006-05-31
17
Medium Priority
?
329 Views
Last Modified: 2012-06-22
Something seems to be going on with my DNS.  When I add sites in AD Sites and Services, it isn't being reflected in DNS (all zones are Active Directory Integrated and accept secure updates).  This is fairly significant as I'm trying to move some AD servers around to remote offices but the changes aren't taking hold... consequently, everyone is still phoning home to authenticate / get DNS / etc.

I'm kinda desperate for an answer... any help is appreciated...
0
Comment
Question by:dhienzsch
  • 9
  • 7
17 Comments
 
LVL 16

Expert Comment

by:Redwulf__53
ID: 16799224
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.
0
 

Author Comment

by:dhienzsch
ID: 16799419
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.
0
 
LVL 51

Accepted Solution

by:
Netman66 earned 2000 total points
ID: 16799804
Sites won't show up in DNS.

When you create new sites, you need to create and associate subnets to those sites.  You also need to move the servers from Default-First-Site-Name into their respective site within the AD Sites and Services MMC.

That's all you need to do.  KCC will recalculate the topology and the clients should then start talking to their local DCs for authentication.

This might take a little while to finish depending on your connections and number of remote sites.

0
Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

 
LVL 51

Expert Comment

by:Netman66
ID: 16799918
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.

0
 

Author Comment

by:dhienzsch
ID: 16800011
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.
0
 

Author Comment

by:dhienzsch
ID: 16800034
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?
0
 
LVL 51

Expert Comment

by:Netman66
ID: 16800140
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.

0
 
LVL 51

Expert Comment

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

0
 

Author Comment

by:dhienzsch
ID: 16800666
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.
0
 
LVL 51

Expert Comment

by:Netman66
ID: 16800932
Ah, ok - the SRV records in _site - I completely forgot about that entry.

0
 
LVL 51

Expert Comment

by:Netman66
ID: 16800973
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.

0
 

Author Comment

by:dhienzsch
ID: 16800981
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?
0
 
LVL 51

Expert Comment

by:Netman66
ID: 16801068
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.

0
 

Author Comment

by:dhienzsch
ID: 16801715
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?
0
 
LVL 51

Expert Comment

by:Netman66
ID: 16802326
Sounds good.

0
 

Author Comment

by:dhienzsch
ID: 16804539
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
0
 
LVL 51

Expert Comment

by:Netman66
ID: 16806175
No problem.

NM
0

Featured Post

Vote for the Most Valuable Expert

It’s time to recognize experts that go above and beyond with helpful solutions and engagement on site. Choose from the top experts in the Hall of Fame or on the right rail of your favorite topic page. Look for the blue “Nominate” button on their profile to vote.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The HP utility "HP Lights-Out Online Configuration Utility for Windows Server 2003/2008" could be of great use when it comes to remotely configure a HP servers ILO WITHOUT rebooting the server. We would only need to create and run scripts using thi…
Recently, I had the need to build a standalone system to run a point-of-sale system. I’m running this on a low-voltage Atom processor, so I wanted a light-weight operating system, but still needed Windows. I chose to use Microsoft Windows Server 200…
This Micro Tutorial will teach you how to add a cinematic look to any film or video out there. There are very few simple steps that you will follow to do so. This will be demonstrated using Adobe Premiere Pro CS6.
When cloud platforms entered the scene, users and companies jumped on board to take advantage of the many benefits, like the ability to work and connect with company information from various locations. What many didn't foresee was the increased risk…

834 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question