Exchange DAG Seeding

anything I don't mind · 28 Mar 2014 at 11:50

I have been having a lot of problems seeding a 200gb database to our DR exchange server. Ive spent the last few weeks trying to seed db1 and ive got it too seed ok, well it goes through the process and data is transferred for 5 hours across the link. Only for it to say failed and suspended and require a reseeded.

The other database db2 seeded first time without any problems.

I've looked in to it a lot and i can't find any reason why its failed. It just fails on a specific item. I've tried changing the dag configuration and all types of network changes, but after db2 worked first time i don't think its misconfigured any more, i just think its a log of item issue on that db.

Im out of options and the only option i have left is from what i have read, dismount the database, move/rename the log folder. Then copy the edb file to the DR and mount the database at production side.

But this will require down time.

Anyone know if there is anything else i can try?

Swarfega · 29 Mar 2014 at 08:19

Network connectivity all working 100%?
AV have exclusions for the logs and DB? Just wondering if AV is seeing something it doesn't like and interrupts the seed.

Yamahahahahaha · 29 Mar 2014 at 11:24

Another option is to set up a separate DAG DB then move individual mailboxes over from the existing DB to the DAG DB. This is how we've done it over ADSL links for people with relatively large mailboxes (~10GB).

You need to make sure your backups are robust though if you think there are issues with item corruption upsetting the database.

Knubje · 29 Mar 2014 at 22:28

Is there any option of blowing the copy away completely from the passive node in Exchange, removing the files from the server and then re-seeding the whole thing from scratch?

I've had an issue with a DB that was behaving very similar to this in the past and this was the fix.

Come to think of it, I've had another that wouldn't reseed at all and after loads of digging it was still a mystery. So we cut our losses, moved users to another database and deleted the old buggered one.

anything I don't mind · 2 Apr 2014 at 13:17

I don't think there is any configuration or network problems because the dc2 seeded first time without any problems.

I've deleted the passive db and log filse completely a number of times for db1 and attempted the reseed from a blank a number of times with the same result. It spend 5 hours replicating all the data and then ends with failed and suspended status with error message that it failed processing a specific item and requires the entire db to be reseeded.

from what i have read the only option i have is to dismount the active db, move the log files to a new location and then copy the edb file through the network and then mount the active copy and it will generate new log files and should show a healthy status.

the question is though wouldn't generating new log filse break the up? I could do it on a saturday morning after the backup from friday has gone through and there will be minimal log files.

Other question i have is around doing a public folder replica

Ive created a new pf db at the 2nd exchange server. Then i used the script command:

.\AddReplicaToPFRecursive.ps1 -TopPublicFolder "\" -ServerToAdd "2ndexchangeserver"

But i am yet to see any public folders replicate. Its only been 30mins but would have expected to see some by now. Hopefully i did it right because it seems realy poorly designed.

anything I don't mind · 13 Apr 2014 at 18:34

Does anyone have any insight on the idea of dismounting the database and then renaming the logs folder. What exactly would the implication be for this action, with regards to backup and database integrity. I have seen some advice online that this needs to be done in order to create a database copy when it fails with item processing.

Sorry to repost its just still outstanding problem.

Knubje · 14 Apr 2014 at 18:39

Hi,

From memory and discussions with other forum members, if you shutdown a database so that it is in a clean shutdown state, you can rename (move) the existing logs and start it up again and Exchange will start new logs to mark that point onwards.

If you want a good test plan and to be as sure as you can, create and mount a quick test DB (Blank ones are like 8MB) and do the same with it's associated logs. See what happens. Same should happen in production.

As always with most things you aren't 100% confident on make sure you have a full backup of the DB within an acceptable RPO before proceeding.