We can all learn from the real-life best practice established in a massive messaging deployment. At nearly half a million mailboxes, HP's Exchange 2010 deployment is pretty big. 216 mailbox servers spanning 18 DAGs must be quite something to manage - think of the planning required to deploy a service pack or hot fix into production. Exchange Connections gives you the chance to come along and listen and learn from the folks who run HP's environment - and ask questions afterward. What a deal!
If you’re one of the fortunate who will attend the Exchange Connections conference in Las Vegas next month, be sure to consider the session “Notes from the Field: Running a 500,000 mailbox on-premises Exchange Server Deployment” at 10AM on Wednesday.
As explained in my earlier post “Tuning .NET for the Information Store”, I have been busy reviewing the decks for all of the sessions at Exchange Connections and found many interesting nuggets to debate when discussing how to run such a large environment.
HP serves 800 locations worldwide. Humans account for 465,000 mailboxes with 2GB quotas. Users generate 86 million messages monthly while 650 million messages are delivered. 390,000 distribution groups are in the HP GAL while their Active Directory contains 5.8 million objects. This is truly a very large environment, explained by the acquisition history of HP spanning Compaq, Tandem, and EDS (to mention just a few).
I don’t want to take away too much from HP’s Mike Ireland and David Dean thunder when they present the session, so let me concentrate on two points that I thought were of interest. First, HP still uses SAN storage for their 385 Exchange 2010 SP3 servers, 216 of which are deployed in 18 Database Availability Groups (DAGs). This runs contrary to the current generally accepted wisdom that cheap storage is the way to go for Exchange deployments. You could make the point that it’s all very well for a hardware vendor like HP to use expensive enterprise-class storage for Exchange when cheap JBOD can provide an acceptable alternative. The point though is that large enterprises often plan and manage storage on an application-independent basis so as to maximize their storage. I believe that this is the situation at HP and it proves that best practice – or perceived best practice – is not always appropriate for specific circumstances.
Second, HP has increased its default mailbox quota from a meagre 200MB to 2GB and have found that there has been a slow user uptake on the new quota. In other words, users aren’t filling those mailboxes as quickly as anticipated and 85% of mailboxes are still less than 1GB. I think this proves the point that I made when I said that the doubling of Exchange Online mailbox quotas to 50GB left me cold. Some people undoubtly need large quotas but once you pass 5GB or thereabouts assigning large quotas (and boasting about it) is a matter of marketing. The old “mine is larger than yours” syndrome.
I bet many questions will be posed to the HP duo when they present. One that I'll be interested in is their plans to upgrade to Microsoft's once-a-quarter cumulative update release schedule for Exchange 2013? Or how to handle a public folder migration for all the ancient folders, some of which have been hanging around since the days of Digital Equipment Corporation. Fortunately, we have two great sessions on the agenda about modern public folders. John Rodriquez will explain how to perform a migration from new to old and he's also going to explain common problems encountered with modern public folders and how to troubleshoot these issues.and how the new software might influence their current operational practice. For example, how will HP handle
I have been impressed at the depth and level of the content as I have gone through the sessions submitted for Exchange Connections. The good news is that the chairs of the other conferences that are co-located alongside us (SharePoint, SQL, Windows, and “Dev”) say the same thing. We have a great speaker line-up at Connections – perhaps you should join us?
Follow Tony @12Knocksinna