Can I get high availability by installing Exchange on a second server and replicating?

pts.
Tags:
Microsoft Exchange 2000
Windows 2000 Server
The company I'm with can't afford clustering. They have 3 x W2k servers, one of which has Exchange 2000 on it. Is it possible to install Exchange 2000 on another server and replicate the mailbox to it? Would this server take over if the main server went bang? (Give or take a little manual intervention) Is replication configurable through Exchange or is a 3rd party tool the only way. They have Backup Exec 8.6 but can't afford the Agent for Exchange! Need to do this on the proverbial shoestring... Many thanks! John

Answer Wiki

Thanks. We'll let you know when a new response is added.

The solution you propose is not possible with Exchange natively (to the best of my knowledge), but is possible with a third party product such as DoubleTake (http://www.doubletake.com/) or EMC’s RepliStor http://software.emc.com/products/software_az/replistor.htm). We use DoubleTake for file server replication and we’ve been pretty pleased with, and we’re looking to do Exchange replication with it in the future.

Discuss This Question: 18  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Aalborz43
    As far as I know, as you've described your situation, no it's not possible. In fact if there's a 3rd-party out there that can do this, I'd like to buy their stocks! However, if one of those servers is under-utilized or you have an extra PC laying around with decent CPU speed and plenty of memory (1GB minimum), you can try virtualize your Exchange cluster. You'd run VMware or MS Virtual Server on the box and set up Exchange clusters that way. As for BUE agent for Exchange, you don't need it to backup Exchange. NTBackup is Exchange-aware and will do just fine.
    0 pointsBadges:
    report
  • Pkmccroskey
    To add to aalborz43's response about using NTBackup, and to simulate daily asyncronous replication, you could have one of the other servers do the backup of the Exchange server, and then restore it to itself. BUT, one major issue is that it cannot be on the same domain and it will have to have the same machine name for the restore to work -- there can only be one Exchange machine with the same name on the same domain, or else it totally screws up everything. Just a thought. (And I hope I am remembering that correctly.)
    0 pointsBadges:
    report
  • Aalborz43
    Yes DoubleTake is good and has a good reputation, but I don't think it applies to John's situation, because they're on a shoestring budget. They can't even afford to buy BUE Exchange agent, let alone pay for a solution like DoubleTake or the like.
    0 pointsBadges:
    report
  • Brandonbates
    As a still fairly low cost solution, virtualize your exchange server in vmware, either by imaging your current server and using that image to build a VM, or by reinstalling exchange on a new VM. Then either install linux on the server to run VMServer or if you have the licenses install VMServer under windows. Then store your VM files on shared storage, (FC, iSCSI, or maybe Network CIFS share). This will give you one level of redundancy in that if that server HARDWARE dies, you can restart the VM quite easily from another machine. The next level is to backup the VM files and/or do a traditional NT Backup within the VM (preferable to be on the safe side) from the shared storage to another physical locatino (in case the shared storage dies). The only way to get true 24/7 availibility is to run a exchange cluster. This solution is a next-best-thing as an "uh-oh it died, quick start it up on another machine" 5-minutes-from-notice solution. Not bad for most small-medium sized businesses.
    0 pointsBadges:
    report
  • adanbluearc
    You said you already have 3 Exchange servers. You could do Active/Active clustering, although I believe you can only do it with 2 nodes in Exchange, there are other limitations as well. You also need Windows Enterprise Edition. There might be additional restrictions in the 2000 versions. The Virtual Server solution is a good idea, but I think more information would be warranted. Whichever way you do this, you will need to do fresh install of the servers and transfer mailboxes to it. For best results use new versions of OS and Exchange. So it's going to cost something, perhaps you want to focus on the most cost effective way to meet your requirement, and your management can choose to decline it. - are all servers currently in same LAN? - how many mailboxes each? - can you afford to upgrade to Windows 2003.
    0 pointsBadges:
    report
  • JohnTWT
    No, we have three W2k servers. One of these has Exchange on it, one has our ERP solution and one is a "spare" which I am using for backups etc. I like the VM idea - has anyone got this totally nailed down and in production? Ref: Exchange/Windows 2003 - what additional advantages would these give me? I know clustering comes out of the box with W2k3 but would this enable my theoretical software solution to be realised more easily?
    0 pointsBadges:
    report
  • JohnTWT
    "You'd run VMware or MS Virtual Server on the box and set up Exchange clusters that way." The lack of shared storage means clustering won't work for us - wrong hardware and wrong software. However! Starting to think a bit more about the virtual solution. If I run a couple of instances of Windows on one server, then there IS shared storage. How the NIC configuration would work (Private NICs etc) I just don't know. Any thoughts? This would take care of software failure. Of course, if the hardware goes down then we're still screwed. :(
    0 pointsBadges:
    report
  • Enterprisephil
    I would go this way....Check this article out.... http://www.lanarchitect.net/Articles/ExchangeRecovery/ its thorough, excellent and cheap. The following article has some Gotchas on installing Exchange on a spare recovery server and the comments by the readers indicate some good relevant advice. http://articles.techrepublic.com.com/5100-1035-6070680.html http://techrepublic.com.com/5206-6230-0.html;jsessionid=YyDE-iij9ohxwQFL8q?forumID=3&threadID=194719&start=0 Running VMware clientservers with Exchange is good but be aware that the VMware server needs to have some hardware grunt. Secondly, the two exchangeserver clients should not ever be started at the same time as you would lose some sleep and be paid overtime. (yyaah right!) Bottomline...Reading some of the replies caused me to think... Exchange backup and restore is time consuming. Domain controllers are finnicky and Vmware is a bit extra on the side. Ghost imaging is cheap and fine for me provided I have some space to put the image.
    0 pointsBadges:
    report
  • Msfttim
    Remember that up to 90% of reported system outages are not hardware related and a large majority of Exchange Server outages are storage failure related. So that the most important item is backup. NTBackup can perform an online or offline backup to tape or disk. I see that you have 2 primary requirements. First is reduncancy via such methods as replication. Second is little is no cost. The Microsoft support method in Exchange 2000/2003 is clustering, which at minimun requires two servers in Active/Active or Active/Passive. (note that Active/Active configuration are not recommended), which requires external shared storage. Extra hardware cost/no software cost. Other option is to use a second server for dial-tone recovery. This is where you mount the databases from backup (you can use NTBackup) to second Exchange Server. Time consuming/No extra hardware/software cost. For Refer to http://www.microsoft.com/technet/prodtechnol/exchange/guides/UseE2k3RecStorGrps/92ae44a2-034d-478a-9ea0-261dde5b8ff1.mspx?mfr=true and http://www.msexchange.org/tutorials/Exchange-Dial-tone-Restore-Method-Part1.html The last option is to upgrade to Exchange Server 2007 which support Local Continuous Replication (LCR) also known as log shipping/replication.
    0 pointsBadges:
    report
  • JohnTWT
    Great articles there - many thanks. It would appear that disk imaging is a cheap and dirty solution. The more elegant solution may be to add Exchange 2007 - and the 64bit box it sits on. Ghosting our main production server sounds scary given that it has failed on two XP Pro clients recently...
    0 pointsBadges:
    report
  • Brandonbates
    Disk imaging is a good solution (I do that), however I have been burned very badly by disk imaging. Disk images do not always restore to DIFFERENT hardware. The physical system must be based on the same storage controller for the boot drive and in some cases the same chipset, etc. The "microsoft supported method" for forklifting an os (Including applications) is NTBackup. So now I do both, I image my system occasionally (like once a year or so, doesn't really matter). Then I run NTBackup nightly. That way I can just reimage then restore the backup, or if the hardware dies, reinstall and restore the backup. That's why I'm moving to VMware is the hardware independence. Heck I could run the server on my desktop if I had do :) P.S. It's a good idea to do use EXMerge to backup your mailboxes to PSTs. As mentioned in the article just referenced, microsoft's supported exchange recovery is really delicate. PSTs are much more portable (I.E. install a new exchange server, different name, domain, whatever and PSTs always restore fine. Just make sure to do a directory/AD backup as well if need be). Gives me some peace of mind. Once an exchange store goes really bad, its a long time to get it back if you ever do.
    0 pointsBadges:
    report
  • JohnTWT
    Good comments on Disk imaging and using NTBackup - belt and braces. As it happens, I have been waging a gentle war on users to prune their mailboxes and have used ExMerge to create just the PST's you mention. Belt and two sets of braces! May I ask what imaging solution you use? I found Ghost 2003 on the system when I arrived so have been using that...
    0 pointsBadges:
    report
  • JohnTWT
    Where's the downside in this theory please? I have a mirrored pair of disks which hold the system and Exchange. (Databases and data held on a different pair) I offline one of these and stick it in the safe. I put another disk in and rebuild the mirror. If everything goes bang, I offline both disks and put the original disk back in. I bring that online and if all is well, add another disk and rebuild the mirror. Just seems a bit quicker than imaging. Anyone think this sucks and care to tell me why? :)
    0 pointsBadges:
    report
  • AaronCutshall
    One thing to keep in mind with exporting Exchange to PST files is that you loose any single storage advantages. In other words, if multiple people receive the same attached document, it is stored only once and each mailbox message merely points to it. When you export to PST files, the document will be replicated for each PST. When imported back into Exchange, each document is still stored within each individual mailbox. Hence, your storage requirements may increase after restoring from PST files.
    0 pointsBadges:
    report
  • Brandonbates
    In reply to #14: Actually before I did disk imaging, that's what I did. Even now, that is one of the ways I image systems that are online or can't afford much down time. By mirroring the disk to another HD, yanking the mirror, imaging it (so I don't have to tie up a hard drive) then putting it back. I have some nervous customers that just leave the extra HD on a shelf for an emergency. That in conjunction with NT Backup allows for a decently quick restore compared to a reinstall. Also more recently I've messed with doing a mirror to an iSCSI volume so it's a little more hardware friendly (hot-swapping and all) I use Paragon Drive Backup 5.5 (Didn't like 6 as much so I still use the old one.) More recently though I have been using the Linux System Rescue CD http://www.sysresccd.org/ since I can (on most machines) boot up on the cd and image that machine to a network share over the network. Whereas with DB55 I had to have a second FAT32 disk handy to back up to (DB6 supports backup to NFTS) I still use both though. Just always make sure you have a full NTBackup fairly recently. If the hardware goes kak you might be in real trouble if you change to different/newer hardware. Just s note if you do the mirror thing, DONT BREAK THE MIRROR, just yank the drive (Ideally shut the system down first, otherwise at least qwell the system as much as you can, or perhaps pause/stop exchange store). If you break the mirror it may give your system drive a different drive letter (or the mirror copy) Pain in the neck to change back (a little scary too wondering if it will still boot :) (Voice of experience) Yes, watch out for the PSTs on restore, the duplicate data does add up. For me to the tune of about 20%, but better than nothing and a heck of a lot easier way to forklift users & fix mailboxes)
    0 pointsBadges:
    report
  • adanbluearc
    WRT to Exchange 2003: one of the big improvements of Exchange 2003 that is relevant in this context is Recovery Groups. So basically you can restore a mailstore into the same server (but a separate temporary area) while the same mailstore is online. This is good for restoring individual mailboxes without resorting to brick-level backups. Also, this is pretty crucial in a 'dialtone restore' situation. With regards to mirroring the hard drives and removing them manually while the system is running, that be the equivalent of dirty shutdown on that drive. In addition the database and the logs could be in an inconsistent state so you could have problems if you have to bring them up in a recovery situation. If you have circular logging enabled or you have logs and store files in the same drive it could be better but neither of these are recommended for other reasons. The ghost technique is superior in this respect. I think a scheduled NTBackus are better and free. You could also use separate storage groups and mailstores and spread out your mailboxes accross them, you have up to 19 stores in total (you have Exchange Enterprise and not standard I hope). This way if one of the stores goes down you have less recovery time to face. If you use redundant components in your server (hard drives, power supplies), have a good hardware support contract, keep your system regularly patched, install antivirus software, and follow other best practices you could get pretty good uptime. At this point, the additional cost of doing cluster to get some additional 9's to the right of the decimal point might not be worth it in your environment.
    0 pointsBadges:
    report
  • Enterprisephil
    WRT #14.... as a h/w technician, handled plenty of clients who did just that and then called to say it dont work so smooth in the rebuild or that the redundancy is lost once a hdd in the mirror pair was removed. The scsi controller and the backplane is involved here in the intelligent control of a mirror pair hdd losing its validity and integrity. In the case of SMART errors or h/w failures, the electrical signals are conveyed back to the controller, which initiates a shutdown process to the specific hdd. Once the shutdown occurs, the hdd can be appropriately replaced. When hdd are unceremoniously removed, without the controller being informed correctly, there is a greater chance of the existing mirror failing totally. A single drive in a mirror pair may revert to a concatenous single hdd which is unable rebuild or mirror again. This is an ineffective and an unresilient solution for any company worth its salt.
    0 pointsBadges:
    report
  • Wrobinson
    Yes, there are some good offerings from Doube-Take and CA XOsoft that will allow you to replicate Exchange databases from a source server to a target server or one source to many target servers for disaster recovery and high-availability. The steps to fail-over can be manual or automated depending on the desired configuration. The caveat here is that these solutions are host-based and as such bears some operational overhead on the Exchange servers. They also run in kernel space and have been known to cause fatal exceptions due to high utilization.
    5,625 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following