Thanks for the great info! Rami
From: [email protected] [mailto:[email protected]] On Behalf Of ccollins9 Sent: Monday, September 08, 2014 5:21 PM To: exchange Subject: Re: [Exchange] Exchange 2013 and DR site This is our same setup. We are currently in production with Exchange 2013/Kemp and it is working very well so far. EX2013 technology changes make it VERY friendly to load balancers now. We are now planning/testing/building out a new DR site. We haven't officially tested this yet, but I know it will work. The trick with allowing the replicated Kemp to run in a DR scenario is to record the MAC address that is being used on the original Kemp installation and manually entering that MAC into the replicated copy when you must bring it up. VMware allows for the editing of the MAC in the settings of the VM while it is off. Its possible whatever your replication technology is using will also replicate the original MAC, but that's uncertain. In your production Kemp, you can actually list both the DR and production servers in the Kemp to service Exchange Virtual Service. At that point you can either choose to live load balance traffic between your DR and production servers (assuming your bandwidth to DR site will allow it), or you can weight it so the DR servers only get used if the production servers are unavailable, or you can simply disable the DR servers in the Kemp until you manually re-enable traffic to them in the event of a disaster. If your production and DR servers are on a separate subnets, Kemp allows for adding "real servers" from disparate subnets after enabling the setting "Allow Remote Addresses" on the VIP. This option is available after setting the global setting for Non-Local Real Servers. >From the Kemp documentation: Enable Non-Local Real Servers must be selected (in System Configuration > Miscellaneous Options > Network Options). Also, Transparency must be disabled in the Virtual Service. Further, we have two DNS records for email: 'autodiscover.domain.com<http://autodiscover.domain.com>' and 'email.domain.com<http://email.domain.com>'. Email.domain.com<http://Email.domain.com> is an 'A' record that points to the Kemp VIP and autodiscover is an alias record for email.domain.com<http://email.domain.com>. So, what that all boils down to is that in a DR scenario, all we would have to do is go into DNS and change the email.domain.com<http://email.domain.com> A record to point to the Kemp VIP that we bring up in the DR subnet. Kemp makes a product that manages this for you called KEmp GEO, but we see no need to use KEmp to manage this simple DNS change. I've been working very closely with Kemp for a while now in setting all this up with our migration from EX2010 to EX2013, so if you have any questions, let me know. On Mon, Sep 8, 2014 at 6:12 PM, Rami SIK <[email protected]<mailto:[email protected]>> wrote: Hi All, I have one main and one DR site with exchange 2013 servers with DAG. In the main site, I have a KEMP CAS load balancer (a VM) as a front end for all my Outlook and BES server. My plan for testing DM, I want to bring KEMP VM (that would be the replicated VM copy of the main site) up in the DR site and do a small config change to point to the DR site Exchange server. Do you think that would run? Anybody used KEMP and do something similar for their DR solution? Or KEMP load balancer would not even run in DR site due to changed MAC address (I am thinking of license requirements that KEMP may look for). Any idea or feedback appreciated? Rami ________________________________ If this message is not meant for you, do not use it - please let us know, and then delete it. We try hard to keep our messages and attachments free of viruses and other malicious programs, but are not liable if our precautions don't prevent their spread.
