How you deploy Data Conferencing Provider depends on the topology and other characteristics of your network. Also, you must decide how to prioritize the different properties of Exchange Conferencing Server. For example, do you want to confine conference network traffic to a specific area of your network? Do you consider the cost of conference traffic across the network infrastructure higher than the cost of managing additional decentralized servers?
The optimal number and placement of multipoint control units (MCUs) depends on your network topology and on how you plan to use MCUs. You should consider the number of conference participants and their location on the network, the cost of placing additional conference traffic on the network, the level of redundancy for fault tolerance, and service performance requirements.
The following criteria affect the deployment architecture for data conferencing:
Exchange 2000 Conferencing Server uses the Windows site as the highest hierarchical level of the conferencing site. When you use Exchange Conferencing Manager, you manage a conferencing site. The Windows site defines the location of servers and conference participants on the network and the connectivity among them. Data Conferencing Provider uses this information to decide which MCU to assign to conference participants.
You construct the Windows site architecture by using Windows Sites and Services. If your Windows organization uses any form of directory replication, this architecture is defined. Typically, a site defines the subnet addresses of the computers on your networks that are interconnected by high-bandwidth and persistent connections. If you have not defined Windows 2000 sites, then you must verify that all conferencing servers are connected by high-bandwidth and persistent connections.
The first server that has Conference Management Service installed on the site is considered the top-level server for Exchange Conferencing Server. The Windows site on which this server is installed is the root node for data conferencing servers. The Data Conferencing Provider code always resides on the same server as Conference Management Service.
Exchange Conferencing Server defines the servers that host the MCUs according to the conferencing site and the Windows site on which Exchange Conferencing Server resides. When you install an MCU on a server, the MCU tries to assign itself to a conferencing site on the Windows site.
You can have multiple conferencing sites in your organization. Data Conferencing Provider uses this architecture to decide on the preferred network locality of a user who asks to join a conference. When a conference participant asks to join an online conference scheduled at one location, Data Conferencing Provider searches for a conferencing site on the participant’s Windows site. If there is an MCU on the conference participant’s Windows site, the participant is referred to that MCU.
The cost of network bandwidth between Windows sites and subnets on a conferencing site affects where you install MCUs. When you have conferences that span Windows sites and subnets, Data Conferencing Provider helps to reduce the cost of your network connection by directing the unicast client connections to a single MCU. Then Data Conferencing Provider creates a unicast connection between the MCU and an MCU on the other Windows site or subnet. By creating a single source of conference data, Exchange Conferencing Server provides a network model that is more scalable and that uses network bandwidth more efficiently.
When it connects a conference participant to the closest MCU, the data conferencing provider considers the following:
When a participant from one conferencing site attempts to join a conference on another conferencing site, the hosting conferencing site directs the user to his or her local site and initiates a connection between the two sites. This creates a single instance of the conference data between the two sites. This is very useful if you have clients trying to participate in a conference across a slow network link, as shown in Figure 4.2.
Figure 4.2 Multipoint Control Unit Affinity
In Figure 4.2, the clients on site 3 are invited to a conference on site 1. There is a slow connection between site 3 and site 1 but fast connections between site 3 and site 2, and between site 2 and site 1. To improve the performance of the conference, use MCU affinity to connect the clients on site 3 to the MCU on site 2 and then to the conference on site 1.
If a participant attempts to join a conference from a Windows 2000 site that does not have a conferencing site, and if the Windows site has been given affinity to an MCU on another site, the participant is considered to be local to that site. Otherwise, the participant is remote to the hosting site and connects to an MCU that is configured to accept remote connections.
Through administrative settings, you can restrict access to an MCU based on a set of subnet mask pairs. Only users whose IP addresses match a defined subnet can connect to the MCU. In this way, administrators can divide a Windows 2000 site and direct participants to a specific MCU.
Each MCU can be configured with a different network name, which is used by participants to connect to the MCU from each of the three regions separated by these firewalls.
All users on the local conferencing site use the local network name, whereas users remote to the conferencing site use the remote network name. Users from the Internet use the Internet network name. Establishing separate network names provides two methods for bridging the security regions. The simplest is to connect each network interface card to each network region. Then, configure each network name to be the IP address, or associated DNS name, of each of these network interface cards. Clients that attempt to join conferences from each region are given the network address of the network interface card for which they have access.
Alternatively, some firewall products can be configured to implement a reverse packet filter for the T.120 connections on port 1503 and to target connection requests to the MCU. In this case, the MCU is connected to the intranet and the external clients refer to the MCU with the network name of the firewall.
To participate in secure conferences, participants must use Microsoft NetMeeting® 3.01 or later and Microsoft Internet Explorer 4.01 or later. To support secure conferences, you must install Certificate Services on at least one server running Windows 2000 in the domain. Certificate Services provides a certificate authority that grants certificates to users that authenticate them for secure conferences.
To improve the reliability of data conferencing in your organization, install multiple MCUs to accept connections from the same groups of users. There is no need to place MCUs in a cluster, however, because Data Conferencing Provider provides automatic fail-over for the MCUs on the site.
Because MCUs exchange distributed Component Object Model (COM) calls with Data Conferencing Provider, make sure that the MCUs on your Windows 2000 site have fast connections to the server with the active Conference Management Service.
You can examine the Exchange Conferencing Server audit and application logs and System Monitor counters to assess the reliability of your Data Conferencing Provider infrastructure. In particular, the MCU application logs provide statistics on the number of software, hardware, and network failures, and on MCU downtimes. The System Monitor counters indicate the connection speeds and the volume of distributed COM traffic.
The audit log files and System Monitor counters provide valuable information on the MCU load dynamics, average connection delays, and other performance characteristics of Data Conferencing Provider. You can use this information to plan the number and type of MCU servers to include in your organization.
Data Conferencing Provider allows you to increase the number of MCUs on the site. If you deploy many MCUs that accept connections from the same groups of users who are using relatively low-performance servers, Data Conferencing Provider automatically balances the load by choosing the MCU with the lightest load to host the conference. Then it connects all of the local participants of that conference to the same MCU to minimize conference traffic. This continues until a configurable maximum load level for the MCU is reached. The next connection request is directed to the MCU with the lightest load.
Because of the configurable maximum, deploying an MCU on a computer with a faster processing speed produces conferences that span fewer MCUs, therefore causing shorter delays for conference traffic. However, when you deploy a larger number of MCUs on computers with slower processing speeds, you get better reliability and fault tolerance.
When a participant accesses a conference, Data Conferencing Provider directs him or her to a specific MCU, depending on the network address of the participant’s computer. Data Conferencing Provider gets the client’s network address from the Web browser. Because of this, client computers on a conferencing site should be configured to bypass any proxy server when accessing the conference access page server. Users from remote conferencing sites can use an inter-site proxy server if the following conditions are true:
Using the participant’s IP address, Data Conferencing Provider looks for conferencing sites in the organization. If it finds a conferencing site that has preferred ownership of the participant’s location, then it connects the participant to the local conferencing site and supplies the conference name and network name of the local MCU on which the conferencing sites can be linked. On the remote conferencing site, Data Conferencing Provider selects the best MCU for the conference.
If the user is accessing the data conference from a Windows client running Internet Explorer and NetMeeting, he or she automatically connects to the MCU hosting the conference. If the user does not have these applications, the MCU sends a T.120 message to the client’s IP address with an invitation to the conference. If this invitation fails, the details for the conference appear on the Web page, allowing the user to call the T.120 conference manually.
You can configure each MCU to restrict user access to its conferences in several ways. By default, an MCU does not allow connections from the Internet, but it does allow local and remote connections. An MCU can distinguish between user connections from a local site, a remote site, and the Internet. You can configure an MCU to restrict or allow access from any of these locations. Also, a set of network addresses can be configured for any combination of these locations. The MCU can deny connections from clients that don’t belong to the defined set of network addresses. Data Conferencing Provider directs these clients to the next best MCU in the organization.
You can also specify an MCU for clients to connect to if the clients are on a Windows 2000 site that is not a conferencing site. For procedures, see “MCU Connections and Types,” later in this chapter.
With so many options for managing access to MCUs, it is important to evaluate your organization’s requirements, network infrastructure, and conferencing patterns to decide which options are best. For example, consider the following:
This section contains examples of backboned, hub-and-spoke, and multiple site deployments of MCUs. Refer to these to help you decide how to use MCUs in your organization. In each of these examples, MCUs are shown on a site with Conference Management Service. However, you can install an MCU on a Windows 2000 site that is not running Conference Management Service.
Backbone Topology
Consider a backbone deployment in which all clients have a low-cost, high-bandwidth connection to a centralized network. Usually, this kind of deployment has network services, such as e-mail and database services, in a centralized data center. In this case, you would place the components of Exchange Conferencing Server in the centralized location. Install MCUs to provide load balancing and redundancy for all network clients.
Consider a backbone deployment if you plan to use Data Conferencing Provider on only one Windows 2000 site and if you are not concerned about inter-subnet network traffic. The backbone topology places Conference Management Service and all the MCUs on the backbone. This improves resource management, load balancing, and fault tolerance. In addition, administrators have better control over the servers in case a change is made to the network infrastructure. However, there is more network traffic between subnets.
Note In the following figures, IIS is shown on the same server as Conference Management Service. This is not a requirement. The only requirement is that IIS be installed on the same site as Conference Management Service.
Figure 4.3 Backbone Topology
Hub-and-Spoke Topology
If you are concerned about traffic between subnets, consider a hub-and-spoke topology. Place Conference Management Service in the hub, and then place one or more MCUs on the subnets with conferencing users. This layout routes conference traffic over a single link. This topology improves network load but compromises load balancing and fault tolerance. A hub-and-spoke topology can be more efficient than a backbone topology if most conference participants are on the same subnet and most network traffic happens on the subnet.
Figure 4.4 Hub-and-Spoke Topology
Decentralized Topology
If you have multiple sites that could have conferences occurring at the same time, consider a decentralized deployment. On each site, there is a server running Conference Management Service and one or more MCUs. If there are firewalls between the sites, a proxy MCU must be defined on each site.
Figure 4.5 Decentralized Topology
If you want to further limit inter-site bandwidth usage, dedicate an MCU on each site for remote connections. This ensures that a single instance of data travels across the WAN link.
If users participate in data conferences on remote sites, they are connected to local MCUs, but the impact that their connection has on MCU capacity is not reflected in resource availability on the local site. Even though they are participating in a remote conference, because their connection is through a local MCU, they still have an impact on the capacity of the local MCU. Thus, if you expect a large number of inter-site conferences, be conservative when setting the Maximum number of scheduled connections for an MCU. You can configure this option on the General tab on Data Conferencing Provider Properties.
You can customize MCUs in various ways to meet the needs of your organization. You can assign specific MCUs to different tasks on the conferencing site. The following procedures illustrate some common uses for MCUs.
In the following procedures, you must navigate to the MCU you want to configure.
To navigate to an MCU:
Local MCU
A local MCU accepts connections only from participants whose computers are on the same Windows 2000 site.
To configure a local MCU:
Local MCU with subnet scope restrictions
This is an MCU that accepts connections only from participants on specific subnets on the site. You control access by defining subnets.
To configure a local MCU with subnet scope restrictions:
MCU with site affinities
An MCU with site affinities treats connections from specific Windows 2000 sites as though they were on the same site. Use an MCU with site affinities to designate an MCU with a faster connection to a particular site as the preferred MCU for participants on that site.
To configure an MCU with site affinities:
Inter-site connector MCU
An inter-site connector MCU serves as a bridgehead between remote Windows 2000 sites. This MCU accepts connections from remote MCUs and remote participants if Exchange Conferencing Server is not available on their sites.
To configure an inter-site connector MCU:
Internet connector MCU
An Internet connector MCU accepts connections from Internet users.
To configure an Internet connector MCU:
Important If you configure an MCU to be accessible from the Internet, and you have only one Windows 2000 site defined in your organization, you must create a second Windows 2000 site and deploy the Internet-accessible MCU on that site. Otherwise, Internet users are considered local by Data Conferencing Provider.