Link to home
Start Free TrialLog in
Avatar of Fraserreid
Fraserreid

asked on

Exchange 2007 using SCR - mailbox sizes between the source/target don't match, log files not deleting

I have Exchange 2007 running using SCR. The size of mailbox on server1 (source server) matches the size of the mailbox on server2 (target server).

I have created a new mailbox on both and enabled scr using a replay time of 1 minute and truncation of 3.

I seeded the target with resulted in identical mailbox files and logs.

I transfered a 121K mailbox into this new mailbox on the source. It increased in size as I expected. However the corresponding mailbox on the target only increased by 89K - so they no longer match in size. Also the log files on my target are still present , even with a 3 minute truncation time.

Any idea why the mailboxes did not increase to the same size and why my logs are still present ?
Avatar of Tony J
Tony J
Flag of United Kingdom of Great Britain and Northern Ireland image

It can take a while to get there.

What do you get from

Get-storagegroupcopystatus -standbymachine TargetServerNam
the amount of time that the Microsoft Exchange Replication service should wait before truncating log files that have been copied to the SCR target computer and replayed into the copy of the database begins after the log has been successfully replayed into the copy of the database plus the truncate lag time

can you post the results from the following cmdlet to verify your settings
(Get-StorageGroup Server\SGName).StandbyMachines
Avatar of Fraserreid
Fraserreid

ASKER

shows copystatus = healthy, replayqueuelenght=50
scr has the minimum replay queue of 50
there are currently more than 50 logs
from the link below:
In addition to the administrator-configured delay of replay that is specified using the ReplayLagTime parameter, Exchange also prevents a fixed number of log files from being replayed on an SCR target, regardless of the value for ReplayLagTime, using the following formula:

Maximum of ("value of ReplayLagTime" or "X log files")

where X=50. This is an additional safeguard against the need to reseed a storage group in situations when an SCR source that is in a continuous replication environment, for example, local continuous replication (LCR) or cluster continuous replication (CCR), experiences a lossy failover and is brought online using the Restore-StorageGroupCopy cmdlet. By delaying replay activity on the SCR targets, when a lossy failover for an SCR source occurs, the chances of needing to reseed the SCR copies are minimized because the nature of the data loss on the SCR source puts the two copies closer together in time.



http://technet.microsoft.com/en-us/library/bb676465(EXCHG.80).aspx
it won't truncate until the source logs have been purged too
Thanks endital1097 - did not know that ! Regarding the size of my mailboxes not matching, is that normal ?
i'm guessing you mean databases, and yes since the copy will always have that minimum of 50 logs to replay
have performed several backups against the mailstore and the logs aren't purging.
make sure you are running at least update rollup 9 for sp1
on the target
yes, on the target , logs do delete on the source after a backup
are you seeing any warning or errors in the application event log
ASKER CERTIFIED SOLUTION
Avatar of Fraserreid
Fraserreid

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial