Exchange 2013 Site Resilient / DR setup; remove DR CAS server from serving DR-local users
we got exchange 2013 deployment in our primary data center with AD Domain = domain1.com and AD site= primary-Site and with two exchange 2013 servers each with CAS+mailbox roles (srv1.domain1.com + srv2.domain1.com) setup as DAG and file-share witness server in same data center filesrv.domain1.com. each mailbox database has 2 copies one active and one passive. both CAS servers are load-balanced by a separate dedicated load balancer for all exch services like OWA, ECP, EWS,MAPI,... in this office the owa namespace is = https://owa.domain1.com, where all users Outlook clients connect and discovers to their mailboxes using MAPI/HTTP to https://owa.domain1.com/... which is fine since the outlook clients are in the same LAN of the exchange servers data center 1 and belonging to domain1.com AD domain. We wanted to achieve Site Resiliency (a.k.a DR) to our exchange setup. we have already a working data center 2 in another country with: AD Domain = domain2.com and AD site= Branch-Site and with two exchange 2013 servers each with CAS+mailbox roles (srv1.domain2.com + srv2.domain2.com) setup as DAG and fileshare witness server in same data center filesrv.domain2.com. each mailbox database has 2 copies one active and one passive. both CAS servers are load balanced by a separate dedicated load balancer for all exch services like OWA, ECP, EWS,MAPI,... similar to the primary office, this branch office has local LAN Outlook users (belonging to domain2.com AD) connects to their mailboxes which are hosted on the domain2 Exchange owa/DAG this office owa namespace is = https://owa.domain1.com, where all users Outlook clients connect and discovers to their mailboxes using MAPI/HTTP to https://owa.domain1.com/... which is fine since the outlook clients are in the same LAN of the exchange servers data center 2 and belonging to domain2.com AD domain. Notes: both domains domain1.com and domain2.com have full trust and belong to same AD forest. VPN links exist between both offices and functional. both domains are at the same level/ no child domains exist. all users primary SMTP domain is unified = mailto:name@email.com internal DNS autodiscover.email.com ==> owa.domain1.com thru Outlook connection status we can identify which CAS the user is connecting to. Case Scenario: We wanted to achieve Site Resiliency (a.k.a DR) to our exchange setup in the Primary Office. we choose the branch office to be this DR site for our Exchange services in the primary office. We prepared a new AD DC + DNS + GC (srv3.domain1.com) in branch office in AD site Branch-Site with dedicated IP of branch office range along. We prepared a new Exchange 2013 server (srv3.domain1.com) in Branch-Site with branch site IP range to be CAS+MBX roles. we joined the srv3.domain1.com to DAG of the primary office. we added 3rd copy of the databases existing in primary office and got replicated successfully to srv3.domain1.com. also same virtual directory names we configured on srv3.domain1.com similar to what is configured for srv1/2.domain1.com Issue: the strange behavior after deploying the 3rd exchange server srv3.domain1.com in the branch office site, here is that the local LAN users of branch office (whose user accounts belong to AD domain domain2.com and have mailboxes under branch exchange setup DAB of srv1/2.domain2.com with https://owa.domain2.com), now these outlook LAN clients connect to https://owa.domain1.com (which is hosted over WAN on primary DC) which is hosted in the primary office data center. we don't want our branch users outlook clients to connect over Internet WAN link to the primary exchange CAS (https://owa.domain1.com). these outlook clients used normally to connect to the branch exchange CAS owa.domain2.com. Required to achieve: We want srv3.domain1.com CAS+MBX as DR server to switch over to it from primary office to it in case of primary DC is down and to keep the existing branch users connecting normally to their exchange setup owa.domain2.com and NOT to use the owa.domain1.com by any means