Exchange 2010 DAG across sites - different subnets vs stretched VLAN

In the scenario where you have an Exchange 2010 DAG (using Windows 2008 R2 failover clustering) with members servers in two AD sites where "Site A" is the normally active site and "Site B" is the DR site, does Microsoft actually publish any guidance or recommendations as far as using separate subnets in the two sites vs stretching a "Site A" subnet via VLAN?

I think most implementations use separate subnets however I'm aware that some have implemented this using a stretched VLAN.  Seems to me that the latter approach is more complicated as well as introducing potential issues during a switchover to "Site B" during a DR - i.e. the DAG member at "Site B" belongs to a subnet (AD site) from the primary data center and all servers (including domain controllers) at "Site A" are down.

Is anyone aware of any specific guidance or recommendations from Microsoft regarding these two approaches. 

Not looking for speculation, just some specifics from Microsoft, thanks. 

Sam

July 16th, 2013 3:55pm

You need a pretty good technical reason to go with a stretched site. The product is designed to be across multiple AD sites in that case as it will have an effect on mail flow and client access. Here's the technet article http://technet.microsoft.com/en-us/library/dd979781(v=exchg.141).aspx
Free Windows Admin Tool Kit Click here and download it now
July 16th, 2013 5:02pm

Thanks for taking the time to replay but again

Is anyone aware of any specific guidance or recommendations from Microsoft regarding these two approaches?

Not looking for speculation, just some specifics from Microsoft, thanks.

The article you quote is just some Microsoft examples and not what I requested in my original post

July 16th, 2013 6:47pm

Sam, Are you looking on information about how you would implement either method? Or guidance as to which to go with? The guidance from Microsoft is that separate physical sites should be defined as separate AD sites. This goes for Exchange as well. You will notice that the TechNet guidance does not provide a reference solution for using a stretched VLAN because the product was designed to use the information in AD. Here is the guidance on how to define an AD site and the criteria to use http://technet.microsoft.com/en-us/library/cc782048(v=ws.10).aspx Sites in Active Directory represent the physical structure, or topology, of your network. Active Directory uses topology information, stored as site and site link objects in the directory, to build the most efficient replication topology. You use Active Directory Sites and Services to define sites and site links. A site is a set of well-connected subnets. Sites differ from domains; sites represent the physical structure of your network, while domains represent the logical structure of your organization. There are blog posts and third party articles available discussing how and why some people have implemented Exchange in stretched sites/VLANs. But I'm not certain if that's what your looking for.
Free Windows Admin Tool Kit Click here and download it now
July 16th, 2013 9:00pm

Thanks for your reply David. Yes I know how it all works and I would normally use separate subnets at each site for the DAG.  I'm looking for guidance or recommendations specifically from Microsoft re the two approaches. i.e. what is and isn't supported or recommended by Microsoft. I've looked everywhere but do I not see it and thats (another) hole in the MS doc.  I need this sort of supporting info when designing these solutions and when I communicate with my clients.

When you say "The guidance from Microsoft is that separate physical sites .... This goes for Exchange as well" , I dont think you know that for a fact. Wheres the MS doc that says exactly that for Exchange DAGs across sites? Same goes for the "blog posts and third party articles" .. people can say whatever they want in those forums but it doesn't mean its true or what MS would advise.

July 16th, 2013 10:12pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics