If deploying the unbound model, connectivity to all sites in the unbound namespace should have low enough latency, and high enough bandwidth to support client connections from all client sites. There is no way to control which site client connections will go to in this model, so assume 50% to each site in a 2 site scenario. You will have challenges with this model if some sites have poor connectivity to one of the Exchange sites. In those cases using the bound namespace model to better control client connectivity traffic may be the better choice.
For reference: http://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-exchange-2013.aspx
If deploying the unbound model, connectivity to all sites in the unbound namespace should have low enough latency, and high enough bandwidth to support client connections from all client sites. There is no way to control which site client connections will go to in this model, so assume 50% to each site in a 2 site scenario. You will have challenges with this model if some sites have poor connectivity to one of the Exchange sites. In those cases using the bound namespace model to better control client connectivity traffic may be the better choice.
For reference: http://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-exchange-2013.aspx
- Proposed as answer by Winnie LiangMicrosoft contingent staff, Moderator 23 hours 7 minutes ago
If deploying the unbound model, connectivity to all sites in the unbound namespace should have low enough latency, and high enough bandwidth to support client connections from all client sites. There is no way to control which site client connections will go to in this model, so assume 50% to each site in a 2 site scenario. You will have challenges with this model if some sites have poor connectivity to one of the Exchange sites. In those cases using the bound namespace model to better control client connectivity traffic may be the better choice.
For reference: http://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-exchange-2013.aspx
- Proposed as answer by Winnie LiangMicrosoft contingent staff, Moderator Monday, May 25, 2015 8:19 AM
Hi
I agree with DJ Grijalvas opinion. The Outlook client would not do any changes when connect to the Exchange server with the unbound mode.
Generally, the unbound mode use the single namespace for Exchange connection. Therefore, the connection namespace in Outlook side would keep the same configuration. In server side, when the service requests are sending to Exchange side with mail.domain.com namespace, the unbound mode would use DNS Round-Robin between two datacenters to distribute the request to the specific datacenter and deal with the request.
Regards,
Hi
I agree with DJ Grijalvas opinion. The Outlook client would not do any changes when connect to the Exchange server with the unbound mode.
Generally, the unbound mode use the single namespace for Exchange connection. Therefore, the connection namespace in Outlook side would keep the same configuration. In server side, when the service requests are sending to Exchange side with mail.domain.com namespace, the unbound mode would use DNS Round-Robin between two datacenters to distribute the request to the specific datacenter and deal with the request.
Re
Yes, you should use a bound namespace if you want to minimize latency at the expense of immediate recovery of failures. My preference is generally the other way around.So, would it be safe to say that if all Outlook clients are at one site, they should connect to only the servers at their site in a bound scenario?