SYSVOL & NETLOGON replication issues

--chris--

I am starting to slow down on troubleshooting a SYSVOL replication issue, anyone have some good methods for figuring these out?

I have tried a non-authoritative synchronization of sysvol without any luck. I am waiting for the business to close today to try an authoritative synchronization of sysvol. If that fails to fix the replication, I am quickly running out of ideas.

I am migrating from 2003R2 to 2008R2 and this is holding me up...

Deathmage

--chris-- wrote: »

I am starting to slow down on troubleshooting a SYSVOL replication issue, anyone have some good methods for figuring these out?

I have tried a non-authoritative synchronization of sysvol without any luck. I am waiting for the business to close today to try an authoritative synchronization of sysvol. If that fails to fix the replication, I am quickly running out of ideas.

I am migrating from 2003R2 to 2008R2 and this is holding me up...

A few things I'd check right off the bat:

replication and GPO is my bread-n-butter, I did it all the time at my last job; we had over 45 GPO's and they used to cause all kinds of issues in regards to schema and the infrastructure master and Global Catalog.

1) Have you tried a "gpupdate /force"? ... sometimes sysvol takes a while to replicate if a GPO is in fault, usually about 5 minutes by default; if you use the force command it makes it faster, however this won't work if you have a confliction with a top level gpo.

2) if you have 2008 R2 make sure you don't have any GPO's that are in fault, this can cause sysvol to conflict with the schema/infrastrucutre master. I've seen it happen way too many times before at my last job. I'm a huge advocate of the GPO modeller and how it will affect things if you change settings.

3) something else check "sites and services" and see if you can do a forced replication, if you can't look at the individual server and check to make sure VSS as an example isn't running; if a volume is locked from a in-progress backup it will prevent replication.

4) another step, open up command prompt into a elevated command prompt and run "replmon now" command to force replication. also use the "check replication topology" in dssite.msc

5) run these commands to make sure replication is happening, with repadmin.exe:

REPADMIN /SHOWREPS %UPSTREAMCOMPUTER%
REPADMIN /SHOWREPS %DOWNSTREAMCOMPUTER%

6) something else to try, all DC's must be able to resolve the other, so make sure there is no event logs with AD replication errors, make sure DNS records can resolve the name and the IP address. if they can't that's a problem.

7) Each DC must be a member of the replica set; run "NTFRSUTL DS [COMPUTERNAME]" in an elevated command prompt. make sure all DC's show up in the "SET: DOMAIN SYSTEMVOLUME (SYSVOL SHARE)" section of NTFRSULT.

the only other thing I can possible think of is if the sysvol folder is placed in a location where a Exchange log or SQL log is located and it's grown to the point that a disk quota has come into affect and prevent anymore data to be written to the partition; this can cause issues. if that's the case move the Exchange logs to an external. on the same token make sure the winevt folder in system32 doesn't have a bazzillion event logs taking up space on the C drive; I've seen that cause replication issues....

I know it's a big list, but I used to deal with these issues religiously...

hope this helps!!!!!

--chris--

Deathmage wrote: »

A few things I'd check right off the bat:

replication and GPO is my bread-n-butter, I did it all the time at my last job; we had over 45 GPO's and they used to cause all kinds of issues in regards to schema and the infrastructure master and Global Catalog.

1) Have you tried a "gpupdate /force"? ... sometimes sysvol takes a while to replicate if a GPO is in fault, usually about 5 minutes by default; if you use the force command it makes it faster, however this won't work if you have a confliction with a top level gpo.

2) if you have 2008 R2 make sure you don't have any GPO's that are in fault, this can cause sysvol to conflict with the schema/infrastrucutre master. I've seen it happen way too many times before at my last job. I'm a huge advocate of the GPO modeller and how it will affect things if you change settings.

3) something else check "sites and services" and see if you can do a forced replication, if you can't look at the individual server and check to make sure VSS as an example isn't running; if a volume is locked from a in-progress backup it will prevent replication.

4) another step, open up command prompt into a elevated command prompt and run "replmon now" command to force replication. also use the "check replication topology" in dssite.msc

5) run these commands to make sure replication is happening, with repadmin.exe:

REPADMIN /SHOWREPS %UPSTREAMCOMPUTER%
REPADMIN /SHOWREPS %DOWNSTREAMCOMPUTER%

6) something else to try, all DC's must be able to resolve the other, so make sure there is no event logs with AD replication errors, make sure DNS records can resolve the name and the IP address. if they can't that's a problem.

7) Each DC must be a member of the replica set; run "NTFRSUTL DS [COMPUTERNAME]" in an elevated command prompt. make sure all DC's show up in the "SET: DOMAIN SYSTEMVOLUME (SYSVOL SHARE)" section of NTFRSULT.

the only other thing I can possible think of is if the sysvol folder is placed in a location where a Exchange log or SQL log is located and it's grown to the point that a disk quota has come into affect and prevent anymore data to be written to the partition; this can cause issues. if that's the case move the Exchange logs to an external. on the same token make sure the winevt folder in system32 doesn't have a bazzillion event logs taking up space on the C drive; I've seen that cause replication issues....

I know it's a big list, but I used to deal with these issues religiously...

hope this helps!!!!!

Huge help!!

thanks, I'll report back if one of these fixes it.

gespenstern

Often happens because of ntfs journal wrap-up. If your ad replicates well while ntfrs doesn't do authoritative restore, but you have to determine which sysvol to use as authoritative copy. I mean, someone could have added some GPOs on some servers and they aren't replicated so your best bet is to use the most up to date sysvol (provided that it's not the one that contains files for accidentally deleted GPOs). Once it is determined just do what MS suggests (search for "burflags D4 D2"). Done that tens of times for clients.

Once you are on 2008 you best choice is to use DFSR for file peplication, NTFRS sucks. File replication isn't upgraded automatically, it's inherited from 2003 domain and DFSR is used only for brand-new. But there's a migration path (search for "sysvol dfsrmig.exe"), pretty simple, done that times of times for clients.

--chris--

gespenstern wrote: »

Often happens because of ntfs journal wrap-up. If your ad replicates well while ntfrs doesn't do authoritative restore, but you have to determine which sysvol to use as authoritative copy. I mean, someone could have added some GPOs on some servers and they aren't replicated so your best bet is to use the most up to date sysvol (provided that it's not the one that contains files for accidentally deleted GPOs). Once it is determined just do what MS suggests (search for "burflags D4 D2"). Done that tens of times for clients.

Once you are on 2008 you best choice is to use DFSR for file peplication, NTFRS sucks. File replication isn't upgraded automatically, it's inherited from 2003 domain and DFSR is used only for brand-new. But there's a migration path (search for "sysvol dfsrmig.exe"), pretty simple, done that times of times for clients.

I came back here to update this thread and you beat me to it!

It ended up getting fixed with the burflag hack, and in the end it was a journal wrap issue that held it up.

I making a PDF of this thread for future reference, I have about 20 more of these to do this year. Thanks a lot guys!

rsutton

The burflag fix has saved me a few times as well. Enjoy having less replication problems with 2008.