کد:
http://msexchangeteam.com/archive/2006/07/06/428213.aspx

Introduction

I regularly meet with customers and discuss their Exchange Server architecture. Two topics frequently come up so I thought I'd discuss them with everybody and give my perspective on them.

Many customers tell me that they do not impose mailbox and/or message size limits on the vast majority of their user population. This poses a problem because you will never be able to adequately design a storage subsystem or maintain the desired database size limits, let alone meet any service level agreements that may be in place.

Additionally, most of these customers do not have defined, measurable, and actionable Service Level Agreements (SLAs) or Operating Level Agreements (OLAs) in place to manage user expectations (i.e. messaging as a service), and thus cannot measure a real cost/benefit with regards to the user population demands. Ultimately, the lack of mailbox size limits and message size limits can lead to instability in the messaging architecture.

Oh, and I consider an outrageously large limit (to quiet the restless natives) the same as the lack of mailbox and message size limits.

Mailbox Limits

The following areas or issues may occur in your environment if you do not have a proper quota management policy in place:
- Denial of Service Attacks - Without a message and mailbox size limits, a hacker (whether internal or external) can easily implement a denial of service attack by sending messages with large attachments, ultimately using all available resources on the Exchange servers, thereby causing system failure. Implementing message size limits (both internal and external) can reduce the likelihood of this risk.
- Capacity Planning - The lack of quota management effectively limits any type of future capacity planning (e.g. cannot predict future database growth). In particular, if you have an SLA that dictates a backup/restore window you may not be able to meet that goal, due to not being able to control the database size metric.
- Network Utilization - Since the users will have unlimited mailbox sizes, network utilization will increase between client and server if users utilize OSTs or cached mode Outlook clients.
- Single Instance Storage - Single Instance Storage ratios may continue to decrease if reactionary measures are used to combat the lack of quotas (e.g. continually moving mailboxes around the enterprise to head off low disk space, SLA attainment, etc).
- Cost Impact - Due to the growth that will likely ensue without a proper quota management implementation, organizations will find that the cost per mailbox will and continue to increase over time. In addition, most likely additional costs will accrue due to poor management of the solution, in terms of not having proper SLA/OLAs, moving mailboxes to head off capacity disasters, and overloading servers from a performance and capacity standpoint (due to the aforementioned mailbox moves).
- Performance Impact - A lack of quota management will mean that eventually the storage subsystem will not be able to sustain the I/O throughput required. As you increase the mailbox sizes, the number of items will increase and for most users this will mean an increase in the number of items in the key folders (Inbox, Sent Items, Calendar, etc); as the number of items increase, the I/O throughput per mailbox will increase (http://support.microsoft.com/?id=905803). In addition, since the amount of data increases, users may deploy desktop search programs, and when running in online mode, these search programs utilize Exchange server resources (http://support.microsoft.com/?id=905184).
Also remember that mailbox quotas are only part of the solution:
- Users should realize that a mailbox is not a file storage area; the users will require some training on email etiquette that is appropriate in their business. For more information on email etiquette rules, please review http://office.microsoft.com/en-us/FX012055341033.aspx.
- Organizations could provide alternate solutions like SharePoint Portal Servers and Windows SharePoint Services where users can save documents and can collaborate around them by sending links via email as opposed to attaching the documents.
- Archiving solutions can help, but only with proper planning and design. Also, please note that most archival solutions replace the archived content with a stub reference. The stub references still have an impact on the messaging view creation process and affect the performance and scalability of the solution.
To resolve the lack of mailbox size quota management in the short-term, organizations should:
- Identify an appropriate message size limit.
- Identify appropriate size limits; include warning, prohibit send, and prohibit send/receive.
- Identify key personnel that require additional storage capacity, above and beyond the limits defined from above. Create separate SLA/OLAs for these sets of users.
To resolve the lack of mailbox size quota management in the long-term, organizations should:
- Implement defined Service Level Agreements and Operating Level Agreements that measure the messaging solution as a service; e.g. Gold, Silver, Bronze; 99.99% availability, etc that are actionable and measurable.
- Gain support from the business for the budget and resources to support the defined SLA/OLAs.
- Implement the message size limit.
- Implement the mailbox size limit using mailbox database policies.
- Move key personnel onto a dedicated database store and use a separate mailbox database policy to control mailbox size.

Message Size Limits

Microsoft has a best practice of a 10MB limit. Exchange Server 2003 by default sets the global message size limit to 10MB. The Exchange Product Group implemented this code change due to customer feedback and to help protect against denial of service attacks.

Issues that can arise from a lack of internal message size quota policy:
- Denial of Service Attacks - Without or with improper message size limits, a hacker (whether internal or external) can easily implement a denial of service attack by sending messages with large attachments, ultimately using all available resources on the Exchange servers, thereby causing system failure.
- Capacity Planning - Improper quota management effectively limits any type of future capacity planning (e.g. cannot predict future database growth).
- Backup/Restore Windows - Improper quota management will ultimately impact backup restore windows. As the database sizes grow, the backup window will increase. At some point this backup window will interfere with business hours. The same is true for the restore window.
- Virus Scanning - Improper quota management will incur performance penalties on virus scanning of the messages.
- Anti-Spam Measures - Many anti-spam products won't scan the message if they are over a certain size.
- Network Utilization - Network utilization will increase as messages are sent between Exchange servers and between the Exchange organization and the Surf Control relay devices.
To resolve the lack of message size quota management in the short-term, organizations should:
- Organizations should monitor and study the contribution of impact related to such large size limits.
- Organizations should consider alternate products for attachments, so that the overall message size limit can be reduced. For example, Windows SharePoint Services integrates with Office 2003, thereby allowing attachments to be stored on web sites.
- Do not implement message size limits on SMTP Virtual Servers as that will also impact public folder replication. Message Size Limits should only be implemented globally, on connectors, or on the mail-enabled object (http://support.microsoft.com/?id=322679).
To resolve the lack of mailbox size quota management in the long-term, organizations should:
- Organizations should implement another mechanism for file transmission and storage.
- Organizations should reduce the overall message size limit.
- Define SLA/OLA's and gain support from the business for the budget and resources to meet user demands.
- Monitor and measure performance to the defined SLA/OLA's.

The Future

Many of you may say "That's great Ross, but the technology doesn't support us. The users need their data and we can't allow them to delete it because we'll have to restore more, or we can't allow them to go to PST, etc".

Yes I know, with today's technologies it is hard to implement a solution, but it is doable. For example, Microsoft IT implements a strict message and mailbox size limit policy, as well as defined measurable SLA/OLAs for the messaging service. For more information, visit IT Showcase at http://www.microsoft.com/itshowcase.

But beyond Outlook 2003's capabilities of restricting PST access (you do know you can do that, right?), Exchange 2003 doesn't provide any mechanism (beyond the limited Mailbox Manager Policies) to implement life cycle management or long-term archival (our third-party partners help in this area - http://www.microsoft.com/exchange/partners/2003/backup.asp).

But fear not, we are making great strides in Exchange 2007 and Outlook 2007 around email life cycle management (in Exchange 2007 it is known as message record management). In addition, our move to 64-bit, allowed us to make changes to the product to reduce the IOPS/mailbox requirements (see http://msexchangeteam.com/archive/2006/04/07/424645.aspx for more information).

I encourage you all to review the Exchange 2007 Beta 2 demos on Compliance to learn more about what's coming - http://msexchangeteam.com/archive/2006/06/20/428030.aspx.

With these features, I truly expect customers to finally be able to get a handle on the data that exists within their message stores and to finally be able to implement valid message and mailbox size limits.

- Ross Smith IV





موضوعات مشابه: