Programming4us
         
 
 
Applications Server

Exchange Server 2010 Mailbox Services Configuration (part 3)

10/17/2010 5:15:51 PM

4. Mailbox Limits

As a seasoned Exchange administrator you have most likely heard from someone that "Storage is cheap, why must you put a limit on my mailbox rather than just adding more disks?" For a number of really important reasons, adding disk alone is not the answer. The primary reason is to meet SLAs. Without established mailbox limits, an SLA violation could occur in a number of ways. For instance, if none of the 5,000 mailboxes on a mailbox server had limits imposed, any single mailbox could consume all of the disks on a server in a matter of minutes. Although this could happen as the result of a malicious act, it can also be unintentional in a case where an Outlook rule or outside service continues to send e-mail messages to a mailbox, causing it to grow larger until the underlying storage fills up. With the improved performance and faster server hardware, these sorts of actions can happen in a matter of just a few minutes.

The other way mailbox limits play into achieving an SLA and controlling the size of databases has to do with achieving expected backup and recovery times. To recover the data in a database within the agreed-upon SLA, the databases must be under a specific size. For example, if you can restore 150 GB of data from your backup solution in three hours, and you have a four-hour SLA to restore the data, you do not want to allow the database to grow larger than 150 GB; otherwise, anytime a restore is required, the SLA will be violated. The easiest way to implement and maintain control over the size of the databases is to establish limits on the mailboxes and thereby not allow them to cause the database to grow beyond the size that prevent SLAs from being met.

This really means there is no hard and fast rule on how big mailboxes should be—just that a maximum size should be set. The best practice is to set a limit that in aggregate is less than the available disk space. That way if all mailboxes on the server reach the limit, the server will still have space to continue operating. That said, this may not be completely feasible, nor is it probable that all users will use their entire quota at the same time, unless there is malicious intent. In this case it is important to weigh the risks and costs involved.

Notes From The Field: Appropriately Sizing Mailboxes

Thierry Demorre

Senior Director, Infrastructure Services Line, Avanade Inc.

At some point during the design phase of a new Exchange environment comes the decision of the mailbox size. This decision prompts questions like "How much should we allocate?", "Should all mailboxes have the same limits and retention policies?", and "Should users have mailbox sizes that coincide with their job function, and if so how would that be determined?" It is appropriate to answer all of these questions before doing everything else, and that requires knowing the big picture of where you are deploying Exchange. To do this you will need to interview the legal team to understand what the retention policy needs to be. For example, if the legal team wants everything older than six months purged and inaccessible, that will need to be the starting point for evaluating the mailbox size.

On the other hand, if no restrictions are to be put in place, evaluation of the Exchange Server 2010 online archive or third-party archiving solution should be done along with determining the potential impact to the configuration and performance of implementing the archiving solution. Most of these archiving companies have been singing the praises of their products, and especially how stubbing items being archived was a way to save space in your online mailbox. As a best practice, however, using any form of stubbing is a bad approach. This has always been a limiting factor in Outlook—performance can degrade when the number of items grows out of control. While Outlook 2007 SP2 and Outlook 2010 introduce technology improvements for many more items in each folder, as well as larger mailboxes, keeping the environment under control is of paramount importance to keep the performance optimal for the end user. It is important to archive smart, rather than retaining data just for the sake of retention.

The appropriate course is to evaluate this question as any other critical aspect of your design. It would be wise to interview representatives from a number of user groups and obtain their requirements. It might be that one group only cares about the last three weeks' worth of e-mail, and another group that has a completely different or conflicting requirement. It would also be good to obtain some less subjective data, perhaps by creating a trend of current mailbox sizes. Because older versions of Outlook may not perform properly with large mailboxes or will not provide access to new features available in Exchange Server 2010, it is important to identify the client software that will be used. I know of companies that will deploy Exchange Server 2010, and then continue to use Microsoft Office Outlook 2003 to connect to their new messaging system.

So, how do you answer the question, "Can I create a 1-TB mailbox?" It is true that Exchange Server 2010 will certainly allow this. However, the reciprocal question would be, "Will you use it?" If you fill that mailbox with messages with an average size of 50 KB, that is approximately 24.5 million messages!


5. Configuring Deleted Item Recovery Quotas

Configuring the deleted item recovery setting needs to be done after the business needs are captured and understood. However, a couple of settings should be configured to ensure that malicious users cannot cause Denial of Service attacks by placing large amounts of data into the dumpster and running the server out of space. To do this the RecoverableItemsQuota and RecoverableItemsWarningQuota settings should be set per database. However, the settings can also be done per mailbox. These settings are similar to mailbox quotas except that they apply to items in the dumpster:

  • RecoverableItemsQuota The default limit is 30 GB; however, this can be set as needed. When the limit is reached all soft deletes will fail and an event log entry will be made the first time it occurs and once daily if the condition continues.

  • RecoverableItemsWarningQuota The default limit is 20 GB; however, this can be set as needed. When the limit is reached, an event log alert will be made and will continue once daily afterward if the condition continues. The oldest items in the dumpster will be deleted to make room for new dumpster data.

