Tanto el orden de las preguntas en el cuestionario, como el orden que tengan las respuestas al interior de cada pregunta cerrada pueden influir en el resultado, es

■ Plan certificate requirements for site failovers

■

■ Predict client behavior during a rollover

Planning site-resilient namespaces

In Exchange Server 2010, failover to a second site of the client access layer involved a change in the namespace. The namespace is what users and clients need to connect to Exchange to reach their mailboxes. For example, mail.contoso.com would be a namespace for the Contoso Pharmaceuticals email service and dr-mail.contoso.com might be a namespace needed when mailboxes are moved to the DR site. If you used protocol specific namespaces such as smtp.contoso.com for transport and owa.contoso.com then you would need disaster recov-ery/second datacenter versions of the primary URLs as well.

In the event of a full site failover, it is possible to update DNS and move the entire namespace to the secondary site. But while some databases are on the primary site and oth-ers on the secondary site, and the client access layer is operational at both sites. This meant that in Exchange 2010 you needed two namespaces. The primary driver for this was that

con-ptg14200515 nectivity between the CAS layer and the mailbox databases was RPC based which required a

fast network with low latency between the tiers and so performance issues could occur if the CAS tier was in a separate site from the mailbox database. That is, your mailbox was on a da-tabase in the secondary datacenter but you were using a CAS server at the primary datacen-ter. In Exchange 2010, cross-site access could be disabled and then CAS connectivity would failover to the remote site, but a namespace change would occur.

In Exchange 2013, all connectivity between Exchange Servers has been moved to the HTTP protocol (and SMTP for transport, and IMAP or POP3 if using an older client). There is no cross-server RPC connectivity. This means that the client connection is ultimately made to the server that contains the active mailbox database for that user’s mailbox and that all connec-tivity happens to and from that server. Exchange Server 2013 provides a proxy layer, known as the CAS role. This proxy layer ensures that user connections are made to the correct mailbox server. Therefore a user or client can connect to any CAS role server, authenticate to prove who they are, and then the CAS role proxies their connections to the mailbox role server that holds their active mailbox database. This is shown in Figure 2-12.

FIGURE 2-12 CAS proxy to active mailbox database

In Figure 2-12, it does not matter if the user connects to either of the two CAS servers shown because both of them will proxy the user to the same mailbox server, the one that is

ptg14200515 REAL WORLD MULTIPLE CAS ROLES AND MAILBOX ROLES

Though Figures 2-12 and 2-13 show the CAS role and the mailbox role as installed on sepa-rate servers, this is for the purpose of illustration only. Microsoft recommends that you use multi-role installations.

Consider Figure 2-12 in real life. This would require five Exchange Server and Windows Server licenses as well as the hardware or virtual resources to run this configuration. If the company requires three mailbox servers, installing CAS and mailbox on three servers reduces the license count, reduces the hardware or virtual resources, reduces the servers to manage, and increases the high availability of the CAS role from two servers to three, all at a cost saving both for deployment and ongoing running costs.

When Exchange Server 2013 is installed into more than one datacenter, and some or all of these datacenters have an inbound Internet connection, it is possible to use different tech-nologies to direct the user at a specific datacenter. For example, this could be a technology that routes the user’s connection to their geographically closest datacenter rather than the datacenter that holds their active mailbox.

The Exchange CAS layer will then direct the traffic using the same protocol that the user connected with, and which is a protocol that is capable of dealing with lower latency links, i.e.

HTTP, to the mailbox server that is active for that user’s mailbox.

This can be seen in Figure 2-13, which is an expansion of the network shown in Figure 2-12. If in this figure the user has a mailbox in Ireland but was travelling in the United States (US), they would be directed to the San Antonio datacenter as that is closer to them over the Internet. When on the private network of the company, the endpoint the user has connected to in San Antonio is then connected to the location of the mailbox server in Dublin. The user receives fast Internet connectivity rather than a high latency connection to another part of the world over the public Internet, and the performance they see from Exchange Server is quick. This is similar to the model that Office 365 uses with the Exchange Online service, and importantly for namespace simplicity, allows the user to use a single namespace regardless of their location or the location of their mailbox. In this example, if this was Contoso, all users throughout the world would use mail.contoso.com to access Exchange Server.

ptg14200515

FIGURE 2-13 Single namespace design with multiple datacenters

MORE INFO USING THE LAB ENVIRONMENT

MVP Paul Cunningham has written a blog post at http://exchangeserverpro.com/exchange-2013-client-access-server-high-availability/ which shows how to configure the Outlook Anywhere namespace for high availability and quick failover times in a lab environment using DNS round robin.

This is an excellent scenario to test in a lab as it introduces you to the concepts of load balancing without the layout of a load balancer, though for real world experience we recommend downloading a trial virtual load balancer from one of the vendors listed at http://technet.microsoft.com/en-us/office/dn756394.

In past examples, we have used both bound and unbound namespace models. A bound namespace is where the name is specifically targeted to a single datacenter and an unbound model is where the namespace works regardless of which datacenter you connect to.