Authenticating to Old Domain Server

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?
Matt MrowickiAsked:
Who is Participating?
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.
Brett DanneyIT ArchitectCommented:
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?
Matt MrowickiAuthor Commented:
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.,, and 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?
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

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.
Brett DanneyIT ArchitectCommented:
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?
If you shutdown 2003 DC, what error you get on client computers during logon to 20102 DC ?
Matt VCommented:
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.
Matt MrowickiAuthor Commented:
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.
Matt VCommented:
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.
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.
Matt MrowickiAuthor Commented:
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?
Matt MrowickiAuthor Commented:
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.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.