6. Poison Mailbox Detection and Correction

Exchange Server introduced poison message detection, placing messages that cause issues with the transport service in a queue and allowing the transport service to continue processing other messages. Exchange Server 2010 applies this same concept to mailboxes. In some cases a single mailbox with corrupt data caused the Exchange Store to crash or even to crash repeatedly. With poison mailbox detection the Exchange information store is able to detect and then isolate the poison mailboxes.

A mailbox will be tagged as a potential threat if:

  • A mailbox has had more than five threads running that have not made progress for 60 seconds; or

  • A mailbox has a thread doing work that crashes.

When a mailbox meets either of these criteria, an entry in the registry is made for the database along with the number of times the problem has occurred. Storing this information in the registry allows this information to be replicated to other servers in the DAG by the Windows Cluster service. This allows this information to be preserved during a failover. This information is stored in the following locations in the registry:

  • HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{Database GUID}\QuarantinedMailboxes\{Mailbox GUID}\Crash Count

  • HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{Database GUID}\QuarantinedMailboxes\{Mailbox GUID}\\LastCrashTime

The default settings can be adjusted for how many crashes lead to quarantining a mailbox as well as how long a mailbox should stay quarantined are stored. You can adjust these settings by modifying the following registry keys:

  • HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{Database GUID}\QuarantinedMailboxes\MailboxQuarantineCrashThreshold The default setting for this key is three crashes.

  • HKLM\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<Server Name>\Private-{Database GUID}\QuarantinedMailboxes\MailboxQuarantineDurationInSeconds The default setting for this is 21,600 or six hours.

The Exchange information store will also keep information on when the mailbox was flagged as a poison mailbox. When a database is brought online and periodically thereafter, the information store reads the time that the mailboxes were identified as potential threats. If the mailbox was quarantined more than two hours prior, the registry key for the mailbox will be wiped out.

After a mailbox is flagged and quarantined, no access is allowed to the mailbox by any end users or any of the Exchange processes. If the mailbox hasn't caused any crashes in the last two hours and is not quarantined, the registry path for the mailbox will be cleaned up by the information store. If a mailbox has been quarantined for longer than the MailboxQuarantineDurationInSeconds since the last time it caused a crash, it will automatically be removed from quarantine. If the problematic mailbox has been fixed, the mailbox can also be removed from quarantine manually by deleting the registry key and then remounting the affected database.

To be sure to keep ahead of any impending issues, you should monitor these registry keys to ensure that there is not a systemic problem causing multiple mailboxes and databases to become corrupt. This will also allow administrators to track down any issues and fix them.

Other -----------------
- Exchange Server 2007: Monitor Your Exchange Environment (part 4) - Microsoft Operations Manager (MOM 2005)
- Exchange Server 2007: Monitor Your Exchange Environment (part 3) - Performance Troubleshooter
- Exchange Server 2007: Monitor Your Exchange Environment (part 2)
- Exchange Server 2007: Monitor Your Exchange Environment (part 1)
- Use the Exchange 2007 Toolbox to Troubleshoot
 
 
Most View
- A Technical Overview of the Mobile Web : THE MOBILE NETWORK
- Windows Vista: Windows Firewall Settings - Advanced Configuration
- SharePoint 2010 : Configure Access Requests for Lists and Libraries
- Windows Azure Queue Overview
- Optimizing SQL Server for SharePoint 2010 (part 2) - Database Files and Their Location
- Windows Small Business Server 2011 : A Networking Primer - Understanding Domains
- Windwos Server 2008 : Recovering from a Server or System Failure (part 3)
- Navigating the Central Administration Home Page (part 1) - Central Administration Site Actions Menu
- SharePoint 2010 : Create a New Folder in a Document Library
- Exchange Server 2010 : Planning for Messaging Security
Top 10
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 3) - Configuring Recipient Filtering
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 2)
- Implementing Edge Services for an Exchange Server 2007 Environment : Utilizing the Basic Sender and Recipient Connection Filters (part 1)
- Implementing Edge Services for an Exchange Server 2007 Environment : Installing and Configuring the Edge Transport Server Components
- What's New in SharePoint 2013 (part 7) - BCS
- What's New in SharePoint 2013 (part 6) - SEARCH
- What's New in SharePoint 2013 (part 6) - WEB CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 5) - ENTERPRISE CONTENT MANAGEMENT
- What's New in SharePoint 2013 (part 4) - WORKFLOWS
- What's New in SharePoint 2013 (part 3) - REMOTE EVENTS