Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
?
Solved

Newly promoted DCs aren't creating SYSVOL/NETLOGON

Posted on 2013-01-18
3
Medium Priority
?
6,697 Views
Last Modified: 2013-01-19
Experts, I've been fighting a new problem all night.  Googling around for different answers has not led me down a path that has led to resolution yet.

I'll get right to the symptoms:

  -  In a 2012 virtual environment, (DCs are server 2012) - any new DC that's stood up does not create the SYSVOL/NETLOGON shares.

  -  These are completely new DCs, in the same AD site.

  -  There are no problems with replication.  "repadmin /replsummary" shows me that everything is fine between every server.

  -  "dcdiag" is showing an error on each of the new DCs:
   Testing server: SITE\SERVERNAME
      Starting test: Advertising
         Warning: DsGetDcName returned information for
         \\WORKINGSERVER.DOMAIN.COM, when we were trying to reach NEWSERVER.
         SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.

      Starting test: DFSREvent
         There are warning or error events within the last 24 hours after the
         SYSVOL has been shared.  Failing SYSVOL replication problems may cause
         Group Policy problems.

      Starting test: NetLogons
         Unable to connect to the NETLOGON share! (\\NEWSERVER\netlogon)
         [NEWSERVER] An net use or LsaPolicy operation failed with error 67,
         The network name cannot be found..

Open in new window


  -  All other tests check fine with "dcdiag".

  -  I have one working DC (original), that does not experience these issues.  This is on any newly promoted DC (I've stood up about 5 new ones that I've been troubleshooting).

//===================================================

For troubleshooting, here are a few steps I've already accomplished.

 -- I know DNS is supposed to have the DNS pointing to itself as primary / and secondary to another DC, but for testing I've got all of the new servers currently pointing a single DNS entry to the working server.

 -- I've demoted cleaned out AD metadata using ntdsutil / adsiedit / sites & services, then repromoted a couple of the new DCs.

-- DNS checks fine, in that the new servers are creating correct entries in _msdcs.domain.com, as well as the forward lookup zone for the domain.



I really am at a loss here, as I don't understand why this is happening.  I would completely understand if these were servers that may have existed before in the domain, but they're not - every new server I stand up and promote to be a DC is showing this exact same problem.

Would anybody happen to have any ideas?
0
Comment
Question by:usslindstrom
  • 2
3 Comments
 
LVL 4

Accepted Solution

by:
Haslerct earned 2000 total points
ID: 38795604
Is the servers harden before the promotion as dc?

Network/os Firewall losses up between all dc and the server you want to promote?
0
 
LVL 5

Author Comment

by:usslindstrom
ID: 38795621
Thanks for jumping in here.  Let me answer your questions.

Is the servers harden before the promotion as dc?
     No sir.  These are base installs of 2012.

Network/os Firewall losses up between all dc and the server you want to promote?
     I have no firewall between the servers, they're all on the same L2 segment.  All of the ports required for AD are open as well.

//List of required ports:

    UDP Port 88 for Kerberos authentication
    UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations.
    TCP Port 139 and UDP 138 for File Replication Service between domain controllers.
    UDP Port 389 for LDAP to handle normal queries from client computers to the domain controllers.
    TCP and UDP Port 445 for File Replication Service
    TCP and UDP Port 464 for Kerberos Password Change
    TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
    TCP and UDP Port 53 for DNS from client to domain controller and domain controller to domain controller.

All ports are listening on the "good" DC as well as the "bad" ones.

Open in new window

0
 
LVL 5

Author Closing Comment

by:usslindstrom
ID: 38797639
I've been able to find the solution after all.

In my particular case, I had to follow the instructions layed out here:

http://support.microsoft.com/kb/947022?wa=wsignin1.0

It involved resetting the SYSVOL ready flag.
0

Featured Post

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

Question has a verified solution.

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

Windows Server 2003 introduced persistent Volume Shadow Copies and made 2003 a must-do upgrade.  Since then, it's been a must-implement feature for all servers doing any kind of file sharing.
A bad practice commonly found during an account life cycle is to set its password to an initial, insecure password. The Password Reset Tool was developed to make the password reset process easier and more secure.
This tutorial will show how to configure a new Backup Exec 2012 server and move an existing database to that server with the use of the BEUtility. Install Backup Exec 2012 on the new server and apply all of the latest hotfixes and service packs. The…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…

564 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