SYSVOL not being shared after a DCPROMO

OIWA used Ask the Experts™
We are having problems adding a new DC to our domain.  We have been trying for some days now to add the server and it has been rebuilt twice.  When the server is dcpromo it's appears for all intensive purposes to be working fine, however the SYSVOL fails to share.  Attached is the output from DCDIAG
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®

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



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:
Class name:
Superclass identifier:
Inheritance was ignored.
How to Generate Services Revenue the Easiest Way

This Tuesday! Learn key insights about modern cyber protection services & gain practical strategies to skyrocket business:

- What it takes to build a cloud service portfolio
- How to determine which services will help your unique business grow
- Various use-cases and examples


Hi all

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



Dcdiag can be somewhat cumbersome to translate.

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


Hello all


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


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
Computer:      PIXIE
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:
Source domain controller:
CN=NTDS Settings,CN=VBCA51DC01,CN=Servers,CN=*REMOVED*,CN=Sites,CN=Configuration,DC=*REMOVED*,DC=local
Network address:

For more information, see Help and Support Center at

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
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
0000: 05 00 00 00               ....    

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


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:

How to perform metadata cleanup of a non-gracefully removed domain controller:


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.


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 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.

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.

Oh, I see. It doesn't get much more complicated when dealing with a flat domain in comparison to a multiple site domain.

Burflag should have re-written the sysvol and netlogon share, then restarted the replication between that server you performed the burflag on and its replication partner. I assume you started the authoritative bur flag for that site's PDCe and for the other DCs, you would do a non-authoritative restore of the sysvol and netlogon shares, (only performing this burflag one server at a time).

I was assuming we were talking about one site (flat domain). So, are all 17 sites as one domain, or do they all belong to different domains in a forest?

If you are having site to site replication, we should probably check AD sites and services and make sure DNS isn't problematic between the sites. If you are having problems with this one site, we should check DNS and FRS on that one site. Can you perform NSlookup between sites. This will tell us if DNS is blocked between them.

Check the domain using DCdiag /v for DNS and AD sites/services problems.

We should look for metadata of a server that no longer exists. These errors pop up when trying to replicate to a non-existant DC and will stop the FRS services, causing journal wrap.



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!


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

Any additional assistance required??

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial