Script

[This is pre-release documentation and subject to change in future releases. This topic's current status is: Milestone-Ready]

Topic Last Modified: 2010-07-18

This topology is for any size of organization with more than one central site. The exact topology in this diagram is for an organization of 70,000 users, with 40,000 users at Central Site A and 30,000 at Central Site B. The type of topology shown in this diagram can accommodate organizations of any number of users.

This topology is shown in multiple diagrams, with an overview first followed by close-ups of the central sites.

• Active Directory Deployment—All Communications Server deployments reside in a single Active Directory forest. For this topology, the customer has Communications Server deployed in two child domains, retail.contoso.com and manufacturing.contoso.com.
  
  
• To Accommodate More Users, Add More Front End Servers—The organization in this diagram has five Front End Servers at Central Site A (for 40,000 users), and four Front End Servers at Central Site B (for 30,000 users). If either site needs to accommodate more users, you can simply add Front End Servers to the pool at that site. One Front End pool can have as many as 10 servers, so a single Front End pool at a single site can support up to 80,000 users.
  
  However, each site can support even more users by adding another Front End pool to the site. To support these extra users only another Front End pool needs to be added; just single pools at each site of A/V Conferencing Servers, Edge Servers, and Directors are still sufficient, although more servers may need to be added to these pools.
  
  
• Using Standard Edition Server at a “Branch Office”—Aside from its use in Communications Server, this organization considers Site C as a branch office, as it has only 600 employees. However, the users there have many A/V conferences among themselves. If it was deployed in Communications Server as a branch office, the media for these conferences would run across the WAN to and from a central site with A/V Conferencing Server installed. To avoid this potential performance problem, they have installed a Standard Edition Server at this site, which will host these conferences. And because a Standard Edition Server is installed there, Communications Server by definition considers it a central site, and it is treated as so in Topology Builder and the Planning Tool.
  
  As long as the users at this site have a pool in another site set as their backup registrar, they will have high availability for Enterprise Voice—voice support will fail over to the backup registrar site automatically. For a more complete high availability solution at this site, a second Standard Edition Server could be deployed there.
  
  Although Site C is considered a central site, you do not have to deploy Edge Servers there. In this example, Site C will use the Edge Servers deployed at Site A.
  
  
• Monitoring Server and Archiving Server Collocation—This organization deploys both Monitoring Server and Archiving Server. For organizations that deploy both, we recommend that you collocate them in a single pool to save server investment. One Monitoring Server can support up to 100,000 users, and one Archiving Server can support up to 300,000 users.
  
  Note that you need a Monitoring Server and Archiving Server pool in only one central site. If the link between the two central sites goes down, the Message Queueing (also known as MSMQ) technology used by both Monitoring Server and Archiving Server helps preserve data while the link is down.
  
  In this topology, the Monitoring Server and Archiving Server pool has its own database server pool. Topologies in which the Monitoring Server and Archiving Server pool shares the same database servers as the Front End pool is also supported, although on large deployments such as this separate database servers are recommended for performance.
  
  For the database servers for the Monitoring Server and Archiving Server pool, we recommend two servers for redundancy and failover.
  
  
• Branch Office Deployment Options—The organization in this topology has Enterprise Voice deployed as their voice solution. Branch Sites 1 and 3 do not have a resilient WAN link to the central site, so they have Survivable Branch Appliances deployed to provide telephone service in case the WAN link to the central site goes down. Branch Site 2 however has a resilient WAN link, so only a PSTN gateway is needed. The PSTN gateway deployed there supports media bypass, so no Mediation Server is needed at Branch Site B. For details about deciding what to install at a branch site, see Branch-Site Voice Resiliency.
  
  
• SIP Trunking and Mediation Server—Notice that at Site A, Mediation Server is not collocated with the Front End Servers. This is because sites that use SIP trunking must deploy Mediation Server in a separate pool from the Front End Servers. In all other instances, we recommend you collocate Mediation Server with Front End Server.
  
  
• DNS Load Balancing—The Front End pool, Edge Server pool, and the Director pool have DNS load balancing for SIP traffic deployed. This eliminates the need for hardware load balancers for the internal interface of the Edge Servers, and significantly lessens the setup and maintenance of the hardware load balancers for the other pools, as the hardware load balancers are needed only for HTTP traffic. For details about DNS load balancing, see DNS Load Balancing.
  
  
• Exchange UM Deployment—Each of the reference topologies includes an Exchange UM Server, which runs Exchange, not Communications Server. The Exchange UM functionality for Communications Server runs on the Front End pool. For details about Exchange UM, see Exchange Unified Messaging Integration.