1 / 46

How to Tell Your Manager You Need Quotas on Your Mailboxes

EXL203. How to Tell Your Manager You Need Quotas on Your Mailboxes. Bhargav Shukla Sr. Premier Field Engineer Microsoft Corporation. Session Objectives and Takeaways. Why do we care about mailbox sizing? Does it matter? Are large mailboxes a problem?

ishmael
Download Presentation

How to Tell Your Manager You Need Quotas on Your Mailboxes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. EXL203 How to Tell Your Manager You Need Quotas on Your Mailboxes Bhargav Shukla Sr. Premier Field Engineer Microsoft Corporation

  2. Session Objectives and Takeaways • Why do we care about mailbox sizing? • Does it matter? • Are large mailboxes a problem? • Mailbox quota is a Business decision as much as it is an IT one

  3. Agenda • Ask a question or two • Talk about Mailbox Quota • Talk about some more stuff • Leave room for Q&A • Remind you to complete evaluation

  4. Question • Microsoft Mail was first introduced… • In 1991 for PC Networks? • In 1988 for AppleTalk Networks? • All of the above? • None of the above? • 1988 for AppleTalk Networks, later sold off to become Quarterdeck Mail, then Star Nine Mail and then discontinued

  5. Where are communications going?

  6. Where are communications going?

  7. Email Trends in November 2008 • The average corporate user, can expect to send and receive about 156 messages a day, and this number is expected to grow to about 233 messages a day by 2012. An increase of 33% over the four-year period. (Radicati, 2008) • Business users report that they currently spend 19% of their work day, or close to 2 hours/day on email. (Radicati, 2007)

  8. Email Trends in 2012 • The average corporate user, can expect to send and receive about 110 messages a day, and this number is expected to grow to about 130 messages a day by 2016. * • Email still plays an essential role in everyday business communications. Office workers spend nearly 3 hours of their day on Email. * • The number of emails sent and received per day is beginning to slow due to the rapid rise in other forms of communications, particularly instant messaging (IM) and social networks. We estimate that 10% of conversations that would have previously been carried out via email are now handled via IM. * *RadicatiEmail Statistics Report, 2012-2016

  9. Why are talking about mailbox quota? • Forecast is cloudy • Office 365 plans offer up to 25GB mailboxes • Google Apps for Business offers the same • Consumer offerings • Hotmail – fair use soft limit • Gmail – 10GB • Yahoo – fair use soft limit

  10. It’s natural • IT management wants to offer more • Users want more • What does Messaging Architect want? • Meet Business requirements • What does management want? • Stay within allocated budget • What does security/legal require? • Meet regulations and compliance requirements

  11. Larger Mailboxes Why everyone wants one?

  12. Is Larger Mailbox better?End User Benefits • Access to all required data from anywhere and any device • Ability to quickly find data via search mechanisms • Reduces mailbox management • Eliminates the need for .PST files

  13. Is Larger Mailbox better?IT Benefits • High availability and rapid recovery • Utilizes high capacity disk drives efficiently • Reduces end user support overhead • Allows for elimination of .PST files

  14. Is Larger Mailbox better?IT Benefits • Eliminate PSTs • Do you have policy that prohibits use of PST files? • PSTs Generate help desk calls • Client machine disk failure • Anyone in audience backs up PST files for users? • Large PST performance issues • While improved with Unicode PST and Newer version of Outlook, how many are still using Outlook 2003? • Client performance and supportability issues when accessing PST’s over network • Dramatically increase legal discovery costs • Predominantly a manual process • Security risk • Terminated employee taking corporate e-mail • Stolen laptop scenarios • Have you tried PST Capture Tool yet?

  15. What size mailboxes do I plan for? • Consider following factors for planning: • Mailbox profile • Message size • Retention requirements • SLA requirements

  16. MSIT Deployment How did Microsoft do it?

  17. MSIT deployment • MSF Process Model • Assessment and Scoping • Identify Business and Technical requirements • Increase employee productivity • Increase operational efficiency • Decrease costs

  18. MSIT deployment • Mailbox Server Configuration Goals • Increase the mailbox quota to 5GB • Increased reliance on e-mail • necessary to sustain long-term growth • Move to low-cost storage • Exchange Server 2010 built to support low-cost storage • Successful implementation at MSIT is important • Remove third-party backups • Use native features to address backup and restore requirements

  19. MSIT deployment • Mailbox Server Configuration Goals • Sizing for storage • Existing average mailbox size (890 MB in 2008) • User profile (100-150 messages per day per user) • Growth rate (60 MB per user per month) • Account for overhead • Changes introduced with the new Mailbox Dumpster • Keep deleted items for 30 days to support backup goal • Content Indexing space requirements • Average number of transaction logs per user • Projected mailbox size = 3GB per user • Formatted capacity of 1TB disk = 917 GB • Total number of users per disk = 305

  20. MSIT deployment • Mailbox Server Configuration Goals • 1 TB disks to host 305 users meeting capacity requirements • What about IO? • 1TB 7200 RPM SAS disk can sustain 100 IOPS while staying below 20ms response times • How many mailboxes can fit in 100 IOPS? • Pre-Production environment observed 0.3 average IOPS per user • 0.3 x 305 = 91.5 • 8.5 IOPS isn’t a lot of remaining IOPS but system won’t suffer • Operational maturity is a key factor • Calculations won’t be this simpler in RAID configurations • Must consider write IO penalty for RAID type

  21. MSIT deployment • Mailbox Server Configuration Goals • Memory requirements • Pre-Production environment observed 120 messages per day • 100 messages/day profile require 6 MB of ESE cache • 150 messages/day profile require 9 MB of ESE cache • OS needs ~2 GB of memory • Exchange Server 2010 requires ~4 GB memory for required 16 active databases • 32 GB server met requirements • 32 GB – 2 GB – 4 GB = 26 GB • About 8 MB average ESE cache per user • ESE cache per user in production averages 5-8 MB per user

  22. MSIT deployment • Server Configuration • 32 GB Memory • 1 TB 7200 RPM disks in JBOD configuration • 35 disks per server • One Database+Logs per disk • 16 maximum active databases per server • 5 GB quota, oh wait! • Yes, this means thin provisioning • Decision to invest in engineering and support teams • Build custom monitoring tools • Regularly report on mailbox size and changes in user profile • Analyze trade-offs carefully before deploying thin provisioning

  23. MSIT deployment • Backup Strategy • Support 5 GB mailboxes • Reduce costs by eliminating third-party backups • Simplify mail restore process • Provide recovery for items up to 30 days old • Which meant • Minimum 30 days of data available for recovery • Ability to hold information for more than 30 days if active litigation required it • Ability to operate or recover with one or two failed copies

  24. MSIT deployment • Designing for backup requirements • DAGs met high availability and resiliency requirements • Single Item recovery met requirement of restoring items within defined restore window (30 days) • Lagged database copies deployed for point-in-time copy for restore • After initial deployment, re-evaluated use of lagged copies • DAG met the goal of recovery requirements as well • Lagged copies introduced administrative overhead • Treat database copies differently • Corruption meant logs not replayed are lost, removing backups from existence • Restoring from inactive database takes more time • Decision to rely on Single item recovery and simplify DAG design

  25. MSIT deployment • Restoring Data • Utilize new dumpster design • No longer a view of database • Implemented as a folder within Non-IPM subtree of the mailbox • Dumpster data is indexed and discoverable • Can be moved with mailbox • Data stored on per-mailbox basis • RecoverableItemQuota on mailbox or database helps prevent DoS attacks • SingleItemRecovery enabled and set to 30 days • Litigation hold for active litigations

  26. MSIT deployment • Recovering mail items • Self service using Recover Deleted Items tool • Administrative access to recover directly to mailbox or to PST • Search-Mailbox "Discovery Search Mailbox" -SearchQuery "from:'Ken Kwok' AND seattle" -TargetMailbox "April Stewart" -TargetFolder "Recovered Messages“ -SearchDumpster • New-MailboxExportRequest -Mailbox "Discovery Search Mailbox" -SourceRootFolder "April Stewart Recovery" -ContentFilter {Subject -eq "april travel plans"} -FilePath \\MYSERVER\HelpDeskPst\AprilStewartRecovery.pst

  27. Larger Mailbox Challenges Why is it important?

  28. Large Mailbox Challenges • Server performance • Client Impact • Operations management • Storage considerations • Disaster recovery

  29. Large Mailbox ChallengesServer Performance

  30. Large Mailbox ChallengesClient Impact

  31. Large Mailbox ChallengesOperations Management

  32. Large Mailbox ChallengesBalance Storage Requirements Performance Capacity Capital Costs (Capex) Operational Costs (Opex) Balance Management Reliability

  33. Large Mailbox ChallengesStorage Requirements: Management • Installation and maintenance activities on SAN • Requires dedicated storage personnel • Disk provisioning is important • Utility approach can cause problems • Incorrect provisioning can result in poor IO characteristics • SAN architecture has many moving parts • Troubleshooting becomes time consuming • SAN architecture requires constant monitoring (especially shared storage environments) • Thin provisioning requires careful planning • Consider procurement and other delays in provisioning new storage

  34. Large Mailbox ChallengesStorage Requirements: Management • Installation and maintenance activities on DAS • Design/deploy/forget approach • “Pod” design • Per server storage doesn’t change for designed lifespan • Deploy new DAG to address growth • Balance mailboxes/active databases to balance IOPS within existing DAG • Backups must be performed over LAN • Does native features meet your requirements?

  35. Large Mailbox ChallengesStorage Requirements: Reliability • Microsoft IT observes an annual failure rate of 2.75% in SAS/SATA deployment in JBOD configuration • Near the rate observed in past with redundant storage • Mid-Tier disks are cheaper than high-end disks and higher quality than cheapest lowest-end disks • For SATA: • Pay attention to enclosure specs since performance is affected based on vibration and heat • Use with battery backed cache controller • Ensure warranty periods align with design goals

  36. Large Mailbox ChallengesStorage Requirements: CapEx & OpEx • DAS solutions provide lower CapEx cost • As much as 10% of the cost of other solutions • JBOD deployments save costs even more • DAS solutions can reduce OpEx cost as well • In terms of provisioning, DAS solutions are isolated and thus performance and capacity can be assured • In terms of maintenance, there are fewer parts to maintain (disk and controller) • SAS/SATA disks consume less power

  37. Conclusion • What should be your mailbox quota? • There is no simple answer • Know your average user profile • Know average growth rate • Know average mailbox size • Understand how adoption of IM/social media will impact growth forecast

  38. Conclusion (continued…) • What should be your mailbox quota? • Understand business requirements • Consider current investments, expertise and budgets to decide where to invest • Invest in people and processes vs. hardware • Use native features of Exchange Server 2010 where possible • Reduce CapEx/OpEx requirements • Reduce complexity • Increase deployment flexibility • Validate early and often • Be proactive – monitor and respond

  39. Related Content • EXL308 - Real World High Availability and Site Resilient Design EXL202 - Getting Microsoft Exchange and SharePoint to Play Together EXL303 - Configuring Hybrid Exchange the Easy Way EXL11-HOL - Exchange Server 2010 Compliance: Archiving and Retention Find Me Later At… Exchange Booth between 11:30 AM – 2:00 PM

  40. Track Resources • Exchange Team Blog: http://blogs.technet.com/b/exchange/ • Exchange TechNet Tech Center: http://technet.microsoft.com/exchange • Geek Out with Perry Blog: http://blogs.technet.com/b/perryclarke/ • MEC Website and Registration: http://www.mecisback.com/

  41. Resources Learning TechNet • Connect. Share. Discuss. • Microsoft Certification & Training Resources http://northamerica.msteched.com www.microsoft.com/learning • Resources for IT Professionals • Resources for Developers • http://microsoft.com/technet http://microsoft.com/msdn

  42. Required Slide Complete an evaluation on CommNet and enter to win!

  43. MS Tag Scan the Tag to evaluate this session now on myTechEd Mobile

  44. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

More Related