Steve Goodman's Exchange Blog
22Jan/112

HP to release the HP E5000 Exchange Appliances – What are the offerings and why do you need them?

imageThis week HP have announced their Exchange-in-a-box appliance solution for building Exchange mailbox servers. I was lucky enough to see one of these back in December under NDA and find this an interesting proposition (I only saw the new hardware itself - anything in this post is from publicly available information). The HP solution takes much of the mailbox sizing, design, testing and implementation away and simply presents a packaged solution that's ready to slot into your existing Exchange 2010 infrastructure, or to use for a new implementation or upgrade.

Right now (you can't buy the E5000 yet!) the options aren't exactly too complicated - you can build an equivalent solution by using the Exchange sizing calculator, specifying the right server, performing testing on the machine to validate that the hardware meets your specification before moving towards implementation. You can accelerate some of the design already by using the HP Sizer for Exchange 2010, or one of the pre-configured parts lists such as this one supporting 1000 2GB mailboxes.

So initially, it doesn't seem like the E5000 series brings a lot to the table that you can't get with a little effort. However, having seen the hardware in the flesh (and it's new!) it is pretty impressive and from what I saw, you won't be able to get the same kit using off the shelf bits. But my general feeling is that if you try, you can get better value with other HP kit. For example, with the HP Sizer tool, I think that it defaults to higher end disks and server hardware than is actually needed and you could get better value by putting the effort in with Microsoft Exchange sizing calculator. It remains to be seen if the actual specifications of the E5000 series go by default for 2TB SATA/Midline SAS disks and maybe even JBOD.

Looking behind the marketing - what will be offered?

The first thing I was hoping to find was some pictures of what's available so you can see how cool the E5000 series units look. However in all the marketing information I can't find anything - so I'll avoid describing what it's comprised of. However I have found what appears to be the list of the models that will be available, listen on the download page for it's recovery DVD:

  • BV839A - HP E5300 12TB Messaging System
  • BV840A - HP E5500 32TB Messaging System
  • BV841A - HP E5700 80TB Messaging System
  • BV895A - HP E5500 16TB Messaging System
  • BV896A - HP E5700 40TB Messaging System

So,  that's a fairly confusing line-up. Two E5500 and two E5700 models - one might assume one is to be configured as a DAG and the other not, or perhaps one is JBOD, one is RAID? Is the 12TB usable storage for mailboxes? Or is it just the total storage including system disks? I'm guessing we won't know for sure yet. Based on the press release, the E5300 will have a list price of $36,000. This doesn't compare too favourably to the list price of an MDS600 with 35 2TB disks (~$26K) and a couple of DL380s with 12GB RAM (~9.6K) so I would hope that it's usable, RAID storage that's inside.

So it's an appliance.. Won't I still need to test it? And can I add it into an existing Exchange 2010 DAG?

The first thing I thought when I heard about these is - OK, it's a pre-packaged Exchange solution. But I am still going to want to check it performs correctly. Yeah, it might be configured to a known good configuration and tested in lots of scenarios, but I still want to check that the storage platform doesn't have any issues. For example, during a recent SQL Server implementation we found that although everything passed the diagnostics fine the performance on the database disks was far lower than it should have been. After some more tests it turned out one of the disks in the RAID set was in fact faulty. The storage had been tested pre-delivery, so it shouldn't have been an issue.

Why do I mention this? Well - the download link mentioned above is for the recovery DVD for the system. Naturally, I downloaded this to find out what it includes. As well as the obvious, like HP utilities, Windows and Exchange it also includes Jetstress. From a quick look, it appears that as part of the process of installing the E5000, you can run Jetstress pre-deployment.

And the other good news from having a look at the contents of the recovery DVD, appear to be that you can install it into an existing DAG, create a new DAG and of course install it into an existing Exchange 2010 environment.

In conclusion, it seems like it's going to be a fairly compelling solution, firstly because of the hardware but mainly because of how apparently easy it makes it to deploy an enterprise ready Exchange solution into an organisation without complex calculations, deploying pre-requisite hotfixes, understanding how to use Exchange storage testing tools and of course deploying a database availability group according to best practises -  or the cost of paying someone to do all that for you. You still might need to do a fair bit of work planning and executing your implementation or migration, but a pre-packaged appliance like this certainly makes everything easier.

What do you think? me know in the comments or via twitter.

4Jan/110

2010 roundup and first anniversary of this blog…

So, 2011 is finally upon us and the new year also marks a couple special occasions for me. Firstly, I'm 30 in less than two weeks time (!) and secondly, it's a whole year since I started my blog…

For many years this site was really just about Car PCs. As that technology became standard in most cars, and the time I had spare for expensive hobbies diminished after the birth of my daughter I needed to find another outlet for my creative juices. I've always been into technology communities - in the past I've organised UK Car PC meets, been a forum mod on a number of Car computing websites and even been in a few UK computing magazines - again for the Car PC stuff.

However in recent years I've spent a lot more time and effort working with enterprise computing technology and taken a special interest in Messaging, VMware, storage and more lately Unified Communications. Therefore, it was a natural step to take more of an active interest, firstly helping people out on forums and of course by blogging.

With so many other Exchange related blogs around, I wanted to be different to a lot of the other blogs and make sure I don't just focus on the latest news; instead I wanted to try and offer something unique or provide the first insight into new features. As an Exchange TAP member the latter was thankfully easy (once features were out of NDA!) and I hope I've done a fairly good job of finding a unique angle or solving a problem you didn't know you had.

A few stats..

I won't bore you with a ton of graphics, so instead here's a few stats on my first year blogging…

And these are just on the blog itself - since I started tracking visits back in 2005 (the site was running for years before that), I've had over 680,000 views from nearly every country on the planet with only a couple of countries in central Africa and North Korea as exceptions.

The Year Ahead

It looks like 2011 is going to a be a busy year for Exchange-heads and UC-fans alike. Lync is certainly going to be making a big push into the Enterprise - it's a fantastic product and I can see it's going to be very popular. Exchange 2010 is no longer the new kid on the block and now it's past SP1 there's going to be a lot more enterprises moving to it from 2003 and 2007; and finally Office 365 is just around the corner. These are all areas I've got more work planned myself and I've got a list as long as my arm of blog posts that will hopefully be very useful.

So, you can expect to see a lot more blog posts from me in the year ahead. I've sat for far too long on a few topics I had planned so stay tuned for a few things that you haven't seen anywhere else yet, complex topics demystified and if all goes to plan I've got some stuff up my sleeve you can't get without spending a fair bit of money. Smile

Happy new year!

Steve

12Dec/106

Why you should consider using Exchange 2010′s archiving features instead of just large mailboxes

imageBeginning with Exchange 2010, the ability to give users a Personal Archive hosted within Exchange was brought into the core product. Previously users would rely on either PST files held locally or copied to a network share, or by using a third party product like Symantec Enterprise Vault, which with software add-ons and a third party management server allowed messages to be archived and retrieved via "stub" messages.

The personal archive feature (sometimes known as the "Online Archive") works by allocating a user a second mailbox. With SP1, the Personal Archive can be located on a separate database, separate server or even (when Office 365 is released) in the cloud. Server-side policies control when messages are automatically moved to the Personal Archive and this can be accessed by users using Outlook Web App, Outlook 2010 and very soon, Outlook 2007. Effectively, it's a way of splitting the current, important mailbox data from the little used reference material that is kept for compliance or convenience reasons.

However, one of the big strengths in Exchange 2010 is that you don't need to archive just to maintain performance and keep server costs down. Due to the lower disk performance required Exchange architects can design solutions that make use of large 2TB SATA disks to give users massive mailboxes of sizes higher than 25GB in some cases. And when it comes to mailbox server sizing, the advice for databases that will store primary mailboxes and archive mailboxes is pretty much the same.

This lead to the obvious question - if I can give users massive mailboxes, what is the point of the personal archives? Wouldn't it make more sense to just give them the whole mailbox as one?

I've thought about this a little bit and while just using large mailbox does make some sense - especially from a client compatibility point of view (e.g. limitations of IMAP, Mac, Activesync), and because archiving requires Enterprise CALs, there are certainly a number of good, sound reasons to consider the use of personal archives:

Reason 1 - Reducing Outlook Client's Offline Cache Size

image

If you give your users a 25GB mailbox, then for most clients, that means a 25GB OST needs to be maintained on each workstation. With the rise of remote workers, "bring your own PC", virtual desktops and taking into account the amount of fragmentation that will occur on the local cache file, this might be undesirable. Although many users won't immediately make full use of these massive mailbox sizes, don't underestimate how many users may take the opportunity to (wisely?) import their old PST files into their larger mailboxes.

By splitting the full quota between the primary mailbox and personal archive, you have a predictable offline file size for clients and can still grant users the larger quotas.

Reason 2 - Tiered Database Copy Levels

image

How important is the archive data? If it's previously been stored on the local users' PCs, then it's probably not mission critical to the business. If it's been on file shares, then again there might only be two copies - one online and one on the file server backups.

So, why not consider having different database "collections" for primary and archive mailboxes, and having a different level of copies for the archive databases. For example, databases dedicated to primary mailboxes may have two on-site copies, a lagged copy and a copy at a DR datacentre. The databases dedicated to archive databases may only need one on-site and one at the DR datacentre. You could reduce the number of mailbox servers and storage required to support a large mailbox infrastructure whilst still maintaining the levels of resilience you want for your most important data.

Reason 3 - Choose Different Backup Policies for Archive Databases

image

If you're still backing up the traditional way, then you are probably making sure the databases containing the user's primary mailboxes have a reliable, up-to-date backup. It may well be direct to disk then streamed off to tape after a certain amount of time has past.

Does all the email need this level of recoverability? The personal archive will have messages moved to it daily as it hits the policy for removal from the primary mailbox - but those messages about to be archived are already being backed up as part of the main backups. You could consider using a different backup policy altogether for databases dedicated to archives, such as weekly if you do daily, or daily if you do hourly? Maybe backup direct to tape, or even consider relying on database copies alone. You could reduce the amount of infrastructure you need to build out for your backup systems.

Reason 4 - Total Disaster Recovery

image

By a total disaster, I mean total! We like to think it won't happen to us, and thankfully with Exchange 2010 the prospect of having to do a dial-tone recovery is one many Exchange admins will never face. But what if the worst does happen? At upto 2TB a mailbox database, how long will it take to restore all those massive mailboxes?

Using dedicated archive databases and personal archives could mean in such a scenario you can bring users to near full working ability by bringing their smaller primary mailboxes from backups and then bring the personal archives back afterward. Given most of the users will be able to work normally, management will hopefully stop breathing down your neck and let you get on with the (still mammoth!) task of bringing back those archives.

Reason 5 - Host Archive Databases Centrally with Primary Mailboxes at Branch Offices

image

It may be be that for branch offices, you aren't even going to consider placing Exchange servers at each location and just have everyone hooked into HQ. But if you are placing Exchange servers at each branch office, then you will be no doubt need to plan for backups. Deploying massive mailboxes could be a problem as then you need to take into account how you will re-seed (if using DB copies) or restore from backups should the need arise.

Hosting personal archives at HQ could be an option to mitigate against these risks, whilst still ensuring the primary mailbox is local to the client. You can deploy smaller servers at the remote offices and reduce the time taken to restore should the need arise.

Reason 6 - Host Archive Mailboxes in the Cloud

image

Finally, why not host the archives in the cloud? Early next year after the release of Office 365, you'll be able to look at the option of letting Microsoft host your entire Exchange infrastructure. But if that isn't for you, Office 365 will also offer the ability for personal archives to be hosted in the service. Obviously there are a lot of other factors to consider, such as costs compared to hosting these in-house, regulations you need to comply with, and any internal barriers to adoption. But there could be serious savings to be made; and the chance to limit the up-front costs associated with moving to Exchange 2010, whilst still providing large total mailboxes and an on premises Exchange system.

What are your thoughts? Do these reasons make sense to you, or not.. Have any more ideas about why you should or shouldn't use archiving in Exchange 2010? Let me know in the comments…

9Nov/101

VMware release Exchange 2010 "Best Practices Guide" [Updated]

imageI recently read via Virtualization.info that VMware have released their "Best Practices Guide" for Exchange 2010. It transpires this was actually released a couple of months ago, however it's the first time I've seen it and I certainly think if you run VMware vSphere and plan on running Exchange 2010 it's worth a read.

VMware say in the best practices guide that "Exchange Server 2010 is proving to be an even better candidate for virtualization than its predecessors.", "The Exchange 2010 Mailbox Server role is lightweight, fast, and ready for virtualization." and "performance for a virtualized Exchange server is comparable to a non-virtualized server running on the same hardware".

So from VMware, it's no surprise to hear that Exchange is a perfect workload to virtualize on their platform. If you're currently running vSphere, and considering virtualizing Exchange 2010, VMware will definitely support this on their ESX platform. However, there are a few caveats…

If you're currently running an Enterprise vSphere deployment, shared storage will most likely be your number one platform for all your VMs running in your virtual environment. Without it, the key VMware features like vMotion, DRS and VMware HA don't work and you're left with your eggs in a number of delicate baskets. So it won't be shock that VMware say "It is preferable to deploy virtual machine files on shared storage ".. "This is considered a best practice for mission-critical Exchange deployments, which are often installed on third-party, shared-storage management solutions.". While I agree with the first part of that, I certainly don't agree that it's still best practice to use shared storage for Exchange - for starters Exchange 2010 no longer supports single copy clusters and CR based clusters such as DAG and CCR really excel when using DAS. Understandably, for VMware this is the main issue. vSphere in the Enterprise == Shared Storage, so to maintain this model they need to recommend shared storage for any application running atop the platform.

So, you've really got to use shared storage for Exchange on vSphere.. But that's OK, isn't it? NFS is getting wider acceptance for running VMs on and of course iSCSI is a great middle ground between F/C and NFS for using traditional storage protocols at a decent price… Well, iSCSI is supported for standalone Mailbox servers, but "For Mailbox servers that belong to a Database Availability Group, only Fibre Channel is currently supported".

According to VMware, though, only supporting DAG on F/C may not be a major problem, though. Instead of using DAG to have multiple database copies, VMware say "The building block approach is a recommended best practice for creating a standalone Exchange Mailbox Servers running on vSphere using pre-sized virtual machine configurations. Exchange servers that have been divided into virtual machine building blocks (as opposed to larger, monolithic Exchange servers) can simplify server sizing during the initial deployment and create a highly scalable solution using virtual machines with predictable performance patterns.". So if you don't mind only having one database copy (or copying it at the array level), the the combination of iSCSI+VMware+Exchange 2010 may be for you.

It's fair to say although there are a few disappointments in the document - like the focus on shared storage, gentle push to avoid DAG and the use of F/C disks in RAID 10s instead of large, dense SATA disks, it's still a worthwhile read (so long as you follow Microsoft's own best practices) and will help with small and large Exchange deployments on vSphere alike.

Download Exchange 2010 on VMWare - Best Practices Guide

Update 1: Microsoft have recently posted (a few hours after this post, taking into account the time difference) a response to the Best Practices guide:  Answering Exchange Virtualization Questions and Addressing Misleading VMware Guidance

Update 2: VMware have responded to Microsoft's above post, addressing why VMware HA is a great compliment for DAGs: Virtualizing Exchange on VMware Provides More Recovery and Availability Options