Link to home
Start Free TrialLog in
Avatar of mwiesauer

asked on

Sysvol not replicating

one of our clients has 4 DCs (3 DCs are running on windows 2003). when promoting the first 2008 DC i noticed that the sysvol was not replicating at all. transfering FSMO to the 2008 went all well and i can browse AD.
however i have checked the eventlog on the former FSMO master (2003 server) and have seen that the sysvol was throwing errors for a long time.

The File Replication Service has detected that the replica set "DOMAIN SYSTEM VOLUME (SYSVOL SHARE)" is in JRNL_WRAP_ERROR.

all other DCs have sysvol not properly synced, so i will need to use the old server as my reference.

my idea is to stop FRS service on all the DCs and set the Bur Flag on my reference DC to D4. then start FRS on the reference server and set the Bur Flag on all other DCs to D2 and start FRS one by one.

as i have never done this before, i am not sure, if i will loose information and if this will work as expected, as because of a not working sysvol nobody can logon to the domain.

as the old servers are physical this will even complicate it more. i tried to restore them on a VM and replcing system state, but have not had much success with this and a P2V conversion of a DC i want to avoid.

any help is greatly appreciated.
Avatar of Metaltree
Flag of United States of America image

Set the BurFlag on the server you are receiving the JRNL errors on (probably the new 2008 dc)

Once you do this, give it at least 30 minutes to an hour, depending on your site setup I've seen it take longer.

Also, make sure your Sites are setup properly as well if this is at another site
Avatar of mwiesauer


i am receiving errors on all the DCs. none of them can replicate. 2 DCs do not even have the sysvol share created.
Do you setup AD Sites & Services properly?
Avatar of Metaltree
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial

the two servers that do have the sysvol shared - should i set them to D4?
what to do, with the ones that do not have it shared? - just keep them as they are.
can i expect any problems with this??
Only perform the D4 flag on the two servers that do NOT have the sysvol share.

The servers that DO have the share, leave them alone.

There will be no problems, it will either fix the issue or it won't.
will this also help with the servers that have the sysvol shared and come up with the JRNL_WRAP_ERROR. what will be my reference, as the DCs what have it shared have different versions.... i thought that D4 makes the one as a reference.

sorry, but i want to plan this carefully and know the steps i am doing...
Yes, because if you look at the Sites & Services you'll see microsoft automatically chooses which DC replicates with which DC, so its a domino effect.

Perform a D2 flag first if you feel more comfortable, ONLY on the servers NOT replicating.

You can also perform this on the DC with the INCORRECT version of the sysvol.
thank you.

so, stop FRS on the 3 servers with incorrect sysvol and not shared sysvol.
D2 on the 3 servers.
restart FRS on the 3 servers. keep the one with correct sysvol untouched.

just in case, this does not work - try D4 on the 3 servers and keep the working one untouched.

Plan B if this also does not fix it?
In my opinion, Plan B would be to call Microsoft. However, I've always been able to fix JRNL_wrap issues with burflags.

What I would do is go into AD Sites & Services and find out which DCs are directly replicating with the DC that has the CORRECT sysvol share. I would perform the BurFlag on those servers first.

Then I would continue to the others.

I will give this a try. just to make sure: try D2 first, if it does not work try it again with D4.

Thank You!
Avatar of Darius Ghassem
Darius Ghassem
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
so, this was my plan too, but it is a different procedure than metaltree explained.
i am a little confused now... sorry..
Well you must have a authrotive system to replicate the SYSVOL from within a multiple DC environment the procedure I posted is the way this would work. I have used this procedure many and times. Plus I have posted this on many questions on EE.
good, then i will try this. i saw some of the questions, but i thought it may be better asking again, to make sure, as in my opinion it is too critical if users can not logon, what is the case while the sysvol is not available.
by the way. none of the DCs has proper sysvol. the all have errors. also the one what i want to use as a reference (where i know, the sysvol is there and shared correctly) has the JRNL_ERROR
Look at the actual share... \\dc\sysvol - which one has the CORRECT files in it? The one that does is your AUTHORITATIVE
And if none of them do then you go with the lesser evil which would be your server holding the PDC role
3) Accept one or more comments as the solution.

I believe dariusg and I should split points evenly
I have chosen the solution from dariusg, because he gave me the correct answer to fix it, and make only one server the authoritative setting the D4 flag and then replicate the others setting the D2 flag. He confirmed, what i was asking in my original question.
I originally told you to set the D4 flags on the servers not operating properly. The expert awarded the points made it clear.. "To add to the others here this is the correct procedure that should be run." I'm confident this would have resolved the issue without a D2 flag on the authoritative server.