New domain controller doesn't service logon requests

Legacy Environment

We had a single Windows 2000 server acting as an active directory domain controller.  All the usual roles were assigned and it was a DNS server but not DHCP.

Environment Changes

We then added a Windows 2003 R2 server to the environment; brand new hardware with a fresh install of the server OS.  We joined it to the domain as a member server then attempted to install Active Directory and make it a domain controller.  The idea was to replace the aging Windows 2000 server box with this new server.  We had to update the domain forest to make the legacy domain compatible with Windows 2003 R2 and then the new server was able to join the domain as an AD server / controller.  Obviously DNS is installed on the new box and I believed it to be correctly configured since the Active Directory wizard will generally yell at you if it's not.  Everything seemed smooth so far.

Retiring the Legacy Server

Finally, yesterday, we were ready to bring the old server offline.  All our data had been transferred so we started moving operations master roles to the new 2003 R2 server.  They have all appeared to move correctly, with the exception of the schema master role which comes back with an FSMO error saying the current role holder could not be contacted and the role could not be transferred.

In testing, we downed the old server (despite not having the schema master role moved) and attempted to login to the domain from several workstations.  The computers login with what I assume is cached domain information but if I try to browse to our 2003 R2 server and view its shares, I’m hit with a “no logon server was available to service your logon request” error.  Bringing the old 2000 server back online resolves the error and users are able to login to the domain without a problem.

Obviously there is some role the old server is holding onto that I’m missing.  Is the schema master role my problem?  Should I attempt to seize the role?  I'd hate to do that if I can avoid it.  I’ve confirmed that the 2003 R2 server is the RID, PDC and Infrastructure master as well as the GC master.  At least that’s what Active Directory is telling me.  I've seen a few notes about DNS being the culprit in "no logon server" errors.  Could that apply to me as well? Any suggestions would be appreciated.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

feptiasChief DudeCommented:
DNS is very likely the culprit as you say. Is the new 2003 server set to use itself as the DNS server (i.e. does ipconfig /all report its own IP address as the preferred DNS server)? What is set as the preferred DNS server on the workstations?

I don't believe the schema master role would cause the login problems. I'll leave it for others to comment on what is the best way to transfer or seize that role - it's slightly outside my experience.
joshmdillAuthor Commented:
Yes the new 2003 server is pointing to itself for DNS as are the workstations.
Steve KnightIT ConsultancyCommented:
Did sounds like DNS.  Are you in the Schema Admins / Enterprise Admins groups?  Perhaps an idea to run a DCDIAG over it.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Active Protection takes the fight to cryptojacking

While there were several headline-grabbing ransomware attacks during in 2017, another big threat started appearing at the same time that didn’t get the same coverage – illicit cryptomining.

feptiasChief DudeCommented:
DCDIAG is a good idea. It might show you straight away where the problem is.

You could also take a look at the following:
1. Can you check the DNS forward lookup zones on the new server using the DNS Management Console. There will be a fwd lookup zone with the same name as your Windows AD domain. Does it contain sub-folders with names like _msdcs and _sites? Under the _sites sub-folder there should be further sub-folders like this: domain_name -> _sites -> site_name -> _tcp  and in that folder there should be SRV records for ldap gc and kerberos. Please check that these are present.

2. If you open the AD Sites and Services console, look under sites. There should be a folder for the site containing a sub-folder for servers. What is shown in that sub-folder?

joshmdillAuthor Commented:
I should be on-site later today and I'll run DCDIAG as well as check those DNS keys you suggested feptias.  Thanks in advance for the advice, I'll let you know how I make out.
joshmdillAuthor Commented:
Okay, updated information on the problem:

I ran DCDIAG on the new 2003 server (\\EWTSV) and got good tests EXCEPT for the netlogon share test.  Apparently the new server is not advertising itself as a domain controller to the forest.  DCDIAG reports the new server does not have a NETLOGON share or SYSVOL share active.  I looked up the error code and found a Microsoft technote that prompted me to run NET SHARE to verify that the server has SYSVOL and NETLOGON shares.  DCDIAG was correct and the new server does NOT have these shares.

I checked our event log under NTFRS and saw the following:

