SYSVOL not being shared after a DCPROMO

Which log errors do you get on the server under system and Directory Service?

Hi

This is the strnage thing.  We are seeing very little if any errors in the logs.  The last error I have in directory services is the following

Source: NTDS General
Category DS Schema

Internal event: The following schema class has a superclass that is not valid.
 
Class identifier:
347668519
Class name:
msExchOmaConnector
Superclass identifier:
943664868
 
Inheritance was ignored.

Try this https://www.experts-exchange.com/questions/24453125/Adding-a-Second-Domain-Controller-LsaPolicy-operation-failed-with-error-1203.html?sfQueryTermInfo=1+24323148

You probably didn't register SRV records after bringing the server on line as a DC.

https://www.experts-exchange.com/articles/OS/Microsoft_Operating_Systems/Server/2003_Server/There-are-currently-no-logon-servers-available-to-service-the-logon-request.html

Hi all

Still no joy.  Tried all of the suggested in articles previosly and still getting the attached.

Thx
Al


dcdiag2.txt

Dcdiag can be somewhat cumbersome to translate.

What do your event log errors say? Look in the FRS event logs as well.

Hello all

* DOMAIN REMOVED*

We see the following when we run the ntfrsutl sets cmd on all of our DC's in our primary site.

C:\Documents and Settings\*removed*>ntfrsutl sets
ACTIVE REPLICA SETS

DELETED REPLICA SETS

C:\Documents and Settings\*removed*>

Along with this from another DC's Directory logs

Event Type:      Information
Event Source:      NTDS KCC
Event Category:      Knowledge Consistency Checker
Event ID:      1272
Date:            22/07/2009
Time:            08:35:07
User:            NT AUTHORITY\ANONYMOUS LOGON
Computer:      PIXIE
Description:
The following directory partition is no longer replicated from the source domain controller at the following network address because there is no Connection object for the domain controller.
 
Directory partition:
DC=ForestDnsZones,DC=*REMOVED*,DC=local
Source domain controller:
CN=NTDS Settings,CN=VBCA51DC01,CN=Servers,CN=*REMOVED*,CN=Sites,CN=Configuration,DC=*REMOVED*,DC=local
Network address:
16882dc5-bf68-4676-9f6f-8787b173c068._msdcs.*REMOVED*.local

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

From the FRS log on the DC we are trying to DCPROMO

Event Type:      Warning
Event Source:      NtFrs
Event Category:      None
Event ID:      13508
Date:            22/07/2009
Time:            08:32:07
User:            N/A
Computer:      VBCA51DC01
Description:
The File Replication Service is having trouble enabling replication from *REMOVED*02 to VBCA51DC01 for c:\windows\sysvol\domain using the DNS name *REMOVED*02.*REMOVED*.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 *REMOVED*.*REMOVED*.local from this computer.
 [2] FRS is not running on *REMOVED*.*REMOVED*.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 http://go.microsoft.com/fwlink/events.asp.
Data:
0000: 05 00 00 00               ....    


Also please find attached ntfrsutl sets output from the server we are trying to promote as well.




ntfrsutl-sets.txt

Do you have an old DC that you removed. Or is this DC having problems with DNS.

The MSDCS file folder that this is talking to is a DNS folder. Is it greyed out? If so, that file folder holds DNS delegation records and/or SRV records for DNS that point the way to your FRS replication partners.

If it has been removed, you need to do a DNS and FRS metadata cleanup.

Either way this is an easy fix.

Found a couple links to point out where I am going with this.

Example of the problems with the MSDCS file folder:
https://www.experts-exchange.com/questions/24349599/URGENT-MSDCS-records-registering-directly-under-FWD-lookup-zone-not-under-FQDN-name-space.html

How to perform metadata cleanup of a non-gracefully removed domain controller:
http://www.google.com/search?q=metadata+cleanup+petri&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

Hi Chief

Thanks for the info

We have had some DNS issues in the past although everything 'appears' to be stable right now.  I cannot find any evidence of the MSDCS file folder being in the wrong location.

Equally we have not removed any DC's in the recent past and have performed metadata cleanups just to be certain that there are now old devices lurking around.

However what I can say is that as if by magic the DC is now sharing the SYSVOL.  Now this does raise another question.  Originally the new DC was trying to replicate with DC's here in this site however I removed those from the NTDS settings and forced replication from a wroking DC on another site.  left it overnight and BINGO it's now shared.  BUT my concern is that as can be seen (as indicated in my last post) is that ALL DC's in the primary site show no replica sets when running ntfrsutl.  Equally when I run SONAR I don't see nay of these devices under our .local domain.  This I believe to be quite serious as two of the devices are role holders.

I am certain we still have an issue but I am now at the limits of my knowledge.

Thanks

There are two MSDCS file folders within DNS. One is a delegation record, and will be found in your forward lookup zone. The second will be a MSDCS.yourdomain.name forward lookupzone. That one holds the SRV records, (to include the SRV records used for FRS).

Here is how that works. Microsoft, in its infinite wisdom made the first domain in the forest create both folders so these records so the SRV records of the first domain DNS server could easily be replicated to other DCs in the forest. The problem is, they don't update the delegation record and it becomes greyed out, as in my example.

From what I am seeing, in your case, you may have a problem with your DNS SRV records getting replicated from one DC to the other within the forest.

Hi Chief

Ok the delegation recored I have, which is to say the file folder under my domain forward lookup the _msdcs record containing dc, domains, gc and sites.

What I cannot locate is the msdcs.mydomain.local folder!!  See attached please.  So I think it is safe too say we do have a DNS issue.

Something I have also just noticed (I have had a lot of very long nights and not a lot of sleep) is that when checking the site links in sites and services I seem some servers using a Replicated naming Context of ForestDnsZones.mydomain.local and some using mydomain.local.  Again I am really at the limits of my knowledge but I would say that doesn't appear to be correct.

Thx for your ongoing help.
dns.jpg

NO, that's not true:

What you are looking at are the SRV records.

Remember the first DC in the forest will create two file folders, (MSDCS). One will be a delegation record, the second will be the actual SRV records.

Those records look fine!!

On both servers, let's make sure these Records are working well.

Go to the command prompt of both servers and type:

IPconfig /flushdns
IPconfig /registerdns
net stop netlogon
net start netlogon

Then, go to Active directory sites and services and force replicate from one dc to the other.

If that doesn't work, we may need to reset the replication set by using the burflag method. Warning: watch out of this. If you have 2003 server R2 or a 2008 server, you should not be using the burflag method to reset replication.

Hi Chief

We had already done all of the above and also the burflag method before I started this post :0(

Equally we don't have any replicate sets on the DC's in this site anymore!

To give you some more background on the domain we are talking about 17 sites all link by VSAT with 4 DC's in this, the primary.  NTDS replications is working fine NTFRS is not.

Thx

Chief

As it turned out after much head scratching this was a combination of both DNS, Metadata and the burflag routine not being followed correctly; it's a wonderful thing when people actually tell you the truth instead of making up an excuse don't you think?

Anyway I am happy to award you all the points as al of your comments and suggestions resulted in the final solution.  Sorry it took so long!

OIWA

All being good is the important part. Points are just ones and zeros on a computer somewhere.

Any additional assistance required??