Ayuda de vídeo de Screencast

Advice on hardware for upgrading EV 7.5 SP3 to EV 10.x.

Created: 01 Oct 2012 • Updated: 25 Nov 2012 | 6 comments
Se ha solucionado este problema. Vea la solución.

Ladies and Gentlemen,

Our EV 7.5 SP3 environment needs an upgrade. Inevitably, the budget is very tight and I’ve been given strict instructions that I cannot exceed the allowance.

Our Exchange 2007 environment consists of two CCR clusters and targets, for EV, a single server running EV 2007 7.5 SP3. There are approx 13,000 mailboxes, in place. The majority are user mailboxes, with shared mailboxes and a proportion of ‘former employee’ mailboxes.

Our user base includes Citrix and VPN users, as well as OWA users and of course office based LAN users.

Average mail item size is 100Kb.

Our archive strategy is aggressive: all mail older than 28 days is archived via EV.

Our current EV Server has about 13Tb of mail data stored already, and the ‘a5’ private queues are already rather huge: around 655000 for each of our two exchange server clusters.

In the last couple of years, we’ve already added an extra 10Tb of archive space and doubled the size of the Indexing drive.

In an ideal world, we’d probably have one EV server per Exchange CCR cluster, but the funds available will not stretch to that luxury.

I’ve been offered an HP DL/580 G5 with 4 x Quad core processors, 32Gb of RAM and 15Tb of SAN storage – this is expected to last us three years The latter is to be split between Fast SCSI for Indexing and Fibre ETA for Archive storage. We’ll be relocating the existing direct attached arrays to the new server. It’s our intention to upgrade to the latest version of EV (10.0.2 ?) and realise that to do so, we’ll have to upgrade through EV 8.x and EV 9.x. before we can get to version 10.

I’d appreciate any suggestions for alternative configurations of hardware that keep us within budget and give an improved throughput of archived data.

Comentarios ComentariosIr al último comentario

el cuadro de los Rob.Wilcox

You could use a product like Archive Shuttle to move the archive data directly to the new hardware (create a new directory/new site etc).  That would skip out the need to upgrade through multiple different versions.

By the way - your A5 queue shouldn't have items in it long term..  Are you looking at the 'journal' MSMQ data, rather than the live data?

el cuadro de los Jeff Shotton

Rob is right. The number of messages on the A5 queue should never be more than the number of mailboxes that are being archived by that task. The fact that you have so many indicates that archiving has been lagging behind for months. Purge the A5 queue when EV is stopped - and then purge the admin queue of the messages after they are transferred there.

A few thoughts:

Regarding the upgrade, you havent mentioned which version of OS you are going to put on there, and you also have not detailed if you are going to use VMWare or if it is even available. You may well make more efficient use of resources by having two virtual instances on the same machine of 8core 16GB of RAM than one monster machine. The Windows 2008 R2 enterprise license will cover this - it allows a host and 4VM on the same box.....but it would require partitioning the environment and you probably have all items sat in one vault store. You would have the same issue with 2x 8cpu, physical 16GB servers which probably work out slightly more expensive. Therefore it would be easier to keep this as one server.

I doubt you will have any issues with the load in EV9 - I've seen boxes with half the spec only use around 40% capacity to archive 5000 mailboxes (at a rate of around 1600 mailboxes/hr) as you have two tasks you should be able to get through the mailboxes assuming your exchange is fast enough (although it is on the edge of what is recommended). EV10 is another matter and the increased processing and memory requirements for indexes etc mean for for less headroom.

You may consider setting up new vault stores and provisioning users into those for potential scale-out in the future. If you are using single instancing across the vault store group this would not lead to any extra storage requirement.

Indexing storage requirements may go up 60% if moving from medium indexing in EV2007 to full x64 bit indexes in EV10. This may add a bit of cost you were not expecting. Of course, you dont HAVE to move to x64bit indexes

Citrix = no vault cache to hide delays.

Using a product like archive shuttle to go direct may well cut down on the space used historically due to the optimized single single instancing - especially if you were using collections as well. It depends on how much you are going to save in storage costs vs the cost of archive shuttle.

You might also consider implementing storage expiry in an effort to remove some of the historic storage. Remember again though - if you are using collections you may well get back less than you expect if only some of the items in each cab are deleted.



Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

el cuadro de los Jeff Shotton

one other thing -  you can always use 'move archive' after you have upgraded to 9.X move archives into a new vault store and take advantage of single instancing. You could also use this to rebuild the indexes at the same time, but you would want to do that in 10 to get x64 indexes

Jeff Shotton

Principal Consultant

Adept-tec Ltd

Website: here

el cuadro de los EV_Novice

Jeff, Rob, thankyou for your comments and advice. I wasn't aware of 'archive shuttle', nor of 'move archive'  in version 9.

I was advised against purging the queues by an ev expert, citing grave consequences and the loss of data. If you could direct me to an article or articles that will both give guidance on how to purge successfully and also reassure that no data will be lost, that would help me with colleagues and management, not to mention the ev expert.

The O/S would be Windows 2008 Enterprise X64. We do have VMWare environments available, but I am told I cannot put EV onto VMWare, because its impact would have serious consequences for other applications already installed in VMWare.

Thankyou in advance for your welcome advice.

el cuadro de los EV_Novice

Apologies, a further read-through revealed I'd missed something:

Yes the a5 queues have been excessing for a long time. Arching is indeed lagging serioualy.

thanks again.

el cuadro de los Rob.Wilcox

I wouldn't necessarily suggest making the changes outlined in this document...


But it does clearly spell out what the A5 queue is for.

In addition show your VMWare experts this document:


Hope that helps?