2007 migration to 2010

Hyper-Me

I've been asked to gather information on upgrading our existing 2007 exchange to 2010.

We have 2 2003 DCs and 1 08 R2 DC. I know that the domain functional level will have to goto 2003 native (if its not already there).

Are there any other considerations you guys have picked up on I should be aware of? I'd really hate to hose our own Exchange stuff.

Tin_Man

I just recently did this. The test environment went pretty smooth but the live environment went terrible.

*You can't do an "in place upgrade" from 2007 - 2010*

Things I took away from all this.

1. TEST TEST TEST
2. 2010 is 64-Bit only so make sure you have the hardware to support this. 4gigs is MIN requirement but try, beg & short of stealing to increase that
3. Exchange 2010 Prerequisites: Exchange 2010 Help <---- Follow that
4. DO NOT INSTALL the Exchange Rollout update 1.. This breaks OWA!!!
5. Online move mailboxes feature is very easy to use.

That is just a general issues I ran into you might not run into.

Claymoore

1. Use the Exchange Mailbox Role Requirements Calculator to properly size the servers and storage. Take time to marvel at how the proper application of mailbox size limits change the requirements. Be prepared to explain why you should/could take Exchange storage off the SAN.
2. Get a 64-bit Client OS to run the management tools locally. Just because you list this as a requirement in an SOW doesn't mean the client will actually do it.
3. Read the MS Exchange Team blog for helpful hints and explanations. The recent discussion on why single instance storage is gone was particularly good. For entertainment, read about 'I survived Bedlam DL3' over on the blog.
4. The best book on Exchange 2010 (of the two out there right now) is the Exchange 2010 Administrator Pocket Consultant. It's more of a 'how' book and not so much a 'why' book, but that's probably all you need right now.
5. I know you like virtualization so be sure to read about the support policy around virtual Exchange servers. It is not supported to install highly available mailbox servers in a highly available virtual environment. Basically, you can have DAGs or Live Migration, but not both. Choose DAGs.
6. Managing a properly designed and deployed Exchange environment is pretty easy - it's the design and deployment or migration that's hard (but it is more fun than just creating mailboxes).

Claymoore

Tin_Man wrote: »

4. DO NOT INSTALL the Exchange Rollout update 1.. This breaks OWA!!!

Looks like installing RU1 from an elevated PowerShell prompt is the solution (solution buried in the comments on the blog below). Thanks for the heads up before I installed it!

You Had Me At EHLO... : Exchange 2010 Update Rollup 1 is now released

blargoe

Claymoore wrote: »

1. Use the Exchange Mailbox Role Requirements Calculator to properly size the servers and storage. Take time to marvel at how the proper application of mailbox size limits change the requirements. Be prepared to explain why you should/could take Exchange storage off the SAN.

Why would I want to take Exchange storage off the SAN?

HeroPsycho

blargoe wrote: »

Why would I want to take Exchange storage off the SAN?

Because DAG's replicate the data in the db's to other servers, so it makes the use of a SAN potentially less compelling. But it depends on why you're using a SAN. If for example you love Single Mailbox Recovery utility on a NetApp SAN, you're not moving it off of it. Anything SAN specific that it adds capability wise, you might still want to use.

blargoe

OK gotcha. I'm using blades so I'm on a SAN pretty much by default

Claymoore

blargoe wrote: »

OK gotcha. I'm using blades so I'm on a SAN pretty much by default

But at least you have the option to use a mix of SAN and DAS now. If you have a DR site without a SAN, you can run an Exchange server that is a member of your HQ DAG off of direct attached storage there for site availability. If you also decide to host multiple servers in you primary data center for service availability, having multiple copies of the same data on the SAN can become prohibitively expensive and introduces the SAN as a single point of failure.

My current client was originally planning a mix of SAN and DAS storage, but local SATA disks were much cheaper. Since Exchange 2010 reduced the disk I/O by 75% compared to 2007, I can run a 250 user, 750 GB Database plus the log files off a single 7.2k SATA spindle. Although we are going to use RAID 10 for an extra layer of protection since we will have 8 databases that size.

blargoe

I like the sound of the IO performance increase. I'm having to go 6 spindles/RAID 10 FC today for an installation just slightly larger than that.

HeroPsycho

blargoe wrote: »

OK gotcha. I'm using blades so I'm on a SAN pretty much by default

You might consider not doing that with E2K10 for your mailbox servers. If SAN storage costs you more than DAS, and you're not making use of anything the SAN can offer for you above what E2K10 can do with a DAS, really, what's the point of a blade for E2K10. Even if you say easier recovery of a server failure, E2K10 still has database portability, and it would have failed over to the other Exchange server in the DAG.

