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.
|All capacity and performance numbers in this section pertain only to the Microsoft Communications Server 2010 (Beta Refresh) release, and are subject to change in future releases.|
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
- 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
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
- 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
- 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