Archive for the ‘CCR’ Category

Exchange CCR error – Event ID: 2059

Friday, July 23rd, 2010

Recently, we had a customer who had an attached storage drive fail on them. An Exchange 2007 CCR cluster was hosted on this drive quite the disruption. Long story short, we got the data back and started to resume the CCR. Unfortunately, the status would keep going from “Healthy” to “Failed”. Checking the results, this is the error we would keep getting:

Source: MSExchangeRepl

Event ID: 2059

Description:

The log file 612083 for Server\Storage Group is missing on the production copy. Continuous replication for this storage group is blocked. If you removed the log file, please replace it. If the log is lost, the passive copy will need to be reseeded using the Update-StorageGroupCopy cmdlet in the EMS.

Now of course, those transaction log files that it was asking for no longer existed (Due to the corruption – again, long story). But here is were we figured out the problem to be. If we took down the exchange db, and did: “eseutil /mh .\database.edb”, we got the following bit of information:

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.02
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode…

<truncated>

Previous Full Backup:
Log Gen: 612070-612083 (0x956e6-0x956f3) – OSSnapshot
Mark: (0x956F4,8,16)
Mark: 07/10/2010 12:34:52

<truncated>

Notice that it was trying to get the log generation files from the previous backup. Two options… back up the 250Gb Database (Takes about 18 Hours), or trick it, get the CCR going again (And then do the backup). We choose to trick it. How? Here is how:

On the mail store, we went to the powershell (Command prompt is fine also) and did this:

Diskshadow
set context persistent
writer verify {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}
begin backup
add volume f: alias shadow_f (F: is where the datastore is…)
create (Takes 2-5 minutes)
However, before I could finish, I got an error:
ERROR: The writer “{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}” was not included. Aborting …
Check the syntax of the writer name and writer ID.
The reason was because my transaction logs were somewhere else (Another Drive), and my system Drive was C:, so added those as well:
add volume c: alias shadow_c
add volume f:\exchange-logs\ alias shadow_logs
create (Again! This time it took 2-5 minutes and it WORKED!)
expose %shadow_f% y:
end backup
delete shadows exposed y:
exit
The whole process took about 7 minutes, and the new result when I ran: “eseutil /mh ./database.edb”:
Previous Full Backup:
Log Gen: 641830-641842 (0x9cb26-0x9cb32) – OSSnapshot
Mark: (0x9CB33,8,16)
Mark: 07/21/2010 01:24:36
It WORKED! Those were the current generation of logs that we wanted… so what exactly did we just do? Well Server 2008 RTM and R2 have the ability to make shadow copies of live databases, and access them using the tool: Diskshadow. Now, when we do this, Exchange detects this as a successful backup, and marks the database as such. No extra Hard Drive was used during this time (Perhaps a few MB), and it was very quick. Trick complete. Restart CCR (Had to reseed unfortunately – this was so the old database that had the old information could be replaced with the new database with the “correct” backup time), and then did a successful backup. Hope this helps someone!

 

Share

Posted in CCR, Exchange 2007 | No Comments »