10135 a xb

1,005 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,005
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
55
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A Presentation: 60 minutes Lab: 60 minutes After completing this module, students will be able to: Deploy high availability solutions for multiple sites. Implement federated sharing. Required materials To teach this module, you need the Microsoft® Office PowerPoint® file 10135A_XB.ppt. Important: We recommend that you use PowerPoint 2002 or a later version to display the slides for this course. If you use PowerPoint Viewer or an earlier version of PowerPoint, all the features of the slides might not be displayed correctly. Preparation tasks To prepare for this module: Read all of the materials for this module. Practice performing the demonstrations and the lab exercises. Work through the Module Review and Takeaways section, and determine how you will use this section to reinforce student learning and promote knowledge transfer to on-the-job performance. Note about the demonstrations : To prepare for the demonstrations, start the 10135A-VAN-DC1 virtual machine and log on to the server before starting the other virtual machines. To save time during the demonstrations, log on to the Exchange servers and open the Exchange Server management tools before starting the demonstrations. Additionally, connect to the Microsoft Outlook® Web App site on the Exchange servers, and then log on as Administrator. It can take more than a minute to open the management tools and Outlook Web App for the first time. Make sure that students are aware that the Course Companion CD has additional information and resources for the module.
  • Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Question: What are some of the common multisite high-availability scenarios? Answer: There are many possible scenarios, including cross-site failovers and switchovers. Cross-site failovers scenarios include: Single database Full datacenter , which includes all mailboxes and services Cross-site switchovers include: Single database Full datacenter (all mailboxes and services) Question: Does your company have a warm disaster-recovery site or is it planning to have one? Answer: Answers will vary depending on the organization. Many companies are investing in disaster recovery to meet regulatory and other requirements. Question: After mail services successfully failover to the second site, what other issues might you still need to address? Answer: Although there is not just one correct answer, possible answers include: How will client machines connect to the secondary site? Will there be staff to maintain the Exchange servers at the secondary site? What process will allow for a successful services failback? Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Discuss how Exchange Server 2010 enables a multisite deployment of the Exchange Server infrastructure with reduced requirements compared to previous versions of Exchange Server. Then discuss the maximum latency requirements and how the administrator needs to manually perform a recovery in case of a datacenter failure. Question: Why should you not implement an automatic datacenter failover even if it is possible? Answer: A full datacenter failover typically disrupts end users and information technology (IT) staff. If a temporary outage occurs at the primary datacenter, it is less disruptive for end users to just wait for the outage to be fixed, rather than enduring a full failover. Also, if you allow the databases to mount automatically in the secondary datacenter when there are network connectivity problems, both sets of servers may operate as if they are primary. This causes a split-brain situation. Exchange Server 2010 leverages Windows® failover clustering to obtain a quorum along with the Active Manager to ensure these situations do not occur. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Discuss some of the issues that might be present for nonmailbox servers. Issues may include: Changing Domain Name System (DNS) entries for Microsoft Outlook if you choose to Live, Outlook Anywhere, and Autodiscover, to reflect the secondary site’s IP addresses. You also can perform these changes with global server load balancing. Requiring clients to log off and then log on because they would be switching their remote procedure call (RPC) client access array connection. Changing the weight of Mail Exchanger (MX) records for inbound e-mail, or reconfiguring hosted anti-spam, antivirus ,and archiving services. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • You must enable datacenter activation coordination (DAC) mode for database availability group (DAG) to allow for an administrator-activated site failover. The failover process includes: Primary data center fails. DNS records are adjusted for Simple Mail Transfer Protocol (SMTP), Outlook Live, Autodiscover, Outlook Anywhere, and any legacy protocols (if necessary). You configure DAG to remove the primary site servers from the Windows Failover Cluster, but not to remove them from the DAG. You configure DAG to use an alternative file-share witness and to restore the secondary site’s functionality. Remaining Active Managers coordinate mounting databases in secondary site. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Discuss the following best practices that users should follow for multisite failover. Ask the students about the practices that they find useful or they expect to find useful. Use Time to Live (TTL) on DNS records for the Client Access server array, Client Access server URLs, SMTP records, to reduce failover time. Having a low TTL enables the DNS clients to discover the DNS entries more quickly that point to the secondary site.   Monitor all aspects of the Exchange Server environment to ensure that it is functioning normally and that mailbox data is successfully being replicated in a timely manner to the secondary site.  Also, talk about scheduling periodic failover tests to provide an additional level of preparation and to provide validation to the configuration and operation of the cross-site failover process.   As other modules point out, change management is important, and you should use it to ensure that each Mailbox server in the DAG, each Client Access server, and each Hub Transport server are configured identically and have the same updates applied. Doing this reduces the possibility of incompatibilities and or that unexpected behavior occurs after a failover. To reduce network congestion and potential communications problems, cluster heartbeat communications should not be allowed between these networks. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Ask students if they are familiar with Active Directory® Federated Services (AD FS). If they are, mention that Federated Sharing is similar to AD FS in that it uses the same technologies to establish a federation trust that can be used to establish secure connections between organizations. Federated Sharing is also different than AD FS, in that, with AD FS, two organizations establish a federated trust directly with each other, while with Federated Sharing, the organizations establish a federated trust with the Microsoft Federation Gateway, which then acts as a trust broker between the organizations. Emphasize that organizations do not need to manage any user accounts on the Federation Gateway. All organizations need to do is establish the federated trust with the Federation Gateway. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Mention that the steps for configuring each of these components will be covered later in this module. Stress that you configure organization identifiers on the Microsoft Federation Gateway, and that each organization must configure their organization identifier. The organization identifier can contain more than one domain name, so that if an organization uses more than one SMTP domain, it can configure a single organization identifier with multiple domain names. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Use the slide to describe the information flow when an organization’s user invites another organization’s user to a meeting. Stress that only the Client Access server from Contoso.com needs to send a request to the Microsoft Federation Gateway. The Client Access server obtains a token from the Federation Gateway, and uses that token to authenticate the connection to the Adatum.com Client Access server. Both organizations must have a federation trust with the Federation Gateway, so the Adatum.com Client Access server will trust the security token. Emphasize that using HTTPS protects all communication across the Internet. Also, only the ews virtual directory on each organization’s Client Access server needs to be Internet accessible to enable the required traffic. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • Stress that the network communication in the federated message delivery scenario is similar to the availability information scenario. In both cases, only the Client Access server in the originating organization needs to obtain the security token used to authenticate and secure network traffic to the destination organization. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • As you discuss this topic, consider opening the Exchange Management Console and showing the New Federation Trust wizard. You cannot actually create the federation trust, but you can show the wizard’s options. Emphasize the importance of meeting the prerequisites. The correct certificate must be installed on the server where you create the federation trust, and the DNS records must be configured before the trust is validated. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • As you discuss this topic, consider opening the Exchange Management Console and showing the wizards for creating new organizational relationships and sharing policies. You cannot actually create the objects without federation trust in place, but you can show the wizards’ options. Appendix B: Advanced Topics in Exchange Server 2010 Course 10135A
  • 10135 a xb

    1. 1. Appendix B Advanced Topics in Exchange Server 2010
    2. 2. Module Overview <ul><li>Deploying Highly Available Solutions for Multiple Sites </li></ul><ul><li>Implementing Federated Sharing </li></ul>
    3. 3. Lesson 1: Deploying Highly Available Solutions for Multiple Sites <ul><li>Discussion: High Availability for Multiple Sites </li></ul><ul><li>Using Cross-Site DAGs </li></ul><ul><li>Challenges of Implementing Cross-Site, Nonmailbox Servers </li></ul><ul><li>Failover Process for Data Centers </li></ul><ul><li>Best Practices for Multisite Failover </li></ul>
    4. 4. Discussion: High Availability for Multiple Sites <ul><li>What are some of the common multisite high-availability scenarios? </li></ul><ul><li>Does your company have a warm disaster-recovery site or is it planning to have one? </li></ul><ul><li>After mail services successfully fail over to the second site, what other issues might you still need to address? </li></ul>
    5. 5. Using Cross-Site DAGs Cross-site DAGs do not require : <ul><li>Special network hardware </li></ul><ul><li>A single shared subnet </li></ul><ul><li>A single Active Directory site </li></ul>Cross-site DAGs do require : <ul><li>Less than 250 ms latency between all DAG nodes </li></ul><ul><li>Reestablishment of cluster quorum after site failure </li></ul><ul><li>Administrative intervention to complete datacenter failover </li></ul><ul><li>Support for nonmailbox roles in each site </li></ul><ul><li>At least one domain controller in each site </li></ul>
    6. 6. Challenges of Implementing Cross-Site, Nonmailbox Servers Challenges of implementing cross-site, nonmailbox servers are : <ul><li>External DNS records name must point to secondary site </li></ul><ul><li>Clients must reconnect to the new RPC client access array </li></ul><ul><li>Inbound e-mail must be redirected </li></ul>
    7. 7. Failover Process for Data Centers Site A Site B DAG Hub Transport (FSW) Hub Transport Client Access Client Access (Alt FSW)
    8. 8. Best Practices for Multisite Failover <ul><li>Verify failover functionality with periodic testing </li></ul><ul><li>Reduce failover time by using low TTL on DNS records for the Client Access server array, Client Access server URLs, and SMTP records </li></ul><ul><li>Closely monitor replication health and other system components to ensure failover health </li></ul><ul><li>Follow proper change-management procedures </li></ul><ul><li>Prevent cluster network cross-talk </li></ul>
    9. 9. Lesson 2: Implementing Federated Sharing <ul><li>What Is Federated Sharing? </li></ul><ul><li>Components of Federated Sharing </li></ul><ul><li>How Federated Sharing Works for Availability Information Access </li></ul><ul><li>How Federated Message Delivery Works </li></ul><ul><li>Configuring a Federation Trust </li></ul><ul><li>Configuring Organizational Relationships and Sharing Policies </li></ul>
    10. 10. What Is Federated Sharing? Federated sharing: <ul><li>Requires Microsoft Federation Gateway as a trust broker </li></ul><ul><li>Uses standard federation technologies to establish trusted relationships </li></ul><ul><li>Enables secure Internet communications between organizations </li></ul><ul><li>Is supported for all messaging clients </li></ul><ul><li>Requires each organization to establish and manage its trust </li></ul>
    11. 11. Components of Federated Sharing Federated Sharing requires: <ul><li>Organization identifier that identifies which domains are available for federation </li></ul><ul><li>Federation Trust with Microsoft Federation Gateway </li></ul><ul><li>Establishment of a federated sharing relationship with another federated organization to enable sharing of availability information, or Federated Delivery of e-mail </li></ul><ul><li>Sharing relationships that define the organizations with which your users will share data, and the type of data they can share </li></ul>
    12. 12. How Federated Sharing Works for Availability Information Access Adatum.com Contoso.com 2 3 4 7 8 6 1 5 Client Access Server Microsoft Federation Gateway Client Access Server Domain Controller Domain Controller Mailbox Server
    13. 13. How Federated Message Delivery Works Adatum.com Contoso.com 2 3 4 6 5 1 Microsoft Federation Gateway Domain Controller Domain Controller Mailbox Server Hub Transport Server Hub Transport Server Mailbox Server
    14. 14. Configuring a Federation Trust Before configuring a federation trust: When configuring the federation trust: <ul><li>Obtain a trusted certificate </li></ul><ul><li>Configure the authoritative domains </li></ul><ul><li>Configure external DNS records </li></ul><ul><li>Ensure the server has Internet access </li></ul><ul><li>Ensure that the server has the certificate installed </li></ul><ul><li>Provide the certificate thumbprint </li></ul>
    15. 15. Configuring Organizational Relationships and Sharing Policies Organizational relationships determine the organizations you want to share information with, and what types of information you will share Sharing policies define which users can share information with other organizations, and what types of information those users can share

    ×