Solved

Authenticating to Old Domain Server

Posted on 2014-02-10
14
604 Views
Last Modified: 2014-05-13
I have a client that had a Windows 2003 server as their primary domain controller.  Several months ago, we added a new Windows 2012 server on the network and went through the process to make it the primary domain controller.  The old server was kept on the network while the client migrated applications to the new server.  That has been done and the client wants to take down the 2003 server.  But, when they shut that server down, users are no long able to authenticate to the domain.

We have gone through a series of steps to try and determine why this may be happening.  Some of the steps we have checked include:

1. The new server is the global catalog.
2. DNS is up and running.
3. SRV records in the DNS are fine and exist for both servers (there are kerberos and ldap entries; the _gc entry is for the new server).
4. DHCP is handing out addresses correctly - including DNS.  All of the clients are using the IP address of the new server as primary DNS.
5. The new server is a member of the domain controller group.
6. AD subnet entries are blank on both servers (we aren't using any).
7. Ran netdom query fsmo.  Everything is pointing to the new server.

Can anyone offer any ideas why the clients are still trying (apparently) to use the old server to authenticate or what further troubleshooting steps we can perform to resolve the issue?
0
Comment
Question by:Matt Mrowicki
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 2
  • 2
  • +3
14 Comments
 
LVL 13

Expert Comment

by:SagiEDoc
ID: 39849325
Is the new domain controller added to the correct site?
Is there a NS record in DNS (with a reverse lookup) for the new domain controller?
0
 

Author Comment

by:Matt Mrowicki
ID: 39851466
If you're asking if the new domain control is in AD sites and services then, yes, it is.

There is a name server record in the forward lookup for the new server, but not in the reverse lookup.  That's empty.  I tried adding what we had on the old server (i.e. 0.in-addr.arpa, 127.in-addr.arpa, and 255.in-addr.arpa with the SOA and NS reflecting the new server) but I got an error message saying that those records already exist.  I suppose they do on the old server.

Is there any way to tell is the clients are trying to authenticate to the new server and failing and falling over to the old one, or if they are ignoring the new server entirely?
0
 
LVL 78

Expert Comment

by:arnold
ID: 39852540
Take down, presumably means powered off, versus removed as a DC using dcpromo.


run the query
nslookup -q=srv _ldap._tcp.dc._msdcs.yourdomain
nslookup -q=srv _ldap._tcp.gc._msdcs.yourdomain
nslookup -q=srv _ldap._tcp.pdc._msdcs.yourdomain (should return the new server only)

you will get two records for gc and dc, the workstations will pick one.
note that the records are provided in alternating order.

using nslookup you can direct the query by appending the server ip to the end of line posted above.

This way you can see whether there is an error in the data (DNS ZONes are not synchronized.)
new server reports both, old server only reports itself.
0
Office 365 Training for Admins - 7 Day Trial

Learn how to provision tenants, synchronize on-premise Active Directory, implement Single Sign-On, customize Office deployment, and protect your organization with eDiscovery and DLP policies.  Only from Platform Scholar.

 
LVL 13

Expert Comment

by:SagiEDoc
ID: 39852615
You can run a set l in a cmd session on the client, that will list the DC the client authenticated against. Are the DNS forwarders set on the new DC?
0
 
LVL 37

Expert Comment

by:Mahesh
ID: 39852647
If you shutdown 2003 DC, what error you get on client computers during logon to 20102 DC ?
0
 
LVL 22

Expert Comment

by:Matt V
ID: 39853003
Do a netdom /query fsmo on one of the DC's.  Sounds like one of your roles did not move over.

Running a dcpromo to demote the 2003 DC should also move the remaining roles.
0
 

Author Comment

by:Matt Mrowicki
ID: 39853265
Thank you for all of the comments and suggestions.  We are going to work through these today and see if anything works or offers any ideas.

To clarify: yes, we did run dcpromo to demote the old 2003 server when the new 2012 server was installed last year.  We also moved all of the rules to the new server.  For about a year, we have been running both servers and, we thought, the new 2012 server was the primary AD DC.

Now, the client wants to actually power down and remove the old server from the network.  When we do this is when authentication stops working.

I will follow-up once we can work through the steps suggested so far.
0
 
LVL 22

Expert Comment

by:Matt V
ID: 39853298
If the 2003 server has been demoted, then there must be a share or some service like DNS that is still pointing to it.

Check the list of shares on the 2003 machine, stop the SYSVOL and NETLOGON shares and see if you get the same error as powering it down.
0
 
LVL 78

Expert Comment

by:arnold
ID: 39853729
Double check your DHCP name server options to make sure you are assigning only the new DC's IP.
Then double check any server that has a static IP to make sure its name server settings only point to the new DC.

IMHO, you should try to pursuade your client to maintain at least two functional DCs in the environment.
ONE DC, critical failure on it, causes a massive amount of headaches.

Is the issue isolated to a specific set/s of system/s?

i.e. Terminal Server, etc.
0
 

Author Comment

by:Matt Mrowicki
ID: 39859549
Here are the comments from my client's internal IT:

====================

I ran the requested commands and have attached the output.  I also ran a dcdiag on the new server.  That's included as well.  The error that I'm getting when clients try to log into the domain with the old server turned off is "There are currently no logon servers available to service the logon request."  I'm extremely paranoid about demoting the old server as if that one isn't there, I'm worried that we won't be able to access the domain at all.

====================

staff.staff.library is the old 2003 server.  That server was powered-down when these tests were run.

The results are attached to this comment.  Can this shed light on what's not configured correctly on the new server?
dcdiag.txt
netdom.txt
nslookup.txt
set-l.txt
0
 
LVL 26

Accepted Solution

by:
DrDave242 earned 500 total points
ID: 39889476
If you run net share from an elevated command prompt on the new DC, does it show that the SYSVOL and NETLOGON shares are both present? The dcdiag output you posted appears to show that the NETLOGON share is missing.
0
 

Author Closing Comment

by:Matt Mrowicki
ID: 40062038
Yes, the problem was caused by missing SYSVOL and NETLOGON shares.  What it looked like happened is that on the old server, the SYSVOL shares was corrupt.  Because of this, the replication to the new server couldn't happen.  (This was noted in the event logs on both servers as an issue with the File Replication Service FRS.)  There was a registry entry that was added to the old server, which recreated SYSVOL and, once that happened, FRS did its thing right away, the SYSVOL and NETLOGON shares appeared on the new server and everything from that point worked perfectly.

So, if anyone has an issue involving logging into a server, or accessing any network resources that require log-in (i.e. shared directories), check the SYSVOL and NETLOGON shares and start there.
0

Featured Post

NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

Question has a verified solution.

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

Suggested Solutions

A project that enables an administrator to perform actions within a user session context not just at the time of login but any time later on day(s) or week(s) later.
Always backup Domain, SYSVOL etc.using processes according to Microsoft Best Practices. This is meant as a disaster recovery process for small environments that did not implement backup processes and did not run a secondary domain controller that ne…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…

732 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