You can get much larger processing power and RAM in a single 2U server than a blade, and E2K10 can handle far more users and transactions per mailbox server than previous versions could. Especially if your SAN team is different from your Exchange team and don't play nice, why give the SAN team the opportunity to jack your Exchange server performance if you don't honestly need the SAN in the first place? I've dealt with enough retarded storage teams doing idiotic stuff like not setting the right RAID level, making separate LUNs for tlogs and databases on the same disk groups, or sharing spindles with other apps that it would be compelling to me as an Exchange admin to not have to deal with them.

I don't mean to say you shouldn't use a blade for a mailbox server in E2K10. I'm just saying it may or may not make sense to use a blade depending on your needs. Blades would be great regardless for CAS and HT servers, but perhaps not mailbox servers.

I like options.

blargoe

I AM the SAN team... and the Exchange team... and the Active Directory team... and the Virtualization team...

Our current situation has us hosting about 500 mailboxes so the blade solution is good enough performance wise (so far). There may be growth on the horizon though. We went with blades originally because we were out of room in our datacenter... completely... and needed the density that blades could afford us. With VMWare in the picture now that won't be as much of a concern anymore.

Also, we just bought a shiny new SAN and I can just see how the conversation with the CIO would go when I recommend moving email off the SAN

1MeanAdmin

I'm about to do an Ex 2003 to Ex 2010 migration on a 6000 user environment and have a feeling that Microsoft is too pushy with their RAID-less DAS/JBOD approach - I read that it is the way to go pretty much everywhere (authors reference MS recommendations a lot). Yes it will save money for a <1K user environment where it doesn't make sense to buy SAN that will ONLY be used by Exchange. At the same time it is not good for bigger environments (like mine, where storage is ALREADY there and is SHARED by MANY systems).I have finally found a study that supports my doubts in DAS:
Should Exchange 2010 Use DAS Or SAN - Wikibon

