The number of conferencing sites that your organization needs and where to install them depends on your organization’s network topology and the demand for online conferencing.
Analyze the following aspects of your organization to decide how many conferencing sites you need and where to install them.
Anticipated schedule load Consider how your organization will use Microsoft® Exchange 2000 Conferencing Server, based on existing network patterns. There may be obvious physical considerations in your organization, such as multiple data centers. For example, if you have e-mail servers at each of several data centers, consider installing Conference Management Service on these sites.
Logical separation of conferences Consider how your organization will use online conferences, and then create sites for different types of conferences. For example, you could create a conferencing site for conferences that are published to the Internet.
Multisite conference topologies Because only one instance of Conference Management Service is active on a Microsoft Windows® 2000 site, consider balancing your user load across multiple sites by assigning users to sites according to their geographic location. Data Conferencing Provider uses the conferencing site architecture to assign a conference participant to the T.120 multipoint control unit (MCU) that is closest to the participant’s computer.
Initially, you can install one conferencing site, use the audit log files generated by Conference Management Service to monitor conference participation, and then decide if you need additional conferencing sites. If the audit log files indicate that you have too many conferences at one location, then install an additional conferencing site closer to that location to balance the load across your network. Additional conferencing sites allow Data Conferencing Provider to better create distributed conference topologies.
For an initial or pilot deployment, you can install all conferencing services on a single computer. If you create a virtual network address for the conference access pages, you can then expand this pilot deployment to meet the needs of your organization.
The first Conference Management Service installed on a Windows 2000 site becomes the active host server for the conferencing site. You can install additional instances of Conference Management Service on other servers, but only one is active on a site at a time, as shown in Figure 4.1.
Figure 4.1 Single Conferencing Site
Figure 4.1 shows a conferencing site with the required components installed on the site: Exchange 2000 Server, Windows 2000 Server with Active Directory™, Multicast Address Dynamic Client Allocation Protocol (MADCAP), and Certificate Services. You can install one or more conference technology providers on a conferencing site. Some providers, such as Data Conferencing Provider, include additional services, such as the T.120 MCU. These services can run on other servers, but at least the base implementation of the conference technology provider code must run on the same server as Conference Management Service.
Because on each conferencing site all conference reservations and client requests are processed by a single instance of Conference Management Service, you must plan the server load to match the capacity of the server running Conference Management Service.
Before a conferencing site can host online conferences, you must:
If your organization has groups of people in more than one geographic location and more than one Windows 2000 site, you can create additional conferencing sites. Because each conferencing site has its own conference calendar mailbox, you must create conference resources and configure network addresses for the conference access pages for these additional sites. Creating additional conferencing sites helps balance network load and improve performance.
The distributed nature of the components on a conferencing site offers great flexibility in the deployment of Exchange Conferencing Server. By associating conference resources with a specific instance of Conference Management Service, you can manage the associated conference technology provider resources and public conference lists separately. For example, if you create a separate conferencing site with connectivity to the Internet, users can access the conference schedule from the Internet. Users who might participate in conferences through the Internet can see the list of public conferences, but they do not see conferences internal to your organization.
Exchange Conferencing Server must be installed on a Windows 2000 site. However, if you plan to create more than one conferencing site or install Data Conferencing Provider with connectivity to the Internet, you must:
If there are no other Windows 2000 sites, then all users and all conferencing servers belong to the local site. When there are no other Windows 2000 sites, Exchange Conferencing Server cannot optimize the conferencing site by identifying the closest MCU on the network, unless an MCU is configured to accept connections from specific subnets. If your organization requires only a single site, and for security reasons you don’t want to expose your primary server running Exchange to the Internet, define a second site to process user connections originating from the Internet.
If you expect users of Exchange Server version 5.5 to schedule online conferences, you need a two-way Active Directory Connector connection agreement to replicate conference resources for Active Directory to the Exchange Server 5.5 directory. For more information on creating an Active Directory Connector connection agreement, see the Exchange 2000 online documentation.
Along with Conference Management Service, a conferencing site has one or more conference technology providers. When you install Conference Management Service, Exchange Conferencing Server installs both Data Conferencing Provider and Video Conferencing Provider. On a specific conferencing site, you can select which conference technology provider to create resources for and which providers are active. You can install third-party providers after you install Conference Management Service, but only on the conferencing site on which you are using those types of resources.
Each conferencing site has a set of conference access pages. Participants use conference access pages to participate in conferences scheduled on each site. The actual conferences may span multiple conferencing sites.
Conference access pages are installed on a server running Microsoft Internet Information Services (IIS) server. The conference invitation includes the conference URL that participants use to access the conference. The conference URL is composed of two parts: the base address and the conference identifier. The conference identifier is appended to the base address.
| URL element | Example |
| Base address | http://<server_name>/conferencing |
| Conference identifier | /default.asp?<conference_parameters> |
| Conference URL | http://<server>/conferencing/default.asp?<conference_parameters> |
Where <server_name> is the name of the server running IIS that hosts the conference access pages and <conference_parameters> is a group of parameters that define the conference.
The base address is listed in Conferencing Site Properties. Click the Conference Settings tab; the base address is listed under Access URL for user connections. This URL is the base address of the server running IIS that hosts the conference access pages; by default, it is based on the NetBIOS name of the server running IIS.
The conference identifier includes several parameters that define the conference, such as a unique conference ID, and in some cases conference start time, and the password.
A single server running IIS is sufficient, in most cases, for hosting all the users on a conferencing site. However, if you want to provide fault tolerance or you have a large organization, you might need to place the conference access pages on more than one server. You should identify each server with the same virtual network name as the one configured in Conference Management Service.
If you expect the server running IIS to accept connections from Internet participants that are not members of your domain, you must configure the virtual root for private conferences so that Internet participants can participate in private conferences by using basic authentication.
To configure the private conference virtual root:
This allows Internet users to participate in private conferences by using basic authentication.
Warning Remember that basic authentication sends users’ credentials, including passwords, in plain text format.
Use a logical server name for the computer hosting the conference access pages, even if the conference access pages are hosted on the server running Conference Management Service. This computer name is embedded in all scheduled conferences. If you accept the default Windows Internet Naming Service (WINS) network address, then you must always use this address. The network address of these pages is included in the conference access URL that is sent to conference invitees. It is important that this network address not change; otherwise, all conference definitions become invalid. To prevent this, define a virtual network name by using the Domain Name System (DNS) for the server hosting the conference access pages. Then, to use this virtual network name, you must modify the address defined by Conference Management Service.
If you plan to host the conference access pages on a server running Conference Management Service, you do not need to change the default conference access URL. If you change the conference access URL so that it refers to a different server, you must first install Conference Management Service on that server, then redirect client requests for previously scheduled conferences to the URL on the new host server running IIS or change the DNS server settings to point to the new server running IIS.
A single conferencing site with conference access pages installed on the default host server is adequate for most companies. However, very large companies that place a heavy demand on Exchange Conferencing Server can designate a single computer or group of computers to process conference access requests.
Depending on network bandwidth, server performance, and number of online conferences, a single server running Conference Management Service can maintain from thousands to hundreds of thousands of users on a site. However, if the network is segmented and geographically dispersed and if the links between remote locations use a low bandwidth, define a separate Windows 2000 site on each network segment and install Exchange Conferencing Server on each site. This configuration can expand to support all conferencing needs.
The conference calendar mailbox contains the definitions of all conference schedules on a conferencing site. This is critical information and it must be available to Conference Management Service at all times. To prevent data loss, place the conference calendar mailbox in its own Exchange storage group. This minimizes downtime because you need to restore only one storage group in the event of disk failure.
If you apply storage limitation policies to the Exchange mailboxes, verify that the conference calendar mailbox has enough space to hold the required number of online conference definitions.
Because all scheduled conferences on a conferencing site are stored in the conference calendar mailbox, you must regularly purge or archive historic conference definitions. You can create a Microsoft Outlook® profile for the conference calendar mailbox and archive older schedule information to keep disk space available.
Each instance of Conference Management Service manages a set of conference resources. Conference resources represent the physical resources that the conference technology provider provides during an online conference. These physical resources vary depending on the type of online conference. Conference technology providers refer to conference resources by the type of physical resource that an online conference consumes. For example, for data conferences, a user connection to an MCU is the consumable resource. For video conferences, a stream of audio and video is the consumable resource.
After you create a conference resource, assign the resource to conference technology providers on your conferencing site. Conference technology providers associate properties with the resource, such as number of user connections allowed or video resolution, that define characteristics of the conferences that use the resource.
Create only one conference resource for a specific configuration. For example, you need only one conference resource to represent a data conference for 10 people. Unlike the address book entry that is created for a physical meeting room, conference organizers can reserve a conference resource many times before it becomes busy. Resources are properties of an instance of Conference Management Service on a specific conferencing site. Only the conference technology providers installed on the conferencing site can be assigned to a conference resource.
Because public conferences on your conferencing site are listed on conference access pages, you should control who can create conferences that will be accessed by people outside your company. For those external resources (for example, users who access the conference over the Internet), the name should be distinguished in some way to inform the conference organizer. For more information see “Naming Conventions,” later in this chapter.
To schedule resources, Exchange Conferencing Server uses a resource model and rules of availability that include free/busy information and resource costs. Each conference resource publishes free/busy information to the Schedule+ Free Busy Information public folder. Each conference technology provider uses the free/busy information and the resource cost to determine if it can reserve a specific resource. After a conference technology provider reserves a resource, it calculates resource availability for the remaining resources. If a conference organizer requests conference resources for another conference and the conference technology provider cannot accept the cost of this additional conference, the resource is at capacity and shows as busy.
For example, you have two conference technology providers. Provider A has 50 resource units available and provider B has 100 units. You have the following resources (the resource costs are in parentheses):
Initially all resources publish a free status. Someone schedules a conference using resource A+B (20). The cost of the resource is reduced from each provider’s total. Provider A now has 30 units available (50-20=30) and provider B has 80 (100-20=80). Since provider A has 30 units available, there are not enough resources for someone to schedule a conference using the A (40) resource. Provider A communicates that the A (40) resource is busy, but the A (10) resource is available.
You must define a naming convention that describes the features of each conference resource. Before creating your naming convention, consider the following:
You can name resources based on their location or on the technology that they provide. It is helpful to include the number of participants that the resource can host in the name of the conference resource, so that when organizers are looking for a resource in the Address Book, they can easily find a resource with the capacity to host their conference.
Location You can configure a conference resource to allow participants in a restricted geographic region to participate in a conference. You can name a resource using the geographic name, conferencing feature, and number of participants. For example:
Technology You can name a conference resource based on the technology or conferencing feature that it provides. This is a useful naming convention for conference organizers. For example:
In each case, the size indicates the maximum number of participants.
To make sure that Exchange Conferencing Server remains stable and available, you must create a reliability plan. Use this plan to define the level of redundancy and what action to take if a component fails. You must understand the possible points of failure in Exchange Conferencing Server and your options for fail-over strategy.
The following table summarizes the key components in Exchange Conferencing Server, failure types you could encounter, and what you can do to prevent or recover from a failure.
| Component | Failure | Recovery or Fail-Over Options |
| Conference calendar mailbox | Disk | Place data on a redundant array of independent
disks (RAID).
Place mailbox in a separate storage group and back up frequently. |
| Conference calendar mailbox | Exchange | Put the server running Exchange into an active/active cluster. |
| Conference Management Service | Server or service | Install an additional instance of Conference Management Service on a backup server, so that you can switch to the backup server if necessary. |
| Conference access pages | Server or service | Install conference access pages on a backup server and change the DNS address of the conference location to that of the backup server. |
| T.120 MCU | Server or service or network | Ensure that each conferencing site has multiple
servers that can accept client connections for the same user
locations.
Exchange Conferencing Server provides automatic fail-over for MCUs. |
| MADCAP service | Server or service or network | Install MADCAP on more than one server and specify scopes on the conference resources for all sites with MADCAP. |
Exchange Conferencing Server places configuration data in Exchange and Active Directory.
Exchange Exchange Conferencing Server places mailboxes for the conference calendar and conference resources in the Exchange mailbox store.
Active Directory in Windows 2000 Active Directory contains objects for the conference resources and conference calendar mailboxes.
To recover from catastrophic failure, you must follow the backup and restore strategies for each of these components. For information on backup and restore strategies for these components, see the Exchange 2000 Server and Windows 2000 Server online documentation.