Event Type: Warning
Event Source: NtFrs
Event Category: None
Event ID: 13508
Date:  11/9/2006
Time:  5:50:59 PM
User:  N/A
Computer: EWTSV
The File Replication Service is having trouble enabling replication from EWTWIN2KSVR to EWTSV for c:\windows\sysvol\domain using the DNS name EWTWIN2KSVR.ewt.local. FRS will keep retrying.
 Following are some of the reasons you would see this warning.
 [1] FRS can not correctly resolve the DNS name EWTWIN2KSVR.ewt.local from this computer.
 [2] FRS is not running on EWTWIN2KSVR.ewt.local.
 [3] The topology information in the Active Directory for this replica has not yet replicated to all the Domain Controllers.
 This event log message will appear once per connection, After the problem is fixed you will see another event log message indicating that the connection has been established.

For more information, see Help and Support Center at

As you can probably guess, the new server is named EWTSV and the old server is EWTWIN2KSVR.  I ran the tests outlined in the eventlog details online help.  The old server DOES have the NTFRS service running, and the new server IS able to resolve the old server's FQDN so I believe that DNS is correctly configured, though I haven't ruled that out completely.

I checked the event log on the old server (EWTWIN2KSVR) and saw an error event under NTFRS.  It's that infamous "JRNL_WRAP_ERROR" which I've seen referenced in a few other technotes here on Experts-Exchange.  I followed the procedure outlined by Microsoft to add a registry key that would recover FRS from the error state and reset the system volume replication set.  I waited the five minutes for the polling to cycle and the old server reported that FRS was ready to replicate the SYSVOL once again.  10 Minutes passed and I hadn't seen any activity in the event log on the new server (EWTSV) but the old server (EWTWIN2KSVR) displayed the EventID 13508 "...having trouble enabling replication between server..." again.  (Same event as above.)

I let the servers sit overnight hoping the replication would resolve itself but this morning the status is the same.  However, there's still no new events in the new server's log and no new entries in the old server's log since the latest replication warning from last night.

I'm at a complete loss now.  I'm not sure what steps to take next, but I think I've at least narrowed the problem down.  I need to get the system volume information for the domain to replicate to this new server so it can act as a logon server then everything should be be 5-by-5.  Any ideas?
feptiasChief DudeCommented:
I am not going to pretend to have the expertise to resolve problems with replication of Sysvol and Netlogon shares between DC's, although I posted a request for help with this question on another thread that is monitored by the more experienced experts in this TA. Hopefully you will get some feedback from one of them.

In the situation you have, I would be tempted to move all the FSMO roles back onto the old server, then demote the new one so it is no longer a DC and then start again from the beginning. If you follow this course of action, before you DCPROMO the new server I recommend that you do the following:
1. Set its Preferred DNS server to point to the old DC, EWTWIN2KSVR.
2. Make sure the new server is already joined to the domain
3. Make sure that the security settings on the DNS server on EWTWIN2KSVR allow the new server EWTSV to make "Dynamic updates" to the forward lookup zone for the domain
4. On the same DNS server, make sure the Type shown for the fwd lookup zone of the domain is set to Active Directory-Integrated
5. Now use DCPROMO to add EWTSV as a DC to the existing domain

After you have promoted the new server to be a DC, you can then install or enable DNS on the new server. Just add a new forward lookup zone for the domain and set it to AD-Integrated and it will automatically pick up a complete copy of the DNS information from the old DC. Then change the Preferred DNS server on EWTSV to point to itself. Test that the new DC is working correctly - e.g. by running DCDIAG and then perhaps running the network with the old DC switched off (workstations will need to be made aware of the alternate DNS server now running on the new DC before you switch off the old one). Finally, if the new one is looking alright then transfer the FSMO roles to it.

Hope this helps.
joshmdillAuthor Commented:
I actually was thinking along those same lines and I did demote the new server and re-install Active Directory yesterday.  I'm once again at the same place.  Still no new event logs on the new server and just the warning about NTFRS on the old server.  Thanks for your suggestion though Feptias, it was worth a shot.
feptiasChief DudeCommented:
Did you keep all DNS on the old server while promoting the new DC in the way I suggested? It still sounds like a problem with DNS is at the heart of the problem. Also, what is shown in the Domain Controllers folder in ADUC and the Sites>Servers folder in AD Sites and Services after you promote the new DC?

When you run your dcdiags on both servers, does anything DNS related error out at all?

You may be looking at needing to seize roles but that will be last resort and we need to get all your data moved across first.could you post a dcdiag for me please
joshmdillAuthor Commented:
Well, here's the weird part.  I left the servers alone for a few days and we checked on them again yesterday.  The new server has now replicated the system volume information from old domain controller and DCDIAG passes it for all tests.  I'm going to transfer the MO roles to the new server tonight and down the old server for good.  Thanks for all the input and suggestions guys.  I think we're in the clear now!
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2003

From novice to tech pro — start learning today.