The other benefit is, with DAS you have to have 3 copies of all databases, while with SAN you only need 2 - a way not to waste %50 more storage ( http://www.dell.com/downloads/global/solutions/security/exchange_2010.pdf )

Another pro of SAN is that it is more dynamic when it comes to expansion and usually implies "storage virtualization" - a way to oversubscribe LUNs which leads to a better spindle and bandwidth utilization. We have teams that, for one reason or another, demand a 1TB volume "in case it grows" and only use 50-100GB. Oversubscription is "free credit" in this case: give 100 1TB volumes and use only 20TB of storage. When the utilization grows - buy more spindles accordingly. It's much better than buying 100 1TB drives right away when a spec sheet for a new server/application says you'll be safe with that much space (that you end up not using anyway!)

rsutton

Im doing a SBS2k8/Exchange 2k7 to Standard 2k8/Exchange 2010 migration this weekend. Thanks for the tips here!

HeroPsycho

1MeanAdmin wrote: »

I'm about to do an Ex 2003 to Ex 2010 migration on a 6000 user environment and have a feeling that Microsoft is too pushy with their RAID-less DAS/JBOD approach - I read that it is the way to go pretty much everywhere (authors reference MS recommendations a lot). Yes it will save money for a <1K user environment where it doesn't make sense to buy SAN that will ONLY be used by Exchange. At the same time it is not good for bigger environments (like mine, where storage is ALREADY there and is SHARED by MANY systems).I have finally found a study that supports my doubts in DAS:
Should Exchange 2010 Use DAS Or SAN - Wikibon

The other benefit is, with DAS you have to have 3 copies of all databases, while with SAN you only need 2 - a way not to waste %50 more storage ( http://www.dell.com/downloads/global/solutions/security/exchange_2010.pdf )

Another pro of SAN is that it is more dynamic when it comes to expansion and usually implies "storage virtualization" - a way to oversubscribe LUNs which leads to a better spindle and bandwidth utilization. We have teams that, for one reason or another, demand a 1TB volume "in case it grows" and only use 50-100GB. Oversubscription is "free credit" in this case: give 100 1TB volumes and use only 20TB of storage. When the utilization grows - buy more spindles accordingly. It's much better than buying 100 1TB drives right away when a spec sheet for a new server/application says you'll be safe with that much space (that you end up not using anyway!)

I won't dispute what works best for your environment, but I'll make some points that are more towards why it still may be compelling for other businesses to go SAN-less for their Exchange servers.

• If your SAN is using RAID5/6 (storage capacity penalty of one/two disk in the disk group), or RAID1 or 10 (50%), it's a fair comparison to say that you could go RAID0 DAS for your DAG for the three copies. That's a fairer comparison of disk utilization comparison.
• Even on a SAN, it's generally a bad idea to share spindles with an I/O hog like Exchange, even with Exchange being far less I/O intense than it has been in the past.
• On I/O intense applications, it's generally not a good idea to thin provision Exchange LUNs for performance reasons.

When it's all said and done, SAN storage usually costs more per gigabyte than the same amount of storage in DAS, and you must make up for it by saving money some other way (storage consolidation, TOC calculations with backup, etc.). Exchange very often prevents cost savings you can get via the methods you mentioned (overprovisioning technologies) compared to other applications because a large amount of data is stored, it's relatively higher I/O requirements compared to other apps, etc.

Even if I fully loaded a few 2U servers with drives and RAID0'ed the whole thing, and Exchange only utilized 50% of that, the question isn't how efficiently the drive space is being used. The question is if it's cheaper than what would it have cost presenting the necessary storage for space and I/O needs had you gone with your SAN comparatively. I don't mean to suggest which will win in every scenario. My point is look and make the judgement. Don't assume the SAN will always be better for Exchange 2010 even in large organizations.

I've been in enough environments to know, especially in large orgs who have separate admins for the SAN and Exchange, that it's not all roses for SANs. Unless you save significant costs or gain some useful functionality with a SAN, there's a compelling reason to keep it simple and off the SAN. With that said, there are many reasons to keep it on the SAN, too, like SAN optimized backup/recovery products, etc.

1MeanAdmin

HeroPsycho,

Thanks for the tips, I totally agree with everything you said. My point is that it was misleading for me to hear Microsoft recommend and only talk about pro's of DAS in Ex2010 like there's no point in using SAN (from what I've read in several dozen articles as well as heard at several Microsoft trainings and conferences). I just thought my case would reveal another perspective on Exchange 2010 storage. And yes, in the end, some features of our SAN leaned me towards using it even at a somewhat higher cost.

Claymoore

1MeanAdmin wrote: »

I'm about to do an Ex 2003 to Ex 2010 migration on a 6000 user environment and have a feeling that Microsoft is too pushy with their RAID-less DAS/JBOD approach - I read that it is the way to go pretty much everywhere (authors reference MS recommendations a lot). Yes it will save money for a <1K user environment where it doesn't make sense to buy SAN that will ONLY be used by Exchange. At the same time it is not good for bigger environments (like mine, where storage is ALREADY there and is SHARED by MANY systems).I have finally found a study that supports my doubts in DAS:
Should Exchange 2010 Use DAS Or SAN - Wikibon

The other benefit is, with DAS you have to have 3 copies of all databases, while with SAN you only need 2 - a way not to waste %50 more storage ( http://www.dell.com/downloads/global/solutions/security/exchange_2010.pdf )

Another pro of SAN is that it is more dynamic when it comes to expansion and usually implies "storage virtualization" - a way to oversubscribe LUNs which leads to a better spindle and bandwidth utilization. We have teams that, for one reason or another, demand a 1TB volume "in case it grows" and only use 50-100GB. Oversubscription is "free credit" in this case: give 100 1TB volumes and use only 20TB of storage. When the utilization grows - buy more spindles accordingly. It's much better than buying 100 1TB drives right away when a spec sheet for a new server/application says you'll be safe with that much space (that you end up not using anyway!)

Well I read the article that you referenced and I doubt the author has ever designed an Exchange environment. You can listen to the accountant with the spreadsheet or you can listen to those of us in the field who do this for a living.

I used to be a SAN admin and it is hard for me to recommend pulling any storage away from the big arrays, but it makes a lot of sense in this case. I have had a few clients say 'but I just bought all this storage for my SAN' when I recommend putting the mailbox databases on DAS. My response is usually 'and I just gave it all back to you for your other applications.' Trust me, you'll find a use for it.

Previous Exchange HA solutions required SANs for shared storage clustering. 2007 gave you some choices, but now 2010 uses a 'shared nothing' approach. Since each server in the DAG must have copies of all databases in the DAG, that's a lot of high dollar storage in one box just to provide service availabilty. Spreading that storage out on DAS can save you money and allow you to place a mailbox server at a different data center without a SAN to provide site survivability.

You claim that putting Exchange on DAS is not cost effective for large organizations, but 2010 was piloted at Microsoft and is the back end for the [EMAIL="Live@EDU"]Live@EDU[/EMAIL] free hosted mail service for schools. The recommendation for putting Exchange on DAS came from the lessons learned on those extremely large deployments.

Also, keep in mind that Microsoft is no longer competing against Notes and GroupWise. They are competing against Google and their mail hosting solutions with large storage limits. They has to design a solution that delivered high availability with large mailboxes and low storage cost or risk losing customers. Once the customer starts hosting mail with Google, it could be a slippery slope leading them to Google Docs and Chrome.

And to the author's point about MS not recommending virtualizing Exchange, that's not entirely accurate. Virtualizing the CAS, HT and Edge Transport roles is fine. You can even virtualize the Mailbox role, but combining Exchange HA and virtualization HA is not supported by MS. This was the same in Exchange 2007, while 2003 is not supported in any virtual environment.