03 Domain Controller Issue

tstrip007

Have a 2003 DC throwing the following error.

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

This is effecting things like group policy and who knows what else. My research has lead me to this troubleshooting fix. Just wondering is anyone has had to do this and if their is anything I should know before attempting.

Fieldbrook Solutions - Brad's TechTips for Windows - Clear the Journal Wrap Error in File Replication Service

Thanks,

GAngel

Can't say without looking at all the logs that's usually where you will find out whats happening. Check for other recurring errors around the same time.

I'd be more worried about end of life on that OS if it were me personally.

Deathmage

make sure the DC in question can replicate correctly.

go to command prompt and type this:

"Repadmin /syncall DC_name /APed"

By running a repadmin /syncall with the /A(ll partitions) P(ush) e(nterprise, cross sites) d(istinguished names) parameters will check to make sure replication is happening correctly with all DC's in forest.

tstrip007

I knew I could count on the security guys to mention the end-of-life. Yes, Im am gearing up for a DC upgrade.

Deathmage, thanks, ran the command against all three of my DC's and got the "syncALL terminated with no errors".

I may run a chkdsk on the primary partition incase there is any corruption going on before I mess with the registry.

Deathmage

tstrip007 wrote: »

I knew I could count on the security guys to mention the end-of-life. Yes, Im am gearing up for a DC upgrade.

Deathmage, thanks, ran the command against all three of my DC's and got the "syncALL terminated with no errors".

I may run a chkdsk on the primary partition incase there is any corruption going on before I mess with the registry.

Well that's a good sign that the DC's are replicating correctly. It's probably a isolated issue with that server.

Chkdsk is good, was going to say to run it to make sure system .dll's were good.

What I'd do is run DCpromo and make sure that starts correctly.

Also if you can transfer the operations masters on that DC to a different server and once that's done if you can demote then promote the server. Check out a post I made on my blog on the command to check the Operations Masters: http://g15it.com/?page_id=242

Ideally if you do it after hours and keep the same name and IP end users shouldn't see it. But it sounds like a AD corruption sort of like a workstation trust issue where you need to leave a domain and then go to workgroup and revert to domain same concept just with dcpromo for a DC.

Although it's only possible to transfer if you have more than 1 DC. I have 3 at my job, one physical two virtual.

Does this issue affect all your DC's or just one of them?

tstrip007

Thanks deathmage, yah this is starting to NOT look like a replication issue. I was testing a new, user based, group policy. New OU, new user, new policy that runs a logon script. When I log in as that user I am not able to gpupdate /force. I get a message stating "the processing of group policy failed...". I run the suggested 'gpresult /h gpreport.html' and get a message stating the user "DOMAIN\user" does not have RSOP data.

I orig thought that this may have been a replication issue because when I ran SET command to determine logonserver, that DC had some replication errors but none in two months.

I am not rushing to get this fixed as the def domain policies and other important GPO's seem to be working. But I am going to spend some time today working out this issue.

Deathmage

tstrip007 wrote: »

Thanks deathmage, yah this is starting to NOT look like a replication issue. I was testing a new, user based, group policy. New OU, new user, new policy that runs a logon script. When I log in as that user I am not able to gpupdate /force. I get a message stating "the processing of group policy failed...". I run the suggested 'gpresult /h gpreport.html' and get a message stating the user "DOMAIN\user" does not have RSOP data.

I orig thought that this may have been a replication issue because when I ran SET command to determine logonserver, that DC had some replication errors but none in two months.

I am not rushing to get this fixed as the def domain policies and other important GPO's seem to be working. But I am going to spend some time today working out this issue.

if it's failing with gpresult I'd run the GPOM Modelling tool and see where it's failing.

Question: Are you using just the "Authenticated Users" setting or you using the administrative flag for specific servers/PC's IE: "servername$" - sometimes GPO's can be wonky. See if setting it with the administrative name for the the specific server in question that is having an issue helps. It essentially forces the GPO to the server without ticking the Enforced option which is a global option, the "$" forces the server to use the 'SAM Account Name'; the kool thing about the "$" command that not many people know about is it will bypass the computer configuration (which requires a reboot) and sets the GPO to the server right then and there so you can without a reason of doubt know if the GPO 'CAN' Apply.

I learn so much at my last job that had over 45 GPO's that GPO's are my bread-n-butter in AD now. - I love fixing GPO issues, some people dread them, lol!!!!

Funny how in the certification exams for Microsoft they never are wonky, they are the perfect child but in our real-world land "reality" they never are, lol!

Claymoore

Been a long time, but you will need to fix the journal wrap. I had an issue with disk IO on a multipurpose domain controller that resulted in a journal wrap and it prevented sysvol replication. So any group policy changes or account changes are not synchronizing there. If you made any specific GPO modifications and were using that server as the DC, they may be gone.