When bulk restoring archived items and Exchange Mailbox Quotas are implemented 3196 and 2270 errors are logged and the Mailbox Store EDB file size increases.

Article:TECH74833  |  Created: 2009-01-24  |  Updated: 2014-02-24  |  Article URL http://www.symantec.com/docs/TECH74833
Article Type
Technical Solution




When bulk restoring archived items and Exchange Mailbox Quotas are implemented, 3196 and 2270 errors are logged and the Mailbox Store EDB file size increases.


When a user is in a situation where they have an Exchange Quota assigned to their mailbox and the user attempts to restore archived items that increases the mailbox size to above the quota the following happens:-

1. A user bulk restores an amount of archived items that will increase the mailbox size to above the configured mailbox quota
2. The restores will complete successfully until the quota has been exceeded.
3. After this a 3196 and 2270 error as below will be logged in the Enterprise Vault event log for each item left to be restored. A DTRACE of the ArchiveTask process will show the following:-

Event ID: 3196 An error has occurred whilst synchronizing the properties of mailbox /o=First Organization/ou=First Administrative Group/cn=Recipients/cn=ihaveaquota on Exchange server EV2007EXCHANGE. |Error: <0x8004060c> |Internal: .\AgentExchSynch.cpp (CAgentExchSynch::SynchronizeMailboxEntryEx2) [lines {...,879,894,912,923,945,946,956,960,1010,1011,1015,1024}] built Feb 13 04:53:09 2009 |

EV~W Event ID: 2270 A queued operation exceeded the retry count and has been discarded|m_pIExchangeSynch->SynchronizeMailboxEntryEx(LegacyMailboxDn = "/o=First Organization/ou=First Administrative Group/cn=Recipients/cn=ihaveaquota",| adMbxDn = "CN=ihaveaquota,OU=EV Users,DC=ev2007,DC=local",| adMsgStoreDn = "CN=Mailbox Store (EV2007EXCHANGE),CN=First Storage Group,CN=InformationStore,CN=EV2007EXCHANGE,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=ev2007,DC=local", | SynchModes = "3")|HRESULT: 0x8004060C |

4. When analyzing the size of the Mailbox Stores EDB file that this users mailbox resides in it has been noticed that the store size has increased even though the items have not been successfully restored.

This issue occurs due to how Microsoft Exchange allocates pages internally. When the restore is initiated a call is received to Exchange and pages are allocated within the database to support the restore. In Exchange 2003 each individual page size is 4KB and so Exchange allocates these pages within the store prior to the restore actually taking place. Once the pages have been allocated you may or may not immediately see the file size of the .EDB file grow. After the page allocation, the restore procedure actually begins.
As items are being moved/copied into the target folder of the restore the item sizes are compared and contrasted individually against the mailbox quota defined for the user. As long as the item being copied/"moved in" is under the mailbox quota, the item will be copied/moved into the folder. When an item is encountered during the restore that would exceed the mailbox quota for the user the restore fails. The net result is that the restore fails to copy/move  the message and the items that were previously successful are rolled out. There is no immediate background thread within Microsoft Exchange that runs to reclaim the pre-allocated pages from the store. Thus, the file size remains constant after the page allocation.
This essentially could materialize into a Denial Of Service type of issue as if a large enough user base attempt many large bulk restores then the EDB file could increase to a size that fills up disk space bringing down the mailbox store.
How can the EDB file size be reduced and disk space reclaimed?
1. Wait for online maintenance to occur
2. Check the application log of the Exchange Server and looked for a 1221 event which will specify:-
The database "First Storage Group\MAILBOXSTORE" has x megabytes of free space after online defragmentation has terminated.
3. This x figure shows the free space that would be freed if an offline defragmentation took place
4. Perform an offline defragmentation
5. Check the Mailbox Stores EDB file size on disk and you will find that it has reduced by the size reported as x
What happens is that during the nightly online maintenance procedure (online defragmentation), the unused or "empty" pages are calculated and reclaimed as white space. The file size itself (the EDB) is not shrunk, but the empty pages are marked as available for new operations. Only after an offline defragmentation is the file size reduced.

This issue is resolved in the following release: 

Enterprise Vault 9.0.2




Supplemental Materials


Size of Mailbox Store EDB file increased substantially by failed EV Restore

Legacy ID


Article URL http://www.symantec.com/docs/TECH74833

Terms of use for this information are found in Legal Notices