Internal vs Cloud-Based Exchange

Deathmage

With our recent events with Rackspace there seemingly known track records of unreliable datacenter service, I've been tasking myself with the thought of moving Exchange to a different provider an/or moving Exchange back in-house. Needless to say we've been offline for emails for 35 hours so far for 4 companies.

I never designed our VMware n+1 cluster to maintain an exchange box. I'm thinking that if I move exchange back in-house I'll need to go to a n+2 design with one of the servers being a FT server plus I got a feeling I'll need to add exchange to their own vlan to keep traffic congestion low and we'll probably need a spam firewall installed like a Barracuda. I'm also contemplating acquiring another SAN since our emails alone is over 15 TB's in size.

Curious what else I might be overlooking with moving a Exchange server out-in-the-cold and moving in back in-house.

Wondering how many others here have weighed the option of cloud-based Exchange or just keeping Exchange in-house?

TheProf

Most of my clients are on-premises, although Office 365 is getting some good attention and they already won over some larger customers, 1000+ user deployment. If you want to host in the cloud, consider O365 as an alternative.

With that said, in terms of bringing exchange in house, not sure why you'd design N+2 if you're adding Exchange to your VMware cluster. Of course you'll need to ensure that you have enough resources to run the workload, etc. But at the end of the day, adding a heavier VM to the mix doesn't mean you'd need to tolerate a failure of two hosts in your vSphere cluster. It really boils down to your requirements... Ask yourself the question, why go with N+1 or N+2, etc.

Also, if you're looking for things like High Availability for Exchange, the best practice is to use the native Exchange functionality like Database Availability Groups, CAS Arrays, and Load Balancers. HA is not application aware, and with FT (if you're referring to Fault Tolerance feature in vSphere) you're limited to 1 vCPU on vSphere 5.5 which I am sure won't be enough for Exchange, unless you're on vSphere 6 which now has support for 4 vCPU in FT mode.

I'd recommend to check out the following documents, really useful info when I was deploying Exchange on vSphere:

http://www.vmware.com/files/pdf/Exchange_2013_on_VMware_Best_Practices_Guide.pdf

http://www.vmware.com/files/pdf/exchange-2010-on-vmware-best-practices-guide.pdf

iBrokeIT

Office365 is the bandwagon most corporations are jumping on, might as well join the party

Deathmage

Thanks Gents, looking into Office 365.

Did a roughly design of Exchange in-house again and it will easily cost me well over $25k in hardware/software, we have 5+ email domains and if you know Exchange they don't co-exist well in the schema very well on one box..

TheProf

Deathmage wrote: »

We have 5+ email domains and if you know Exchange they don't co-exist well in the schema very well on one box..

Misunderstood what you mean by this, exchange can easily support multiple domains.

But anyways, it definitely can get expensive hosting something as critical as Exchange in house.

Claymoore

Deathmage wrote: »

if you know Exchange they don't co-exist well in the schema very well on one box..

I do know Exchange very well and I don't know what you mean by this. Multiple email domains - I've seen installations with over 100 working fine. Multiple AD domains - I've worked with multiple Exchange servers in multiple AD domains in same and separate forests and it runs fine.

However, Exchange is designed to be deployed on physical servers with local storage. Virtualizing it requires additional configuration, cost, and dependencies that affect service levels. Your best bet is to move to Office 365.

Deathmage

The problems we keep having with our Rackspace hosted Exchange boxes is Rackspace told us that we couldn't have alias setup on say three of our email domains cause all three of the exchange domain sat on the same exchange box and they explained that is caused a schema issue.

To me it should have worked fine if they made is like companyA.parentcompany.com, companyb.parentcompany.com, companyc.parentcompany.com but they never setup up the email domains as domains on the forest parentcompany.com. They instead just made them their own email domains. They were indeed suppose to be sub-domains of the parent domain. Rackspace told us it would take weeks to correct the Schema issue.

I'll be the 1st to admit, Exchange is just not my cup of tea yet so I don't understand the full complexities of Exchange or if Rackspace was blowing smoke up my a**. It's on my list to get Messaging after SI.

emerald_octane

Intermedia is good too. so nice to not have to worry about practically anything except client side stuff.

techfiend

No email for 35 hours?!

I thought the occasional minor issue like missed email or not being able to send to certain addresses in O365 was bad. Normally O365 is pretty solid but lately it's been a bit of a nuisance. I personally want to do exchange 2013 on premise to have control of it but its not economically feasible for most smb's.

In this case I think 15TB of email would raise an issue with O365.