Email administrators work on a variety of problems and issues surrounding email configuration changes and settings. But in conjunction with email client configurations and settings are also the settings on the email server, Exchange Server, which must also be tweaked from time to time.

Sometimes the size of the folders on the server and on the client can be different which can lead to confusion and unnecessary diagnostics. Users have reported mailbox sizes and folder sizes that are seemingly larger on the server than they are shown to be on Outlook.

For instance, the local data tab may show a size of six or seven megabytes for one of their Outlook folders but on their server data will show a much larger size such as one-hundred or more megabytes. Unfortunately adding the sizes of individual items will show that the client and the server data still do not match up as expected.

Making changes on the client such as deletions and even emptying out the mailbox will not reconcile the difference. But there is an explanation.

The fact that a client shows a folder size in the local data tab is an indication that the client is running in Cached Mode and that means there is a local copy of the mailbox being updated. It can happen that the local copy is significantly smaller than the actual size of the date on the server. If data has not been recently accessed then this can also affect the size reported for the local data since the client is in cached mode. Also the cached mode settings will affect the size reported. Having “download headers” enabled will also affect the size reported since not all of the data will need to be downloaded.

Another alternative worth trying is to press the control (CTRL) shift and “F” key simultaneously. This will bring up the Advanced Find dialog box. What you want to search for are items that are over a certain size such as larger than tens, or perhaps hundreds, of megabytes. An administrator can specify “Any Type of Outlook Item” and, from the “More Choices” tab, then set the size to something greater than one-thousand twenty-four (1024), or some multiple thereof, in megabytes. This will help in locating large files which can account for the difference in sizes between what is reported on the client and what is reported on the server.

Other issues can occur as an indirect result of differences in the mailbox sizes on the client and the server. As mentioned earlier deleting items from the mailbox folder you would expect to see those same size changes reflected on the server. But the space that is used by those items is, instead, not reclaimed. And as a further result of this condition when an administrator runs Exchange System Manager they’ll not see a decreased mailbox size.

On top of all that is another frustrating experience associated with trying to move mailboxes. Those actions can end up as unsuccessful operations and events logged in the application log as follows:

Event Type: Error
Event Source: MSExchangeIS Mailbox Store
Event Category: General
Event ID: 1205
Date: Date
Time: Time
User: N/A
Computer: SERVER_NAME
Description: Failed to create the mailbox of /o=company/ou=orgunit/cn=Recipients/cn=username with error 0×4e3.

Another issue that may be encountered as a result of different mailbox sizes for the same folders between the client and the server is that if messages have been deleted before they have been read then Exchange server might not report unread receipt messages for those unread items.

These issues can manifest themselves if the Microsoft Exchange Information Store service is not running the background cleanup process. As would be expected, it is the job of the background cleanup process to reclaim the data space that has been deleted from mailbox folders when messages or attachments have been removed.

In order for the background cleanup process to successfully run on the Exchange server it requires that two default registry entries exist and be correctly populated. Those much needed entries are the “Backup Cleanup” entry and the “Track Duplicates” entry. The default value for the Background Cleanup registry entry is sixty-thousand (“60,000”). And the default value for the Track Duplicates registry entry is one (“1”). These registry key values are automatically populated when an Exchange database is created and then mounted. The undesired results and issues mentioned in this article are most likely the result of the newly created database not being mounted. If the database has been created but not yet mounted then this can cause the background cleanup process not to run.

Another program can be used to create the registry key but the registry entries will not be created and hence even though the database can then be mounted it will still not run the necessary background cleanup process.