Exchange 2010 SP2 2 host DAG.

The mounted database has a clean shutdown state.

I reseeded the database copy and that was sucessful.

However when it tries to do resynchronizing the copy queue length continues to grow and it fails.

I'm also seeing this in the logs

The active copy of Mailbox Database Faculty has a missing or corrupted log file (E030042A9B0.log). To keep this copy healthy, replication will restart at generation 4368817. A full backup must be performed before an incremental backup is possible.

Should I delete the database copy and create a new one and let it reseed?

The Exchange 2010 Forum is http://social.technet.microsoft.com/Forums/en-US/home?forum=exchangesvravailabilityandisasterrecoverylegacy

The problem you're running into is called Source Log Corruption. What's happening is that log E030042A9B0.log is corrupt. It can't be replayed into either a passive copy or a backup. If you caught this right away (and knew what it was) you could have forced a lossy failover to one of the passive copies and then reseeded the old active.

When you seed the passive copy the copy will have the required range of the seeding source at the point of time that the seed began. But when it's done seeding and starts copying logs, it doesn't start copying logs at it's required range, it starts copying every log it can find. So even though the newly seeded copy doesn't need E030042A9B0.log it still tries to copy and inspect it (which is where it's failing).

So what you can do is run Update-MailboxDatabaseCopy -ManualResume, and once it's complete use eseutil.exe to check the required range of the copy. Then manually copy the required range over to that copy yourself. Then Resume-MailboxDatabaseCopy, and the copy will start copying from that point on, working around the corrupt log on the source.

Ok so my original copy is fine. I removed the second copy and created a brand new copy. WIll this work?

No, the code for copying log files is the same code, whether it's an existing copy or a new one.

I'm not following you. I have one good database copy and one that won't rebuild because of corrupt logs.

How can you make a copy of the working database without the logs?

The Exchange 2010 Forum is http://social.technet.microsoft.com/Forums/en-US/home?forum=exchangesvravailabilityandisasterrecoverylegacy

The problem you're running into is called Source Log Corruption. What's happening is that log E030042A9B0.log is corrupt. It can't be replayed into either a passive copy or a backup. If you caught this right away (and knew what it was) you could have forced a lossy failover to one of the passive copies and then reseeded the old active.

When you seed the passive copy the copy will have the required range of the seeding source at the point of time that the seed began. But when it's done seeding and starts copying logs, it doesn't start copying logs at it's required range, it starts copying every log it can find. So even though the newly seeded copy doesn't need E030042A9B0.log it still tries to copy and inspect it (which is where it's failing).

So what you can do is run Update-MailboxDatabaseCopy -ManualResume, and once it's complete use eseutil.exe to check the required range of the copy. Then manually copy the required range over to that copy yourself. Then Resume-MailboxDatabaseCopy, and the copy will start copying from that point on, working around the corrupt log on the source.

• Proposed as answer by Simon_WuMicrosoft contingent staff, Moderator Friday, July 12, 2013 5:29 AM

You make a copy of the working database by copying the database file, not the logs.

Seeding a database makes a copy of the .edb file, it doesn't care about the logs at all. The part of the process that's tripping up your copy right now is the stage between copying the .edb file and catching up with all of the logs. The seeded copy is copying more logs than it needs to (from the point of view of just itself), so you need to convince it to start copying at a later point in the log stream.

You make a copy of the working database by copying the database file, not the logs.

Seeding a database makes a copy of the .edb file, it doesn't care about the logs at all. The part of the process that's tripping up your copy right now is the stage between copying the .edb file and catching up with all of the logs. The seeded copy is copying more logs than it needs to (from the point of view of just itself), so you need to convince it to start copying at a later point in the log stream.

• Marked as answer by Simon_WuMicrosoft contingent staff, Moderator Thursday, July 18, 2013 7:07 PM

What is the eseutil command to check the required range of the copy?