Deploying And Maintaining Microsoft Exchange 2000 Conferencing Server

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server White Paper

Published: April 2003

Contents Introduction...............................................................................................................4 Before You Begin........................................................................................................4 Data Conferencing Technology Overview....................................................................4 Functionality and Capabilities.................................................................................4 T.120 Concepts and Limitations..............................................................................5 Building Efficient Topologies...................................................................................5 Video Conferencing Technology Overview...................................................................6 Functionality and Capabilities.................................................................................6 Multicast Video....................................................................................................6 H.323 Video........................................................................................................7 Exchange Conferencing Server Components and Terminology.......................................7 Client Components..................................................................................................8 Windows Client....................................................................................................8 Internet Browser..................................................................................................8 E-mail Client........................................................................................................9 T.120 Client.........................................................................................................9 Scheduling a Conference.......................................................................................9 Joining a Conference...........................................................................................10 Related Technologies.............................................................................................10 Active Directory .................................................................................................10 Internet Information Services .............................................................................10 Exchange 2000 Server........................................................................................11 Deployment Concepts............................................................................................13 Conferencing Sites .............................................................................................13 Deploying Data Conferencing.....................................................................................14 Major Deployment Options.....................................................................................14 Single-Server Deployment...................................................................................14 Single-Site Deployment.......................................................................................17 Mixed Exchange 5.5 and Exchange 2000 Environments...........................................20 Remote MCU Deployment....................................................................................21 Deploying Exchange Conferencing Server for Business-to-Business Conferencing........25 Combining Deployment Options into a Multi-Site Deployment...................................37 Deciding on the Deployment Option.........................................................................40 Scalability Considerations....................................................................................41 Tracking the Load and Updating the Topology.........................................................42 Extending Deployment to Support Video Conferencing...................................................43 Infrastructure Requirements for Multicast Conferencing..............................................43 H.323 Fallback...................................................................................................43 Maintaining Your Exchange Conferencing Server Deployment..........................................46 Maintenance Procedures........................................................................................46 Cleaning Your Conferencing Calendar....................................................................46

2

Shutting Down and Restarting T.120 MCU Servers..................................................46 Tuning Up Exchange Conferencing Server Performance..............................................46 T.120 MCU Performance......................................................................................46 Conference List Performance................................................................................47 Audit Log Files and Performance Monitor Counters ....................................................48 Audit Log Files...................................................................................................48 Performance Monitor Counters.............................................................................50 Conference Management Service Counters............................................................50 Data Conferencing Service Counters.....................................................................50 T.120 MCU Server Counters.................................................................................51 Video Conferencing Service Counters....................................................................52 H.323 Conferencing Bridge Service Counters.........................................................53 Additional Resources ................................................................................................54 Appendix.................................................................................................................55 Sample Perimeter Network Configuration.....................................................................55 Example Perimeter Network Scenario.......................................................................55 Router, Firewall, and Proxy Configuration...............................................................56

3

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server White Paper Published: April 2003 For the latest information, please see http://www.microsoft.com/exchange

Introduction Microsoft® Exchange 2000 Conferencing Server extends the productivity and connectivity of knowledge workers through multi-party audio/video and data conferencing services. Additionally, with Exchange Conferencing Server Service Pack 3 (SP3), you can support data conferencing through firewalls, thereby extending your conferencing capabilities. This paper introduces the concepts behind Exchange Conferencing Server and provides guidelines and topologies for deploying data and video conferencing services. After you have completed Exchange Conferencing Server deployment, you can use the maintenance section of this paper to help you schedule regular Exchange Conferencing Server maintenance tasks. The Appendix provides additional deployment procedures and troubleshooting tips that may be applicable to your Exchange Conferencing Server environment. Some of the features in this paper, such as deploying Exchange Conferencing Server in a tunneling mode, are dependent on Exchange Conferencing Server SP3. We recommend installing the latest service pack for Exchange Conferencing Server for additional functionality, better reliability, and scalability. SP3 is the latest available at the time this paper was published. As with any large software project, there are issues and specific configurations that this document does not address. You should refer to your Exchange Conferencing Server documentation and online help for more information about Exchange Conferencing Server deployment and configuration. Use Microsoft Knowledge Base for the latest information about known issues and limitations; in addition, consult Microsoft Product Support for issues not covered in Microsoft publications.

Before You Begin Data Conferencing Technology Overview Functionality and Capabilities A data conference has the following features:

•

Application sharing You can share an application running on one computer with other participants in the conference. Participants can review the same data and see the actions while the person sharing the application works on the program; for example, editing content or scrolling through data. The person sharing the application can choose to collaborate with conference participants, allowing them to take turns editing or controlling the application. Only the person sharing the application must have it installed on his or her computer. Also, with Microsoft NetMeeting® version 3.01 you can share your desktop, allowing another person to remotely control your computer

•

Shared clipboard You can share data with other participants by using cut, copy, and paste operations; for example, you can copy information from a local document and paste the contents into a shared application. The shared clipboard provides an easy way for participants to exchange data between shared and local applications.

•

File transfer You can send a file in the background to one or more conference participants using a file transfer. Because the file transfer occurs in the background, participants can continue sharing an application or using other data conferencing features.

•

Whiteboard You can load or sketch diagrams and organizational charts or display other graphic information in this multipage, multiuser drawing application. Whiteboard is object-oriented (versus pixel-oriented), allowing you to move and manipulate the contents using a click-and-drag operation. In addition, you can use a remote pointer or highlighting tool to point out specific content or sections of shared pages.

•

Chat You can type text messages to share common ideas or topics with conference participants, or you can use text messages to record conference notes and action items. You can also use chat to communicate if audio is not available. The NetMeeting whisper feature allows you to have a separate, private conversation with one of the conference participants during a group chat session.

T.120 Concepts and Limitations During a data conference, the computer of each participant is connected to a T.120 multipoint control unit (MCU). On the conferencing site, you can install the T.120 MCU on multiple servers running Microsoft Windows® 2000 Server or Advanced Server. Exchange Conferencing Server groups these MCUs to provide failover and load balancing across the conferencing site. These groups of MCUs provide the platforms on which each scheduled data conference is hosted. Building Efficient Topologies 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 client connections to an MCU in the client’s site (local MCU). Then Data Conferencing Provider creates a unicast connection between the local MCU and an MCU in the Windows site where the conference has been scheduled (hosting MCU). 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.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

5

When it connects a conference participant to an MCU, the Data Conferencing Provider considers the following: •

Is the participant joining a conference from a remote location that has a conferencing site?

•

Is the participant joining a conference from a location that is considered to be local to a conferencing site?

•

Has the administrator defined visibility restrictions on the MCU to which a participant can connect?

•

Are there already MCUs connected to the conference?

•

What’s the current load of the available MCUs?

When a participant from one conferencing site attempts to join a conference on another conferencing site, the hosting conferencing site directs the user to an MCU in his or her local site and initiates a connection between the two sites. Note You must configure more than one Windows 2000 site and subnet so that the Conference Management Service is able to determine whether conferencing clients are connecting from the internal or Internet network. If you do not configure more than one site, all conferencing clients appear to come from the default (the internal) Windows 2000 site.

Video Conferencing Technology Overview Functionality and Capabilities Exchange Conferencing Server employs two mechanisms to provide audio/video to conferences. IP multicast is the preferred or default method. H.323 is used in cases where IP multicast is not available. Multicast Video IP multicast is an extension of the Internet Protocol (IP) that allows for efficient group communications. In a multicast environment, the participant's computer sends a single copy of each data packet to the network. Each conference obtains a transient class D IP address, clients subscribe to the multicast address via the router using Internet Group Management Protocol (IGMP), and then the router forwards multicast content to each subscribed client. The Exchange IP multicast Technology provider uses the Session Description Protocol (SDP) for IP multicast conferencing. A multicast address and a pair of User Datagram Protocol (UDP) ports define the multimedia traffic for the conference. Each multicast client sends one stream of audio/video to the multicast address and listens to the same address. The advantages of IP multicast include: •

A single video/audio stream requires less network bandwidth than H.323.

•

Every attendee sees video of all other attendees.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

6

The limitations of IP multicast include: •

Network routers between all clients and the host conferencing server must be multicast enabled. Improper router configuration can create IP multicast islands, which make it impossible for clients to connect to some conferences.

•

Clients must be multicast capable.

•

IP multicast conferencing is CPU-intensive on the client because the client performs the audio mixing and receives all of the video streams.

H.323 Video H.323 is an International Telecommunications Union (ITU) standard that specifies how client computers, equipment, and services for multimedia communicate over networks, such as the Internet. Different products that use H.323 for audio and video can connect and communicate over the Internet just as people using different types of telephones can communicate using telephone wires. H.323 is the other common mechanism for providing the audio/video stream to videoconferences. H.323 provides unicast video conferencing. Each H.323 client sends audio/video to a central H.323 bridge. The H.323 bridge mixes audio from all the clients and sends the resulting unicast audio streams to all attendees that are not multi-cast enabled, as well as a single multicast stream to all multicast attendees. The bridge also implements voice-activated video switching for H.323 clients to display the video of the active talker, and sends all H.323 clients’ videos to multicast attendees. The advantages of the H.323 bridge include: •

Although the bridge must have multicast connectivity to the Conference Management Service, there are no special network requirements between clients and the host server.

•

Client CPU usage is low because the H.323 bridge mixes audio and switches video.

•

The client receives only one audio stream and one video stream.

The limitations associated with the H.323 bridge include: •

With multiple audio/video streams, an H.323 call requires more network bandwidth than IP multicast.

•

Participants do not see the video of multiple participants simultaneously.

•

H.323 video is CPU intensive for the H.323 bridge server.

Exchange Conferencing Server Components and Terminology Familiarity with various Exchange 2000 Server and Exchange 2000 Conferencing Server components and terms enhances your understanding of this paper. Table 1 lists and describes these components.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

7

Table 1

Exchange Conferencing Server components and descriptions Component

Description

Conference Management Service

Conference Management Service coordinates and manages conferencing technologies and resources and tracks and controls access to conferences.

Conference Technology Provider

Conference Technology Provider is the back-end service supporting the online meeting. Microsoft provides two Conference Technology Providers within Exchange 2000 Conferencing Server: Data Conferencing Provider and Video Conferencing Provider.

Data Conferencing Provider

Data Conferencing Provider is a conferencing technology based on the T.120 protocol stack that provides collaboration tools such as those found in NetMeeting. Data Conferencing Provider provides a T.120 multipoint control unit for data conferencing clients.

Video Conferencing Provider

Video Conferencing Provider is a conferencing technology that provides video and audio conferences over multicast-enabled IP networks. Video Conferencing Provider also provides an H.323 bridge that allows H.323 clients to participate in audio and video conferences when multicast is not available.

Conference Web Access

Conference Web Access, also known as conference access pages, provides a front-end service for conferencing. This service includes access, authentication, and, starting with Exchange Conferencing Server SP1, scheduling capabilities.

T.120 Multipoint Control Unit (MCU)

The T.120 MCU service runs as a component of DCP and provides multipoint data connectivity between participants in a data conference.

Conference calendar mailbox

A conference calendar mailbox is an Exchange 2000 mailbox that stores the definitions and properties of all conferences.

Conference resources

Conference resources are Exchange 2000 mailboxes that users invite when scheduling an online meeting. The conferencing resource properties define the properties of the conference such as the number of attendees allowed, audio/video, data, capabilities, audio, video compression/decompression algorithms (CODECS), and so on.

H.323 bridge

The H.323 bridge permits NetMeeting clients that are unable to connect directly to multicast conferences to connect through a H.323 unicast session.

Client Components To take advantage of the full set of Exchange Conferencing Server features and capabilities, we recommend you use the latest versions and service packs of Windows, Microsoft Internet Explorer, NetMeeting, and Microsoft Office Outlook® on client computers. Windows Client Clients running Windows 2000 or Microsoft Windows XP can participate in multicast video conferences. These platforms include the latest Telephony Application Programming Interface (TAPI) telephony libraries. Exchange Conferencing Server uses these libraries to support multicast video conferencing. Internet Browser A browser that supports frames and JavaScript works for data conferences. We do not recommend that you use a version of Internet Explorer earlier than version

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

8

5.0. Sending audio/video in conferences requires browser support for Microsoft ActiveX® controls. Conference participants use an Internet browser to participate in conferences through Conference Web Access. Note Users must have permission to download and install ActiveX controls. E-mail Client Conference organizers use an e-mail client to schedule conferences and reserve conference resources. Though you can use Outlook Web Access or early versions of Outlook for scheduling conferences, you will not get the best experience with Outlook versions earlier than Outlook 2000. Starting with Exchange Conferencing Server Service Pack 1 (SP1), it is also possible to schedule conferences through a browser by using the Conference Web Access services. T.120 Client At the time of this writing, NetMeeting 3.01 is the preferred T.120 client. (The latest Windows 2000 and Windows XP service packs are recommended for best performance.) This application allows conference participants to connect to an MCU and send and receive data during a data conference. You can also use other T.120compliant applications. Scheduling a Conference You schedule a conference by creating a meeting request and inviting a conference resource. If the associated conference technology providers accept the conference request, Conference Management Service stores the conference details in the conference calendar mailbox. This persistent representation of the online conference gives Conference Technology Providers a storage location for information associated with the conference. Conference Management Service maintains the accuracy of the conference definition by processing all conference updates and publishing the associated free/busy information of conference resources. To restrict Active Directory searches for resource objects in large Active Directory organizations •

If your organization has many domains and users in Microsoft Active Directory® directory service, and if your Exchange 2000 server that hosts Exchange Conferencing Server resources is in the same domain with the Conference Management Service, it is a good idea to restrict Active Directory searches for resource objects performed by Exchange Conferencing Server to the local domain only. To accomplish that, add the following value to the registry key:

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

9

Location: HKLM\SOFTWARE\Microsoft\Exchange\Conferencing\Parameters Registry Key: ResourcesOnlyInLocalDomain Type: REG_DWORD Data: 1 Caution Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. Joining a Conference In a typical online conference, the user asks to attend by going to the location that the conference URL specifies. Every online conference is identified by a conference access URL. All conference participants use the same URL regardless of the combination of conference technology providers that the conference is using. A user can access the URL of an online conference before, during, or after the scheduled start time.

Related Technologies Active Directory Exchange Conferencing Server stores all configuration information in Active Directory. This facilitates multimaster, remote, and offline administration. Exchange Conferencing Server also uses information in Active Directory to access the network topology. Exchange 2000 Conferencing Server uses the Windows 2000 Active Directory site structure to define the basic conferencing site structure. By default, the conferencing site is the same as the Windows 2000 site in which it was installed. It can also be configured to span multiple sites as appropriate for your network architecture. 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. 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 in the Windows site. Internet Information Services Exchange Conferencing Server uses Internet Information Services (IIS) to provide conference Web access. Conference participants use HTML pages to schedule,

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

10

authenticate, join, and participate in conferences. Conference Web Access must be installed in the same Active Directory site as the Conference Management Service. For Web scheduling features, available with Exchange Conferencing Server SP1, Conference Web Access installation is required on all Exchange 2000 Servers that host Exchange Conferencing Server resource mailboxes. Exchange 2000 Server Exchange Conferencing Server resource and conference calendar mailboxes are hosted by Exchange 2000 servers. The resource and calendar mailboxes are associated with a specific conferencing site. The Exchange 2000 server that hosts conference calendar mailbox must be in the same domain with the Conference Management Service. For Web scheduling features, the Exchange 2000 Server that hosts conferencing resources must be in the same Active Directory site with the Conference Management Service. It is a good practice to dedicate a separate Exchange 2000 storage group, or possibly a server, for conference resource and calendar mailboxes for fast backup and recovery. To restart the Conference Management Service after moving resources to a different Exchange storage group •

You must restart the Conference Management Service after moving resources to a different Exchange Storage storage group. Otherwise, you cannot book a conference or a meeting against a resource that has been moved across Storage Groups.

Multicast Address Dynamic Client Allocation Protocol (MADCAP) allows hosts to request multicast addresses from multicast address allocation servers. MADCAP is an optional component of Windows 2000 Server and is implemented as an extension to Dynamic Host Configuration Protocol (DHCP) services. After you configure and activate a multicast scope, the MADCAP service in Windows 2000 Server can provide multicast IP addresses in the same way that DHCP provides unicast IP addresses. An active MADCAP server is required for Exchange Conferencing Server multicast videoconferences. If no MADCAP servers are found, Exchange Conferencing Server will allocate a multicast address randomly, which may present a security risk if two conferences happen to be assigned the same multicast address. To disable allocation of random multicast addresses •

To disable allocation of random multicast addresses by Exchange Conferencing Server, set the following registry key on Conference Management Service servers:

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

11

Location: HKLM\SOFTWARE\Microsoft\Exchange\Conferencing\Parameters Registry Key: Type: DWORD Value: "No Random Mcast Address" =1 Caution Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

12

Deployment Concepts Conferencing Sites At least one Conference Management Service server is required for any conferencing site. Only one Conference Management Service per site is active at a given time. Starting with Exchange Conferencing Server SP1, you can install a backup Conference Management Service in the site, and this backup Conference Management Service will take over if there is any interruption in service for the primary Conference Management Service. Conference Management Service Failover

The first Conference Management Service installed in the site is automatically assigned as the primary Conference Management Service for the site. After installing the second Conference Management Service, administrators can configure it as a backup Conference Management Service. All other Conference Management Service installations will be idle, unless the administrator assigns one to be active or backup. The backup Conference Management Service makes periodic Distributed Component Object Model (DCOM) calls to the primary Conference Management Service to verify that the latter is functioning. If a call fails, the backup Conference Management Service changes its status to primary and the primary Conference Management Service to backup. If there is a network failure, then in very rare cases each Conference Management Service may ‘think’ it is the primary Conference Management Service, and the conferencing site might become unstable. This state may last for up to several minutes until the former primary Conference Management Service gets the Active Directory notification about the change and transitions into a backup state, after which the functionality of the site is restored. To avoid conflicts between the primary and backup Conference Management Service, make sure the network connection between primary and backup Conference Management Service servers is reliable. Determining the Number of Conferencing Sites

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 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 in 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 in the perimeter network (also

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

13

known as DMZ, demilitarized zone, and screened subnet) or extranet for conferences that are published to the Internet. •

Multisite conference topologies Because only one instance of Conference Management Service is active in a Windows 2000 site, consider balancing your user load across multiple sites by assigning users to sites according to their geographic locations. Data Conferencing Provider uses the conferencing site architecture to assign a conference participant to the T.120 MCU that is closest to the participant’s computer.

The cost of network bandwidth between Windows sites and subnets in a conferencing site affects where you should 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 the closest MCU. The Data Conferencing Provider then creates a unicast connection between the MCUs in difference sites. By bridging multiple MCUs, Exchange Conferencing Server provides a network model that is more scalable and that uses network bandwidth more efficiently than having, for example, only one MCU service your entire organization. Initially, you can install one conferencing site, use the audit log files generated by Conference Management Service to monitor conference participation, and then decide whether 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.

Deploying Data Conferencing Major Deployment Options The scenarios described in the following sections and the combination of one or more scenarios are the best practice recommendations for deploying Exchange Conferencing Server. Single-Server Deployment The single-server deployment is the simplest Exchange Conferencing Server scenario. In this case, you install all components of Exchange Conferencing Server on a centralized server, and all conferencing clients use the central server for their conferencing needs. The advantages of a single-server deployment include: •

Easy deployment path The single-server deployment is the easiest to deploy from a server standpoint, and you can use it as a pilot deployment to better understand how to use Exchange Conferencing Server in your organization.

•

Low administration overhead Managing a single Exchange Conferencing Server requires little additional administration of your server and site configuration.

The challenges associated with a single-server deployment include:

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

14

•

Scalability Exchange Conferencing Server can only provide the conferencing capabilities as provided by one MCU and cannot perform any load-balancing. In addition, if there are multiple clients in a remote network location, bandwidth is not used effeciently.

•

Reliability In a single-server deployment, there are no backup components such as a backup Conference Management Service or other MCUs to handle conferencing services in the event of failure of any Exchange Conferencing Server component.

•

Feature limitations If your network does not support multicast, some remote clients may not be able to participate in multicast videoconferences.

The single-server deployment scenario is shown in Figure 1.

Figure 1

Single-server deployment scenario

Single-Server Deployment Metrics

The following are the approximate scalability numbers for the single-server deployment illustrated in Figure 1: Server configuration: Number of processors: 2 Processor speed: PIII-800 megahertz (MHz) Physical memory: 512 megabytes (MB) Operating system: Windows 2000 Advanced Server SP3 ECS regkeys set to non-default values: none Client #1 configuration: Number of processors: 1 Processor speed: PIII-1 gigahertz (GHz) Physical memory: 256 MB Operating system/Browser: Windows 2000 Professional SP3, Internet Explorer 6 SP1

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

15

Client #2 configuration: Number of processors: 1 Processor speed: Celeron 600 MHz Physical memory: 256 MB Operating system/Browser: Windows 2000 Professional SP3, Internet Explorer 6 SP1 Note

All network cards set to 100-MB full duplex.

Scalability tests descriptions: Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. Users were simulated using tools that mimic NetMeeting client usage and load. Definitions for each type of user: Application sharing Full-screen true-color shared graphical Microsoft PowerPoint® slide deck, alternately minimizing and maximizing PowerPoint every 15 seconds which forces a repaint of entire shared screen. Application viewing

Receives and views shared application.

Note Typically, these are worst-case scenarios, where data conferencing tasks were simulated at above normal rates. Therefore, results may be higher than expected for typical users who would normally not complete multiple tasks at this speed and would pause more frequently. Large conferences: Load simulated clients into 100-user conferences until performance between two real NetMeeting users in a separate conference on that MCU exceeds: 60 seconds to join1 and 10 seconds to application-share2. 100-user conferences are comprised of one Application Sharer and 99 Application Viewers. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. Many small conferences:

1

Time elapsed from opening the conference URL to a fully rendered shared application screen. This includes NetMeeting starting, connecting to and joining the conference, and rendering the shared application. 2

Time elapsed from the first NetMeeting user maximizing the shared application to the second NetMeeting user receiving the fully rendered shared application update.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

16

Load simulated clients into 10-user conferences until performance between two real NetMeeting users in a separate conference on that MCU exceeds: 60 seconds to join and 10 seconds to application-share. 10-user conferences are comprised of one Application Sharer and nine Application Viewers. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. List: View the Exchange Conferencing Server List conferences Web page (increasing 100 conferences at a time) until the time to render the list is greater than 10 seconds. This is performed once with anonymous meetings scheduled and listed by an anonymous user, and again with private meetings scheduled and listed by an authenticated user3. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. The tests were run multiple times with the two clients described previously to determine the range of listed conferences below. Approximate scalability numbers: •

For large conferences: up to 200 users (two 100-user conferences) can be supported simultaneously while maintaining the required performance goals.

•

For many small conferences: up to 400 users (40 10-user conferences) can be supported simultaneously while maintaining the required performance goals.

•

For list, between 400 and 1,200 conferences can be listed anonymously, and 300 and 1,000 can be listed authenticated.

Single-Site Deployment The single-site deployment, with additional data functionality, expands on the single server deployment. In this scenario, the conferencing services reside in a single location, but there are dedicated servers for Exchange Conferencing Server components as well as additional Conference Management Service and MCU servers within that site to provide more scalability and reliability. The advantages of a single-site deployment include: •

Single source of conference scheduling and scheduled from a single site.

•

Scalability Exchange Conferencing Server is able to take advantage of its load balancing algorithms to connect conferencing clients to an available MCU.

•

Reliability Multiple servers provide reliability by means of a failover of conferencing components.

All conferences are still managed

The challenges associated with a single-site deployment are:

3

Authenticated users require more time to list because they must be verified as invitees to the conferences in order to view it in the list.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

17

•

Additional server management There are multiple conferencing server computers and components deployed in your network that require management and administration.

•

Inefficient bandwidth usage If there are multiple clients in a remote network location, bandwidth is not used as effeciently as it is when deploying Exchange Conferencing Server in the remote location.

The diagram of a sample single-site scenario is shown in Figure 2.

Figure 2

Single-site deployment scenario

Single-Site Deployment Metrics

The following are the approximate scalability numbers for the single-site deployment illustrated in the preceding diagram: Server configurations (all servers have identical hardware): Number of processors: 2 Processor speed: PIII-800 MHz Physical memory: 1024 MB Operating system: Windows 2000 Advanced Server SP3 ECS regkeys set to non-default values: none Client #1 configuration:

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

18

Number of processors: 1 Processor speed: PIII-1 GHz Physical memory: 256 MB Operating system/Browser: Windows 2000 Professional SP3, Internet Explorer 6 SP1 Client #2 configuration: Number of processors: 1 Processor speed: Celeron 600 MHz Physical memory: 256 MB Operating system/Browser: Windows 2000 Professional SP3, Internet Explorer 6 SP1 Note

All network cards set to 100-MB full duplex.

Scalability tests descriptions: Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. Users were simulated using tools that mimic NetMeeting client usage and load. Definitions for each type of user: Application sharing Full-screen true-color shared graphical Microsoft PowerPoint slide deck, alternately minimizing and maximizing the slide every 15 seconds, which forces a repaint of entire shared screen. Application viewing

Receives and views shared application.

Note Typically, these are worst-case scenarios, where data conferencing tasks were simulated at above normal rates. Therefore, results may be higher than expected for typical users, who would normally not complete multiple tasks at this speed and would pause more frequently. Large conferences: Load simulated clients into 100-user conferences until performance between two real NetMeeting users in a separate conference on that MCU exceeds: 60 seconds to join4 and 10 seconds to application-share5. 100-user conferences are comprised of one Application Sharer and 99 Application Viewers. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. Many small conferences:

Time elapsed from opening the conference URL to a fully rendered shared application screen. This includes NetMeeting starting, connecting to and joining the conference, and rendering the shared application. 4

5

Time elapsed from the first NetMeeting user maximizing the shared application to the second NetMeeting user receiving the fully rendered shared application update.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

19

Load simulated clients into 10-user conferences until performance between two real NetMeeting users in a separate conference on that MCU exceeds: 60 seconds to join, 10 seconds to application-share. 10-user conferences are comprised of one Application Sharer and 9 Application Viewers. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. List: View the ECS List conferences Web page (increasing 100 conferences at a time) until the time to render the list is greater than 10 seconds. This is performed once with anonymous meetings scheduled and listed by an anonymous user, and again with private meetings scheduled and listed by an authenticated user6. Exchange Conference Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic.. The tests were run multiple times with the two clients described previously to determine the range of listed conferences below. Approximate scalability numbers: •

For large conferences: up to 500 users (five 100-user conferences) can be supported simultaneously, load-balanced across the three MCUs, while maintaining the required performance goals.

•

For many small conferences: up to 1,000 users (100 10-user conferences) can be supported, simultaneously load-balanced across the three MCUs, while maintaining the required performance goals.

•

For list, between 400 and 1,200 conferences can be listed anonymously, and 300 and 1,000 can be listed authenticated.

Mixed Exchange 5.5 and Exchange 2000 Environments It is possible to deploy conferencing services to support users on Exchange Server version 5.5 and Exchange 2000 servers. In a mixed environment, both Exchange 5.5 users and Exchange 2000 users are able to schedule, join, and participate in online conferences by using Exchange 2000 Conferencing Server. A sample topology for a single-site deployment in a mixed environment is shown in Figure 3.

6

Authenticated users require more time to list because they must be verified as invitees to the conferences in order to view it in the list.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

20

Figure 3 scenario

Single-site deployment in a mixed Exchange 5.5/Exchange 2000

For more information about how to deploy Exchange Conferencing Server in a mixed Exchange 5.5 and Exchange 2000 environment, see http://www.microsoft.com/exchange/techinfo/deployment/2000/ECSmixed.asp. Note To enable users in the Windows NT® 4.0 domain to participate in private conferences, you need to install a stand-alone Root CA (Certificate Authority) service on a Windows 2000 member server in the Windows NT 4.0 domain. For more information, see Microsoft Knowledge Base article 321953, “Your Certificate Request was Denied Error Message Occurs When You Request a Certificate for Secure Conferences” at http://support.microsoft.com/support/kb/articles/q321/9/53.asp. Remote MCU Deployment In some cases, a conferencing site can span multiple Active Directory sites. For example, you can install only T.120 MCU components in an Active Directory site and associate those MCUs with a CMS in another Active Directory site. This configuration is called a “remote MCU” deployment. In a remote MCU deployment, the Conference Management Service services are still provided from a central location, but there are MCUs strategically placed to support clients in remote locations. The advantages of a multiple remote location deployment include: •

Bandwidth utilization For inter-site conferences in which there are multiple clients from a remote location, the bandwidth is used more efficiently because of single-instancing of packets and connections between MCUs per conference.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

21

The challenges associated with a multiple remote location deployment include: •

Administration overhead Each remote location conferencing server requires additional administrative overhead to maintain and support.

•

Scalability Having only one active Conference Management Service can be a bottleneck to support a large number of conferences. In addition, the top node MCU in the central site can be another scalability limitation because a remote MCU communicates with the top node MCU even if all of the conference clients are local to the remote MCU.

Another example of a conferencing site spanning multiple Active Directory sites is the so-called “MCU affinity” configuration in which one or more Active Directory sites are assigned to an MCU. In this configuration, all T.120 data conferencing connections initiated from a remote site without any Exchange Conferencing Server components directed to the MCU(s) controlling that remote site. These MCUs are often called “local to remote site” MCUs. This configuration may be useful if there is a reason for assigning data conferencing traffic to specific routes when there is more than one alternative. A sample diagram of an extended conferencing site with remote MCU deployment and MCU affinities is shown in Figure 4.

Figure 4

Remote MCU deployment scenario

You must configure more than one Windows 2000 site before the Conference Management Service can distinguish conferencing clients as either connecting locally or from a remote site. If you do not configure more than one site, all conferencing clients appear to come from the default single Windows 2000 site. For information about how to configure Windows 2000 sites, see the Windows 2000 online documentation.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

22

Changing the Default Remote MCU Connection Logic

The following is the default client connection process for clients in "MCU only" sites: •

If the MCU in the "MCU only" site is not accessible, then clients will fail over to any other MCU in the client’s Active Directory site.

•

If all the MCUs in the client's Active Directory site are not accessible, the client will connect to an available MCU in the "Host Conferencing Site" (which can span multiple Active Directory sites).

Exchange Conferencing Server SP3 enables administrators to change this default process to prevent clients in "MCU only" sites from failing over to a "Host Conferencing Site" MCU. Administrators may want to consider this change if the client’s “MCU only” site is across a wide area network (WAN) link from the “Host Conferencing Site.” To change the default client connection process for clients in “MCU only” sites 1. In HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange Conferencing\Parameters, create a DWORD registry value named NoRemoteLoadBalancing. Caution Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. 2. Set the value of NoRemoteLoadBalancing to 1. If the value does not exist or is set to zero (0), the default process described above will be applied, and such cross-site connections will be allowed. Important If this change is applied, and there are no available MCUs in the "MCU only" site, clients in the “MCU only” site will not be able to join conferences until an MCU is available. Remote MCU Deployment Metrics

The following are the approximate scalability numbers for the remote MCU deployment illustrated in the preceding diagram: Server configurations (all servers have identical hardware): Number of processors: 2 Processor speed: PIII-800 MHz (CMS/CWA), PIII-550 MHz (MCU) Physical memory: 1024 MB (CMS/CWA), 512 MB (MCU) Operating system: Windows 2000 Advanced Server SP3 ECS regkeys set to non-default values: none WAN speed: 256 kilobits per second (Kbps) Client #1 configuration: Number of processors: 1

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

23

Processor speed: PIII-1 GHz Physical memory: 256 MB Operating system/Browser: Windows 2000 Professional SP3, Internet Explorer 6 SP1 Client #2 configuration: Number of processors: 1 Processor speed: Celeron 600 MHz Physical memory: 256 MB Operating system/Browser: Windows 2000 Professional SP3, Internet Explorer 6 SP1 Note

All network cards set to 100 MB full duplex.

Scalability tests descriptions: Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. Users were simulated using tools that mimic NetMeeting client usage and load. Definitions for each type of user: Application sharing Full-screen true-color shared graphical PowerPoint slide deck, alternately minimizing and maximizing the slide every 15 seconds, which forces a repaint of entire shared screen. Application viewing

Receives and views shared application.

Note Typically, these are worst-case scenarios, where data conferencing tasks were simulated at above normal rates. Therefore, results may be higher than expected for typical users, who would normally not complete multiple tasks at this speed and would pause more frequently. Large conferences: Load simulated clients into 100-user conferences (splitting users in each conference between each site) until performance between two real NetMeeting users in a separate conference across the MCUs exceeds: 60 seconds to join7 and 10 seconds to application-share8. 100-user conferences are comprised of one Application Sharer and 99 Application Viewers. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. There are only two MCUs available to join: one in the Exchange Conferencing Server site and one in the Remote MCU site. Time elapsed from opening the conference URL to a fully rendered shared application screen. This includes NetMeeting starting, connecting to and joining the conference, and rendering the shared application. 7

8

Time elapsed from the first NetMeeting user maximizing the shared application to the second NetMeeting user receiving the fully rendered shared application update.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

24

Many small conferences: Load simulated clients into 10-user conferences (splitting users in each conference between each site) until performance between two real NetMeeting users in a separate conference on that MCU exceeds: 60 seconds to join and 10 seconds to application-share. 10-user conferences are comprised of one Application sharer and nine Application Viewers. Exchange Conference Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. There are only two MCUs available to join: one in the Exchange Conferencing Server site, and one in the Remote MCU site. List: View the ECS List conferences Web page (increasing 100 conferences at a time) from the Remote MCU site until the time to render the list is greater than 10 seconds. This is performed once with anonymous meetings scheduled and listed by an anonymous user, and again with private meetings scheduled and listed by an authenticated user9. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic.. The tests were run multiple times with the two clients described previously to determine the range of listed conferences below. Approximate scalability numbers: •

For large conferences: up to 300 users (three 100-user conferences) can be supported, load-balanced across the two MCUs, while maintaining the required performance goals.

•

For many small conferences: up to 700 users (70 10-user conferences) can be supported, load-balanced across the two MCUs, while maintaining the required performance goals.

•

For list, between 400 and 1,200 conferences can be listed anonymously, and between 300-1,000 can be listed authenticated.

Deploying Exchange Conferencing Server for Business-to-Business Conferencing The business-to-business deployment scenario is optimal for organizations that want to host conferences with clients that are not part of the corporate network. In this deployment, Exchange Conferencing Server is configured to support users that connect through firewalls and proxy servers. The advantage of a business-to-business deployment includes: •

Extended collaboration Users can have conferences with clients that are not part of your corporate network.

Authenticated users require more time to list because they must be verified as invitees to the conferences in order to view it in the list. 9

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

25

The challenges associated with a business-to-business deployment scenario include: •

Security considerations As with all information that leaves the corporate network, conferencing across the Internet requires additional security considerations such as configuring certificate services or installing Conference Web Access in a secure virtual directory, that is, a virtual directory that requires connection over Secure Sockets Layer (SSL).

•

Firewall modification To enable Internet conferencing, you must work with your firewall administrators to create a network and port access scheme to work with the conferencing requirements. If you are using tunnelling to provide SSL conferencing with remote users, only the SSL port needs to be available for conferencing.

A diagram of an Internet deployment scenario is shown in Figure 5.

Figure 5

Perimeter network deployment scenario

In this recommended configuration, the conferencing site is deployed in a separate Active Directory forest, called “Application Vault”, which is separated from the corporate perimeter network by a reverse proxy. This adds an additional security layer to the deployment. You can also deploy Exchange Conferencing Server in the perimeter network with MCUs and Conference Web Access directly accessible from the Internet over HTTPS ports. For simplicity, we use the term “perimeter network deployment” to refer to either of these options.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

26

Perimeter Network Deployment Metrics

The following are the approximate scalability numbers for the perimeter network deployment illustrated in Figure 5: Server configurations (all servers have identical hardware): Number of processors: 2 Processor speed: PIII-800 MHz (CMS/CWA) (MCU) Physical memory: 1024 MB (CMS/CWA), 256 MB (MCU) Operating system: Windows 2000 Advanced Server SP3 ECS regkeys set to non-default values: in HKLM\Software\Microsoft\Exchange Conferencing\Parameters, DWORD PortNumber = 443 WAN speed: 256 Kilobits per second (Kbps) Client #1 configuration: Number of processors: 1 Processor speed: PIII-1 GHz Physical memory: 256 MB Operating system/Browser: Windows 2000 Professional SP3, Internet Explorer 6 SP1 Client #2 configuration: Number of processors: 1 Processor speed: Celeron 600 MHz Physical memory: 256 MB Operating system/Browser: Windows 2000 Professional SP3, Internet Explorer 6 SP1 Note

All network cards set to 100 MB full duplex.

Scalability tests descriptions: Exchange Conference Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. Users were simulated using tools that mimic NetMeeting client usage and load. Definitions for each type of user: Application sharing Full-screen true-color shared graphical PowerPoint slide deck, alternately minimizing and maximizing the slide every 15 seconds, which forces a repaint of entire shared screen. Application viewing

Receives and views shared application.

Note Typically, these are worst-case scenarios, where data conferencing tasks were simulated at above normal rates. Therefore, results may be

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

27

higher than expected for typical users, who would normally not complete multiple tasks at this speed and would pause more frequently. Large conferences: Load simulated clients into 50-user conferences until performance between two real NetMeeting users in a separate conference exceeds: 60 seconds to join10 and 10 seconds to application-share11. 50-user conferences are comprised of one Application sharer and 49 Application Viewers. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. There is only one MCU available to join in the perimeter network. Many small conferences: Load simulated clients into 10-user conferences until performance between two real NetMeeting users in a separate conference exceeds: 60 seconds to join and 10 seconds to application-share. 10-user conferences are comprised of one Application sharer and nine Application Viewers. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. There is only one MCU available to join in the perimeter network. List: View the ECS List conferences Web page (increasing 100 conferences at a time) from the perimeter network until the time to render the list is greater than 10 seconds. This is performed once with anonymous meetings scheduled and listed by an anonymous user, and again with private meetings scheduled and listed by an authenticated user12. Exchange Conferencing Server scale characteristic testing was performed in a controlled environment on a 100-MB network that only supports Exchange Conferencing Server client and server traffic. The tests were run multiple times with the two clients described previously to determine the range of listed conferences below. Approximate scalability numbers: •

For large conferences: up to 200 users (four 50-user conferences) can be supported while maintaining the required performance goals.

•

For many small conferences: up to 3,500 users (35 10-user conferences) can be supported while maintaining the required performance goals.

•

For list conferences, between 400 and 800 conferences can be listed anonymously, and 300 and 600 can be listed authenticated.

Time elapsed from opening the conference URL to a fully rendered shared application screen. This includes NetMeeting starting, connecting to and joining the conference, and rendering the shared application. 10

11

Time elapsed from the first NetMeeting user maximizing the shared application to the second NetMeeting user receiving the fully rendered shared application update. 12 Authenticated users require more time to list because they must be verified as invitees to the conferences in order to view it in the list.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

28

HTTPS Tunneling

To enable business-to-business collaboration, starting with SP3, Exchange Conferencing Server supports HTTPS tunneling for T.120 data conferences. This capability allows conference attendees from other organizations and from the Internet to participate in Exchange Conferencing Server data conferences from behind proxy servers and firewalls in a transparent fashion, where security is enhanced or increased. Note To use the new HTTPS tunneling feature, client computers must not be running a version of Windows earlier than Windows 2000, a version of Internet Explorer earlier than version 5.0 , or a version of NetMeeting earlier than version 3.01. To enable HTTPS tunneling of Exchange Conferencing Server data conferences Exchange Conferencing Server SP3 enables tunneling of T.120 traffic over SSL to get through firewalls and proxy servers in client and server networks. The following procedure is required to configure Exchange Conferencing Server tunneling: 1. Configure Active Directory Configuration to support Exchange Conferencing Server in the perimeter network/application vault. The following are the recommended Active Directory configuration options: a. Corpnet and perimeter network are in separate forests with unidirectional trust, where the perimeter network trusts the Corpnet, and user objects in Active Directory are replicated to the conferencing forest as disabled user accounts (see account replication details below). b. Corpnet and the perimeter network are in separate forests with no trust or user information replicated to the perimeter network. However, the perimeter network has external accounts and mailboxes created for conferencing users. The first option enables the users within your organization to schedule meetings in the perimeter network by using their corporate accounts. The second option requires a separate set of credentials to schedule (unless anonymous scheduling is enabled) and participate in private conferences. To enable the first option, replicate the following user object attributes to the perimeter network Active Directory (note the mapping of attributes): Table 2

User object attributes for perimeter network replication CorpNet

Perimeter network

sAMAccountName

sAMAccountName

objectSid

msExchMasterAccountSid

Mail

mail

mailNickname

mailNickname

legacyExchangeDN

legacyExchangeDN

textEncodedOrAddress

textEncodedOrAddress

msExchHomeServerName

msExchHomeServerName

proxyAddresses

proxyAddresses

userPrincipalName

userPrincipalName

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

29

givenName (optional)

givenName (optional)

sn (optional)

sn (optional)

initials (optional)

initials (optional)

2. Create Certificate Authority/Public Key Infrastructure (PKI). Certificates are required for: MCU Server Certificate to allow secure conferencing; MCU will install certificate from certificate authority (CA) if present. Conference Web Access Server Certificate for Web server to enable SSL. Conference Management Service Server Certificate for secure conferencing. Users User Certificate (Authentication Enabled) to authenticate and encrypt T.120 conference data. 3. Configure port restrictions. Table 3 shows the port requirements between the corporate network and the perimeter network/application vault. Table 3 Port requirements between corporate network and perimeter network/application vault Type of traffic

Port

Inbound or outbound

T.120 Traffic

SSL (443) – TCP

Inbound (also configurable to any arbitrary port)

Conference Web Access – Web Traffic

SSL (443) – TCP

Inbound

SMTP

Mail (25)- TCP

Inbound/outbound – Delivery of Meeting Requests

Domain Name System (DNS)

53 – TCP/UDP

Inbound/outbound

Active Directory unidirectional

445 – TCP

Trust secure Active Directory channel

Kerberos

88, 464 - TCP/UDP

Inbound/outbound

Optional

MAPI scheduling requires dynamic ports – RPC and established TCP ports

Inbound

Lightweight Directory Access Protocol (LDAP)

389 – TCP/UDP

Inbound/outbound

RPC

135 - TCP (You can define the higher ports used after the initial connection is established through the registry.)

Inbound/outbound (point-topoint between the domain controllers)

Optional

GC (3268) and other ports for Active Directory-Active Directory bidirectional trust (if required)

Inbound/outbound

Other routing/management protocols as required by corporate standards

As needed

As needed

Table 4 shows the port requirements between the perimeter network/application vault and the Internet. (For more information about

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

30

how to configure Active Directory segments separated by firewalls, see http://www.microsoft.com/windows2000/docs/adsegmented.doc). Table 4 Internet

Port requirements between perimeter network/application vault and

Type of traffic

Port

Inbound or outbound

T.120 Traffic

SSL (443) – TCP

Inbound (also configurable to any arbitrary port)

Conference Web Access – Web Traffic

SSL (443) – TCP

Inbound

Simple Mail Transfer Protocol (SMTP)

Mail (25)- TCP

Inbound/outbound – Delivery of Meeting Requests

DNS

(53) – TCP/UDP

Inbound/outbound

Kerberos

(88, 464) TCP/UDP

Inbound/outbound

4. Enable HTTPS tunneling by setting the following registry key on each Conference Management Service server in the perimeter network: In HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange Conferencing\Parameters create a DWORD registry value named PortNumber. Set the value of PortNumber to 443 or the alternate TCP port you want to use (the use of TCP port 80 is not recommended). Caution Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. You must restart the Conference Management Service for this change to take effect. When this registry key is set, all the T.120 MCUs in the site listen on both the default TCP port 1503 as well as on the alternate port defined by the registry key for client connections. Connecting to that site, all of the clients that meet the software requirements described below will automatically connect over the alternate port. Other supported clients may be able to connect to the data conference by using the default TCP port 1503, unless firewalls or proxies prevent such connections. 5. Set the MCU network names used for local, remote and Internet connections to a Fully Qualified Domain Name (FQDN) value for all MCUs in the perimeter network. 6. For better security and more efficient use of system resources, disable services you will not need in the perimeter network. For example, if you are not planning to use H.323 audio/video conferences in the perimeter network, disable the Microsoft Exchange H.323 Bridge service on all T.120 MCU servers in the perimeter network. Note All communication over the alternate port is encrypted regardless of the conference security settings. A valid server certificate must be installed on each T.120 MCU in the site. If the certificate is missing from a T.120 MCU, that MCU will successfully bind to the alternate port; however,

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

31

users will not be able to join any public, password-protected public, or private data conferences on that MCU. For a sample configuration of the perimeter network and application vault firewalls and the proxy server, see the Appendix. Active Directory Sites

You must configure more than one Windows 2000 site and subnet before the Conference Management Service can distinguish conferencing clients as either connecting locally or from the Internet. If you do not configure more than one site, all conferencing clients appear to come from the default (the internal) Windows 2000 site. Certificate Services

To participate in secure conferences, participants must not be using a version of NetMeeting earlier than version 3.01 or a version of Internet Explorer earlier than version 4.01. To support public, public with required password, and private conferences as well as SSL access to Conference Web Access, 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 servers and users that authenticate them for secure conferences. Server certificates are required for Conference Web Access if it is installed into a secure site (that is, a site that requires connection over SSL), as well as for MCUs that use HTTPS tunneling. Server certificates are also required for MCUs that host private and encrypted password–protected public meetings. User certificates are required for private meetings. In addition, for encrypted password-protected public meetings and all tunneled meetings, a default NetMeeting certificate must be present on the client computer. To enable encryption for password–protected public meetings To enable encryption for password-protected public T.120 data conferences, set the following registry key on all servers running Conference Management Service in your organization: 1. Create the following key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Conferencing\Parameters,: EncryptPasswordConferences DWORD value = 1 The MCU must have a valid server certificate installed to support encrypted conferences. Caution Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. 2. Restart Conference Management Service for this change to take effect.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

32

If you do not set the EncryptPasswordConferences registry key on all Conference Management Service servers in the organization, some users may not be able to join password-protected conferences. To join encrypted conferences, the clients must not use a version of Internet Explorer earlier than version 4.01 or a version of NetMeeting earlier than version 3.01. H.323 clients will not be able to join encrypted conferences. Note This registry key has no effect if HTTPS tunneling is enabled on that server. If the conference is private, the MCU server and client both exchange certificates before establishing a secure connection. Certificates are checked for validity by both sides. For the connection to succeed, the certificates must be trusted, unrevoked, and unexpired, and information in the certificates must identify an expected entity; for the client, it must be an e-mail address of an invited attendee, and for the server, it must be an MCU network name of a valid server in the organization. Note The certificates are only verified against the cached certificate revocation lists. Neither server nor clients have the functionality to renew revocation lists from the certificate authority. To configuring secure conferencing 1. Install CA Root and certificate on the MCU, then verify: a. Windows 2000 standalone CA Note The Q323172: Security Update must be installed after installing the CA. This update resolves the "Flaw in Digital Certificate Enrollment Component Allows Certificate Deletion" security vulnerability in Windows NT 4.0. 1. Go to the MCU computer. 2. In Internet Explorer, go to http:///certsrv. 3. Select Retrieve the CA Certificate. 4. Select Download the CA Certificate and save to disk. 5. Go back and select Request a Certificate. 1. Choose Advanced Request and Submit a cert request…using a form. 2. Fill in the following fields exactly as stated: a. Name: Fully Qualified Domain Name (FQDN) of MCU b. E-mail – Country: anything c. Intended Purpose: Server Authentication Certificate d. Key Options: CSP: Microsoft Enhanced Cryptographic Provider e. Key Size: 1024 (or greater) f. Use local machine store 3. Install the certificate. 6. From a Run command line, type MMC

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

33

7. Click File, Add/Remove Snap-in, Add, Certificates, Add, 8. 9. 10. 11.

Computer Account, Next, Finish, Close, and then OK. In Certificate Snap-In, expand Certificates (local computer) and Trusted Root Certification Authorities. Right-click Certificates and then click Import and import the file from step 4. Refresh, click and open the certificate, and verify that no errors have occurred by clicking the General tab. Repeat steps 8-11 for Personal folder and verify MCU cert.

b. Windows 2000 Enterprise CA 1. Certificate should automatically download and install on MCU. 2. Verify certificate using steps 6-11. 3. Make sure that one of the MCU network names on the MCU property page matches the Name in the certificate (usually automatically set to FQDN). c. Third-Party CA 1. Install certificate using third-party instructions. 2. Verify certificate using steps 6-11. 2. Install CA certificate into Trusted Root CAs on Conference Management Service; verify: a. Repeat steps 1-4 to install CA certificate. b. Repeat steps 8-10 to verify. 3. Create user account in Active Directory; optionally, create mailbox and verify SMTP address: a. Open Active Directory Users and Computers and add a user account. b. Verify that the account has at least one SMTP address. Add additional SMTP addresses as needed. 4. Install certificate on client. 1. Go to the client computer. 2. In Internet Explorer, go to http:///certsrv. 3. Select Request a Certificate. 1. Click Advanced Request, and then Submit a cert request…using a form. 2. Fill in the following fields exactly as stated: a. Name: Anything b. E-mail: Correct SMTP address of client c. Company – Country: anything d. Intended Purpose: E-mail Protection Certificate e. Key Options: CSP: Microsoft Enhanced Cryptographic Provider f. Key Size: 1024 (or greater) g. If your client has an older Windows version, such as Windows 98, ME, or Windows NT version 4.0, mark keys as exportable. 3. Install the certificate. 4. Verify:

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

34

a. In Internet Explorer, click Tools, Internet b. c.

Options, Content, and Certificates. Click the Personal tab and verify that cert is listed. Open cert and verify that the General tab shows no errors.

5. Install client CA on MCU; verify: a. If Client certificate is from a different CA than the MCU and Conference Management Service certificates, then repeat steps 1-4 and 8-10 from step 1 “Install CA Root on the MCU, verify.”

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

35

6. Install client CA on Conference Management Service; verify: a. If client cert is from a different CA than the MCU and Conference Management Service certificates, then repeat steps 1-4 and 8-10 from step 2 “Install CA Cert into Trusted Root CAs on Conference Management Service, verify.” 7. Restart MCU: a. Verify that no other server certificates are installed for the MCU (if so, remove them). b. Restart MCU. 8. Restart Conference Management Service. 9. Schedule and join a secure conference. Best Practices Using Certificates

•

Depending on your enterprise security policies and regulations in your company, you can vary the number and level of PKI certifying authorities that you choose to trust. The recommended option is to start with an empty list of CAs, intermediate CAs, third-party CAs, and so on in the local machine store, and add only the absolute minimum set of authorities required. You can limit it to the stand-alone CA in the perimeter network if the installation is set up for the highest level of security, and that CA is the only authority issuing certificates based on the set of user accounts in the perimeter network forest (replicated-disabled or active-regular).

•

The following criteria is used for evaluating client certificates for acceptance on the Exchange Conferencing Server Servers for use in the T.120 session for which there is no manual process to override:

•

•

Validity Dates for expiration, Version number (v3 only,) public key sizes (less than 4096), Enhanced Key Usage enabled for client authentication (if present), and policies on the server that include the trusted CAs and Certificate Revocation Lists on the server computer.

•

Similar requirements will be enforced for selection of the MCU Server certificate on startup with the exception of the Enhanced Key Usage, which should be set to “Server Authentication.”

Renew Certificate Revocation Lists (CRLs) on your conferencing servers regularly, especially if you are relying on third-party certificate authorities.

Conference Web Access

For stronger security, you can deploy Exchange Conferencing Server to require SSL for access to Exchange Conferencing Server Web pages. The first time that you install Exchange Conferencing Server, assuming that you are not using a version earlier than SP2, you can select the Conference Access SSL Support option by expanding the Conference Access Web Pages node during installation. Conference Access SSL Support is a node in the Conference Access Web Pages node and is not installed by default. The option to set up conference access pages in a secure site is enabled only if IIS has a server certificate enabled for the default Web site. If this certificate is not enabled, Exchange Conferencing Server does not display the SSL Support option in

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

36

the component selection menu. You must not be using a version earlier than Exchange Conferencing Server SP2 for the option to display. If you upgrade an existing Exchange Conferencing Server installation and you want conference access pages in a secure site, you must change the conference access URL in the Conference Management Service properties to begin with https rather than http. After you run update.exe to install SP2, open Control Panel, doubleclick Add/Remove Programs, click Microsoft Exchange 2000 Conferencing Server, and then click Change. Click Next twice to modify, click Conference Access Web Pages, and then click Conference Access SSL Support. Warning When you change the conference access URL, users will lose access to all previously scheduled conferences in that site. For Internet participants to be able to join a conference, the DNS name of the conference access pages server must be available to Internet users, and the firewall must allow HTTPS (or HTTP if Conference Web Access does not require SSL) access to that server; inbound, TCP port 443 (or 80 if no SSL) should be opened. Combining Deployment Options into a Multi-Site Deployment If you have many users participating in conferences in different geographical locations or in different Active Directory sites, consider a multi-site deployment, in which a full set of conferencing components is deployed in each Active Directory site. Any of the previously described deployment configurations may represent a conferencing site. Select an appropriate configuration depending on your specific needs and taking into account the comparative advantages and limitations of each topology described previously. A multi-site deployment introduces additional efficiencies and special considerations listed below. The advantages of a multi-site deployment include: •

Bandwidth utilization As with remote MCU, with multi-site deployment conference attendees are connected to their local MCUs even when participating in a data conference in a remote site. Thus, for inter-site conferences in which there are multiple clients from remote locations, the bandwidth is used more efficiently because of single-instancing of packets and connections between MCUs per conference. In addition, if conferences are local to an Active Directory site, all of the conferencing traffic is completely contained in the local site, and no inter-site conferencing traffic occurs on the network.

•

Scalability Multi-site deployment is more scalable, because the conference management and Web services are distributed among mutiple Conference Management Service and Conference Web Access installations.

•

Decentralized management Multi-site deployment facilitates distributed geographical and organizational IT management structures and enables independent configurations and usage scenarios.

•

Local multicast If the network does not support multicast between the sites, the users can still have multicast videoconferences locally.

The challenges associated with a multiple remote location deployment include:

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

37

•

Administration overhead Each remote location conferencing server requires additional administrative overhead to maintain and support.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

38

A sample multi-site deployment is shown in Figure 6.

Figure 6

Multi-site deployment scenario

Trust Relationships (see numbered callouts in Figure 6) 1. Tree Root Primary Domain Controller 1, Primary Domain Controller 2 (Site A and Site B) and Primary Domain Controller 3 (Site C) - 2-way trust (default) 2. Primary Domain Controller 3 (Site C) and Child Domain Controller 1 (Site D) 2-way trust (default) 3. Primary Domain Controller 3 (Site C) and Windows NT 4.0 domain - 2-way trust (non-default) 4. Tree Root Primary Domain Controller 1, Primary Domain Controller 2 (Site A and B) and Windows NT 4.0 domain - No trusts 5. Child Domain Controller 1 (Site D) and Windows NT 4.0 - No trusts 6. Tree Root Primary Domain Controller 4 (Site G) - No trusts Note The scalability and performance figures for multi-site deployments depend on the number and specific configuration of individual conferencing sites. You can estimate the total scalability of a multi-site deployment by adding up scalability numbers of individual sites.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

39

Deciding on the Deployment Option Consider the following questions when deciding what deployment option to choose. Will your conferences be hosted from a central location? Hosting conferences from a central location is a typical configuration for a company that has a central office and does not have a large presence in other offices, if any. In this configuration, users that are not in the central location may want to participate in conferences or even organize them with users in their own locations, but there is not enough conferencing activity to justify deploying the additional components, or there is good connectivity (such as a fast WAN connection) between the remote location and the central location. The advantages to hosting conferences from a central location include simplified administration and lower hardware costs that stem from managing a single server or single-site deployment. The disadvantage to centralized conferencing services is lower scalability and inefficient use of bandwidth necessary to support remote users. In a backbone deployment 13, network services such as e-mail and database services are usually located in a centralized data center. In this case, you could place the components of Exchange Conferencing Server in the centralized location, and install additional 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 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 and manageability over the servers. However, there is more network traffic between subnets. Will clients from remote networks participate in conferences without intermediate servers? If you are hosting conferences from a central location, you need to determine whether there are remote locations that have a large enough grouping of users that will be attending the same conferences to warrant installation of intermediate services to consolidate conferencing traffic. In this case, you may have a remote office that will have five users that will regularly or predictably be participating in conferences hosted in the central location. To reduce network traffic for this situation, you may consider deploying an MCU to the remote office. In this configuration, remote users connect to the remote office MCU, and then that MCU connects to the central conference, thereby reducing the conference stream to the remote office to a single instance. The advantage of this approach is lower bandwidth utilization to offices that will have conferencing users. The disadvantage of this approach is additional management and hardware for the remote office MCU.

Here a backbone deployment is defined as a deployment where all clients have a low-cost, highbandwidth connection to a centralized network. 13

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

40

To improve the reliability of data conferencing in your organization, install multiple MCUs to accept connections from the same groups of users. Do not place MCUs in a cluster, however, because the Data Conferencing Provider provides automatic failover for the MCUs in the site. Note Exchange Conferencing Server components should not be installed on cluster servers running Windows 2000 Server. Because the Exchange server that hosts conferencing resources must have the Conference Web Access component installed, it cannot be installed in a cluster. Due to MCUs exchanging DCOM calls with a Data Conferencing Provider and running in the same process with the Conference Management Service, make sure that the MCUs in your Windows 2000 site have fast connections to the server with the active Conference Management Service. Do you host many conferences in remote sites? If you have remote sites that host many conferences, consider a multi-site deployment. Do you have multicast connectivity between sites? If your primary use of Exchange Conferencing Server is for inter-site videoconferences, but there is no multicast connectivity between the sites, you should consider a single-site deployment. You will not save bandwidth in a multisite topology, and the single-site deployment offers lower manageability costs. Scalability Considerations Decision Matrix

The flow chart in Figure 7 will help you determine which deployment scenario is appropriate for your organization. In some cases, you may want to choose more than one scenario. Add the appropriate conferencing components as necessary to best serve your conferencing needs.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

41

Figure 7

Determining the appropriate Exchange Conferencing Server deployment

Note The decision matrix shown in Figure 7 does not take into account videoconferencing considerations. It is still valid if the default multicast mode is available for all clients. However, if there are users who cannot join a videoconference using multicast for an H.323 fallback–enabled conference, they will be referred to the closest MCU/H.323 bridge. If the bridge does not have multicast connectivity with the Conference Management Service in the hosting site, the user will fail to connect to the videoconference. Thus, if videoconferencing is important to your organization, you must ensure that either all the clients or all H.323 bridges (running on MCU servers) are capable of communicating with the hosting Conference Management Service servers over multicast. Tracking the Load and Updating the Topology Regardless of the deployment scenario that you choose, you should review the load on your conferencing servers on an ongoing basis. By using the audit log files generated by Conference Management Service to monitor conference participation, you can decide if you need additional conferencing sites or if the conferencing sites need to be located in a different network location. If the audit log files indicate that you have many conference participants from one location, then install an additional conferencing site closer to that location to balance the load across your network.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

42

Additionally, you should use the performance monitor counters on the MCU to decide about adding an MCU to the topology. See “Audit Log Files and Performance Monitor Counters” later in this document for descriptions of the MCU performance monitor counters.

Extending Deployment to Support Video Conferencing Infrastructure Requirements for Multicast Conferencing If you are providing audio/video conferencing functionality, any routers between the client and the conferencing server must be multicast-aware and clients must support multicast (Windows 2000 and Windows XP natively support multicast). IP multicast is an extension of the IP that allows for efficient group communications. In a multicast environment, a conference obtains a class D assigned IP address from the MADCAP server, clients register with the routers via IGMP, and the router forwards the multicast packets only to those clients that have registered. The routers listening for this multicast address propagate the traffic through a spanning tree type algorithm to all other routers that have IGMP registrations for the multicast session from their corresponding subnets. Any time that an IGMP and Request for Comments (RFC) 2236-compliant router receives a multicast packet, the router determines if there are conferencing clients listening for that address on that particular subnet. If there are conferencing clients listening, the packets are delivered to those conferencing clients. If no conferencing clients on that subnet or segment are listening on that address, the router does not forward the packets to the specific subnet. Note This paper does not address IGMP and RFC 2236-compliant routers. For additional information about these routers, see either the Microsoft Windows 2000 Server Resource Kit or documentation provided by the router manufacturer. H.323 Fallback Often remote conferencing clients do not have multicast connectivity. To work around this issue, conferencing clients without multicast connectivity can connect across an H.323 bridge. The fallback to the H.323 bridge happens in one of the following conditions: •

The client computer has Windows NT or a Windows operating system earlier than Windows 2000 (non-multicast enabled).

•

There is no multicast connectivity to the client computer.

The H.323 bridge runs on the T.120 MCU server and permits conferencing clients that are unable to connect directly to multicast conferences to connect through an H.323 unicast session and participate in video and audio conferences. For the H.323 fallback to occur, the conference must have both data and video providers and H.323 fallback enabled on the conferencing resource.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

43

H.323 conferencing clients connect directly to the H.323 bridge server (the H.323 client is referred to the same server where he or she joins T.120 data session), which sends the H.323 audio/video data to all of the other participating conferencing clients. In this configuration, there must be multicast connectivity between the video conferencing provider and the H.323 bridge. When a non-multicast capable client, or a client that does not have IP multicast connectivity to the Conference Management Service, wants to participate in a multicast conference, the client calls the H.323 bridge with a conference ID provided by the T.120 call. The H.323 bridge, on behalf of the H.323 client, verifies that it has multicast connectivity to the hosting Conference Management Service server, joins the multicast group defining the conference, obtains the media streams, mixes the audio, switches video, and sends the output to the H.323 client. On the other side, the bridge relays the H.323 client’s media to the multicast host group, thereby allowing other multicast clients in the conference to see the H.323 client. To improve scalability, you should consider installing more than one MCU/H.323 bridge on the portion of your network where you have many simultaneous users. The MCUs in this area may have the same scope mask restricting client access to the specific subnets, or none at all, because the site’s Conference Management Service automatically balances the load among the MCUs. To bridge video conferences, all MCUs that accept H.323 client connections must have multicast connectivity to the Conference Management Service on the server that is hosting the conference. Note Videoconferencing requires higher bandwidth than data conferencing for usable voice and video. For this reason, some connection modes such as dial-up or low bandwidth digital subscriber line (DSL) may not support high quality audio and video capabilities. Advantages •

A corporation is rarely a single multicast island; thus, H.323 becomes crucial for connecting the multicast-incapable client to the multicast conference.

•

Routers do not have to be multicast–enabled.

•

Client computers do not need to be multicast–capable. Thus, nonWindows 2000 or Windows XP clients can connect to multicast conferences.

•

H.323 serves as a backup method for conferencing when the multicast infrastructure is temporarily down.

Limitations •

Network routers must be multicast-enabled between the Conference Management Service and all H.323 bridges that are expected to join the conference.

•

Only NetMeeting H.323 clients are supported.

•

Only data and video conferences support H.323 fallback. Video-only conferences can only have multicast participants.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

44

•

A single H.323 bridge server cannot scale much beyond a few dozen H.323 attendees. For example, a 450-MHz server with 256 MB of RAM can support approximately 40 H.323 clients spread out in several conferences on one server.

•

Participants only see the video of the active talker. The active talker in a conference is the person who has most recently sent audio. Ideally, the active talker should be visible when he or she starts talking. However, the Active Talker algorithm can take up to seven seconds to switch the video to the current speaker. Thus, participants might not see the appropriate video and do not see the videos of the other participants.

•

GSM6.10 audio CODEC is not available with H.323–enabled conferences. Note

Multi-site deployments create multicast islands.

Videoconferences and Security

Exchange Conferencing Server multicast videoconferences are not encrypted by default. However, beginning with Exchange Conferencing Server SP2, you can enable encryption of audio and video streams in a conferencing resource’s video provider properties. This setting requires that all the client computers in the conference have the Windows XP operating system because earlier Windows versions do not support this kind of encryption and will not be allowed into an encrypted videoconference. Even though audio and video conferences can be encrypted, the conferences should also be secured by configuring Conference Web Access to communicate over SSL. Conferencing resource’s video provider properties also have the setting that enables sending audio and/or video of the participant automatically when the person joins a conference. Even when the settings are disabled, there is a remote possibility that an experienced hacker could exploit this feature to obtain users’ audio and/or video streams without their knowledge. To minimize this threat, beginning with Exchange Conferencing Server SP3, you can disable the automatic sending of audio/video streams from a client computer by editing clients’ registries and setting the following key: Location: HKCU\Software\Microsoft\Exchange Video Conferencing Registry Key: SendAudio Type=DWORD Value= 0 Registry Key: SendVideo Type= DWORD Value= 0 Caution Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

45

These settings do not affect H.323 conferences. Sending audio and video streams automatically when the participant joins a conference is determined by NetMeeting client settings.

Maintaining Your Exchange Conferencing Server Deployment Maintenance Procedures Cleaning Your Conferencing Calendar The conferencing calendar should be cleaned on a periodic basis. This cleaning reduces the time that it takes to query the conference calendar, although there has to be a very large number of conference calendar items (around 50,000) to affect the response time noticeably. To prevent the possible slow down, clean the conference calendar by using the Outlook auto-archive feature on a regular basis. The frequency for archiving will vary on calendar usage, but a good practice is to clean/archive the conference calendar when you have about 25,000—30,000 items in the calendar mailbox. Shutting Down and Restarting T.120 MCU Servers It is sometimes necessary to shut down for maintenance or reboot the Exchange Conferencing Server servers. Before shutting down or rebooting T.120 MCU servers, disable the MCU for user connections from the MCU property page, and watch the performance monitor Active Connections counter to determine whether any clients are still connected to the MCU. Recycle when no active connections are reported by the Performance Monitor.

Tuning Up Exchange Conferencing Server Performance T.120 MCU Performance The T.120 MCU is the central point of data conferences that relays data between multiple conference clients and other MCUs. The MCU functions in a multi-unicast mode by establishing dedicated Transmission Control Protocol (TCP) connections with each client and MCU in the conference and by sending a separate copy of conference data to each recipient. MCU is a crucial component for overall data conference performance, but the clients connected to the conference often affect the data delivery latencies and overall conference experience. Slow clients, such as dial-up clients or clients with slow CPUs, may cause an MCU to spend more time waiting for the client response, which negatively affects the delivery of the data to other conference clients. To moderate a slow or improperly functioning client’s influence on the conference, Exchange Conferencing Server SP3 has added the capability to disconnect slow or dysfunctional clients from the conference after waiting for a preset timeout for data packets waiting in the recipient queue. To modify the timeout for disconnecting clients from a conference

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

46

•

You can modify the timeout for T.120 data packets on an MCU recipient queue before MCU disconnects a client from the conference. The registry setting is a DWORD value for the following key: Location: Local Machine\SOFTWARE\Microsoft\Exchange\Conferencing\Parameters\ Registry Key: SecsUntilKickSlowClient Type: DWORD Caution Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

The default is 70 seconds. If the client is disconnected, the following event is logged in the Application Event Log: Event ID: 12295 Event log: Client was removed from the conference in order to prevent it from slowing the conference for all participants. This may happen occasionally if, for example, the client transfers too large a file, pastes too much data to a whiteboard session, or shares an application that updates the screen too often. This may happen repeatedly if the client computer has too little available memory, too slow a processor, or too slow a connection to the conferencing server. Conference List Performance Exchange Conferencing Server SP3 introduces performance improvements for viewing the Web site with the list of conferences. At the same time, SP3 enables administrators to limit the maximum duration for which users may get the list of scheduled conferences on an Exchange Conferencing Server site. This limitation protects against accidental, large queries that could potentially introduce significant delays in servicing this and other requests in the conferencing site. The optimal values for the default (the query that is returned when a user first navigates to the list site) and maximum duration for the list queries may be different for different sites and may depend on the number of conferences returned in the query. You can adjust these values by editing the registry on the Conference Management Service servers. To change the default and maximum duration for list queries

•

The default list duration is determined by the following registry value:

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

47

Location: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange Conferencing\Parameters Registry Key: List Default Duration Hours Type: REG_DWORD Value: 1 to 2016 (or List Maximum Duration Hours whichever is lower). Registry Key: List Maximum Duration Hours Type: REG_DWORD Value: 1 to 2016 Caution Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data. If either of these values is not set, the default value for List Default Duration Hours is 24 (one day), and it is 336 (two weeks) for List Maximum Duration Hours. List Default Duration Hours cannot be set higher than List Maximum Duration Hours. For example, if you set List Maximum Duration Hours to 168 hours (one week), you cannot set List Default Duration Hours to anything greater than 168. (You can set the value in the registry, but the value in List Maximum Duration Hours supercedes it.) These two values can be equal. This would result in the default list duration also being the maximum duration allowed for queries.

Audit Log Files and Performance Monitor Counters You can examine the Exchange Conferencing Server audit and application logs and Performance Monitor counters to assess the health of your Exchange Conferencing deployment and to provide early detection mechanisms for potential problems. Audit Log Files The audit log files are text files that Conference Management Service and Data Conferencing Provider use for logging all conferencing events. You can use Conference Management Service and Data Conferencing Provider property pages to enable/disable logging for specific events. Figure 8 shows the Conference Management Service and Data Conferencing Provider audit logging property tabs with the list of audit events. The illustrations also indicate the events logged by default.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

48

Figure 8 Logging tabs of Conferencing Site and Data Conferencing Provider property sheets The information in the audit log files is formatted as comma-separated values that can be easily imported into a database or a spreadsheet. Use the audit log data to collect and analyze data on various aspects of your Exchange Conferencing Server deployment. For example, you can determine: •

Who, when, and from which location conferences in each site are scheduled and attended.

•

What kind of conferences are scheduled.

•

How many conferences have been scheduled.

•

Which resources have been reserved.

•

How many attendees participated in any conference, or in all conferences at any point in time.

•

The reason for failure, when scheduling or joining a conference fails.

For more information about the audit log events and file format, see Exchange Conferencing Server online help. Setting the “Log Subject” and “Audit Log Files Lifetime”

Exchange Conferencing Server uses the Exchange 2000 Server settings “Log Subject” and “Audit Log Files Lifetime” to decide whether to include conference subjects in the audit log event formats and to determine when to delete old log files. However, these settings only affect Exchange Conferencing Server default behavior (not logging subject and keeping files indefinitely) if Exchange 2000 Server and Conference Management Service are on the same computer.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

49

Performance Monitor Counters Various performance monitor counters (PMC) are provided for Conference Management Service, Data Conferencing Provider, Video Conferencing Provider, and T.120 MCU services. PMCs allow the tracking of various measures of system performance in real time. Use the PMCs, which have a higher granularity than the audit logs, for measuring various service performance characteristics for specific periods of time. Also, you can track the system health and current server loads in your deployment. This data can give you early warning of reaching service capacity and the need to add servers to your topology. It can also provide diagnostic data for problems that you observe and generally help you tune up the Exchange Conferencing Server deployment and configuration. Tables 5 through 9 describe Exchange Conferencing Server PMCs per component. Conference Management Service Counters The following table defines the counters associated with Conference Management Service. Table 5

Counters associated with Conference Management Service

Counter

Description

Active Conferences

The current number of conferences in progress in the site.

Conference Profiles

The number of scheduled conferences in the conference profile store.

Conferences Deleted

The number of scheduled conferences deleted since the Conference Management Service started.

Conferences Scheduled

The number of conferences scheduled since the Conference Management Service started.

Join Requests

The number of requests to join a conference received since the Conference Management Service started.

Join Requests/sec

The number of requests to join a conference received per second.

List cache hit

The number of schedule queries satisfied by the cached result of a previous query, since Conference Management Service started.

List cache missed

The number of schedule queries not satisfied by the cached result of a previous query, since Conference Management Service started.

List cache invalidated

The number of times since Conference Management Service started that it invalidated the cached result of a conference schedule query.

Bucket <X.> hit

The number of schedule queries satisfied by this (X) cached view on the Exchange Server, since Conference Management Service started.

Data Conferencing Service Counters Table 6 defines the counters associated with Data Conferencing Service.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

50

Table 6

Counters associated with Data Conferencing Service

Counter

Description

Active MCUs

The number of T.120 MCU servers available to participate in conferences in the site. (This is a measure of the site's capacity for handling conferences.)

Average Conferences per Active MCU

The average whole number of active conferences hosted by each active T.120 MCU server in the site.

Average Load per MCU

The average load per T.120 MCU server. This is calculated as the percentage of time that a server's CPU spends processing MCU threads relative to the time the CPU spends processing MCU and idle threads. This number is a measure of the amount of processor time used by the average T.120 MCU server in this site. If this counter is consistently high (above 75 percent), consider adding an MCU to help balance the load.

DCOM Calls to MCUs

The number of DCOM calls made to T.120 MCU servers by the conference technology controller since the service started. This number is a measure of communication overhead, which is influenced by different events (for example, the addition and removal of MCUs, invitations to a conference, and users joining or leaving a conference). The value of this counter is also influenced by the number of active conferences in the site.

Disabled MCUs

The number of T.120 MCUs not accepting new client connections in this site.

Local Conferences

The number of local conferences in progress in this site.

Local Referrals

The number of times that local users requested a connection to a remote conference since the service started.

MCU DCOM Conference Callbacks

The number of DCOM calls related to conference activity received by the conference technology controller from T.120 MCU servers since the service started. This number is a measure of the variable portion of communication overhead, which is influenced by different events (for example, the addition and removal of MCUs, invitations to a conference, and users joining or leaving a conference). The value of this counter is also influenced by the number of active conferences in the site.

MCU DCOM Load Updates The number of connection-status DCOM calls not related to conference activity that have been received by the conference technology controller from T.120 MCU servers since the service started. This number is a measure of the fixed portion of communication overhead. Remote Conferences

The number of remote conferences in which local T.120 MCU servers are participating. A large number indicates a high level of conference traffic between sites.

Remote Referrals

The number of times that a remote client requested a connection to a local conference since the service started.

Successful User Joins

The number of times that users successfully joined a conference in the site since the service started.

Unavailable MCUs

The number of stopped or failing T.120 MCU servers in the site.

User Join Attempts

The number of times that users tried to join a conference in the site since the service started.

T.120 MCU Server Counters Table 7 defines the counters associated with T.120 MCU servers.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

51

Table 7

Counters associated with T.120 MCU servers

Counter

Description

Active Connections

The number of clients connected to this T.120 MCU server.

Bytes Received/Sec

The number of bytes per second received by this T.120 MCU server.

Bytes Sent/Sec

The number of bytes per second sent by this T.120 MCU server.

Data Messages Received

The number of Multipoint Communication Service (MCS) data messages received from other T.120 MCU servers since the service started. MCS Data messages carry user-initiated information (for example, chat messages and pointer movements, or text on a whiteboard). This number should increase over the duration of an active conference.

Data Messages Sent

The number of MCS data messages sent to other T.120 MCU servers since the service started. MCS data messages carry user-initiated information (for example, chat messages and pointer movements, or text on a whiteboard). This number should increase over the duration of an active conference.

Hosted Conferences

The number of active (joinable) conferences in which this T.120 MCU server is participating as a top level MCU server.

Kbytes Received

The number of kilobytes received by this T.120 MCU server since the service started. If the server is participating in active conferences, this number should increase over time.

Kbytes Sent

The number of kilobytes sent by this T.120 MCU server since the service started. If the server is participating in active conferences, this number should increase over time.

Management Messages Received

The number of MCS management messages received from other T.120 MCU servers since the service started. MCS management messages carry information related to conference control (for example, invitations, joins, and connection requests).

Management Messages Sent

The number of MCS management messages sent to other T.120 MCU servers since the service started. MCS management messages carry information related to conference control (for example, invitations, joins, and connection requests).

Non-hosted Conferences

The number of active (joinable) conferences in which this T.120 MCU server is participating as an intermediate MCU server.

T.120 MCU Load

The percentage of time that the server's CPU spends processing MCU threads relative to the time that the CPU spends processing MCU and idle threads. This number indicates how much processor time is being used by the T.120 MCU server. To reduce the load you can upgrade the server hardware or add another T.120 MCU server to the site. If the server is running other applications that require significant processor time, consider moving those applications to another server.

Video Conferencing Service Counters Table 8 defines the counters associated with Video Conferencing Service. Table 8

Counters associated with Video Conferencing Service

Counter Failed User Joins Attempts

Description The number of times that users could not successfully join video conferences in the site since the service started.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

52

Counter

Description

Total User Joins Attempts The number of times that users attempted to join video conferences in the site since the service started. Video Conferences in Progress

The number of video conferences in progress in this site since the service started.

H.323 Conferencing Bridge Service Counters Table 9 defines the counters associated with H.323 Conferencing Bridge Service. Table 9

Counters associated with H.323 Conferencing Bridge Service

Counter

Description

Bridged Calls

The number of currently bridged H.323/multicast calls.

Incomplete Calls

The number of H.323 calls that could not be bridged since the service was last started.

For more information about PMCs, see Exchange Conferencing Server online help.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

53

Additional Resources For more information about Exchange 2000 Conferencing Server, please see http://www.microsoft.com/exchange/techinfo/conferencing/default.asp For more information about Exchange 2000 Conferencing Server SP3, please see http://www.microsoft.com/exchange/downloads/2000/sp3/default.asp For more information about how to deploy Exchange Conferencing Server in a mixed Exchange 5.5 and Exchange 2000 environment, please see http://www.microsoft.com/exchange/techinfo/deployment/2000/ECSmixed.asp. For more information about how to configure Active Directory segments separated by firewalls, please see http://www.microsoft.com/windows2000/docs/adsegmented.doc For more information about Exchange 2000 Server, please see http://www.microsoft.com/exchange

Did this paper help you? Please give us your feedback. On a scale of 1 (poor) to 5 (excellent), how would you rate this paper? mailto:[email protected]?subject=Feedback: Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server









Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

54

Appendix Sample Perimeter Network Configuration Please refer to the Internet deployment topology in Figure A.1 for the following example.

Figure A.1

Perimeter network deployment scenario

Example Perimeter Network Scenario For the purposes of this example, we have two perimeter networks. Each has a slightly different function and has a different level of trust. At each layer, a logical list of access controls is applied to traffic. The objective is to show in general terms how a conferencing solution can be configured to host conferences across an untrusted network. It is not the objective of this discussion to provide vendor– specific configurations. The Internet is network space that is outside an organization’s control and therefore is completely untrusted. The router controls traffic flow from this network to the next layer of our network. It employs simple packet filtering to provide some

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

55

level of protection against lower-level attacks, but does not provide real, finegrained controls that would absorb lots of CPU time. So, access lists at this layer are simple: Block incoming traffic with inappropriate source or destination IPs, and block traffic to service ports that are not being offered to Internet users. The purpose of the perimeter network is to allow external users to interact with the perimeter network services and additional services that we want to provide to them. The use of a full proxy server enables us to offer access to those additional services while disabling access to any other service or port that is not necessary. The proxy provides full connection isolation and control over service availability. The perimeter network is a more trusted network than the Internet because some screening has taken place at the router. However, it is still not a fully controlled environment, so we do not trust any of the traffic in it. The Application Vault (Vault) is a more trusted network than the perimeter network. It is where most of the servers providing the services are located. Traffic in this network has been subjected to some screening, either when coming from the corporate network or filtered through the proxy. As a result, we can offer services to this network that would not be prudent to offer to either of the previous networks. In this network we have installed a completely separate Active Directory forest to support our servers and services. This forest trusts, but is not trusted by, our internal Active Directory forest(s). This is done so that internal user information can be replicated to the Vault’s forest. That way internal users can use the same credentials to log on to Vault resources. Without the trust, each conferencing user would need to have and maintain two separate sets of credentials. The existence of this trust requires the use of RPC services and ports. In order to create and verify this trust or to replicate user information, some User Datagram Protocol (UDP) ports are also used. Neither of these protocols is particularly firewall-friendly, so to provide this service level without compromising our corporate network, we have a stateful packet-filtering firewall between our Vault and our corporate network. We found that a packet-filtering RPC was much easier to use than a proxy server. Finally, our corporate network enjoys the highest level of trust where users and servers are fully exposed. All internal user accounts reside on the corporate network, as does the internal Active Directory forest. This network should not trust the forest in the Vault network. Router, Firewall, and Proxy Configuration The networks in the preceding scenario have the following address spaces: Internet – * DMZ – 192.168.3.0/24 Proxy’s public IP 192.168.3.251 ConfWebPage Proxy’s public IP 192.168.3.252 ConfMCU Proxy’s public IP 192.168.3.251 MailHost Vault – 192.168.2.0/24 Vault_DC_DNS IP 192.168.2.2

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

56

Vault_Exchange_Server IP 192.168.2.3 Vault_ECS_CWA IP 192.168.2.4 Vault_ECS_MCU IP 192.168.2.5 Corporate Network – 192.168.1.0/24 Corp_DC_DNS IP 192.168.1.2 Corp_Exchange_Server IP 192.168.1.3 Router Access Control List any:t established -- > 192.168.3/24 any < -- 192.168.3/24:u53 any:u53 --> 192.168.3/24 any < -- 192.168.3/24:t25 any < -- 192.168.3/24:t80 any < -- 192.168.3/24:t443

any -- > 192.168.3.251:t25 any -- > 192.168.3.251:t443 any -- > 192.168.3.252:t443 We start the configuration by allowing previously established sessions to enter the network. Then we allow TCP 443 in to our Conference Web Access or MCU. Lastly, we allow for outgoing Web, DNS, and SMTP traffic. Proxy Publishing Rules Here the proxy is used to make a service available that is running in our Vault. Users located outside the corporate network make their connection to the proxy, which then relays that client connection and data to a specific server in the Vault. Reply data is also sent back through the proxy. 192.168.3.251:T25 <--> 192.168.2.3:T25 192.168.3.251:T443< -- >192.168.2.4:T443 192.168.3.252:T443< -- >192.168.2.5:T443 any:t443 < -- 192.168.* any:t80 < -- 192.168.* any:u53 < -- 192.168.* any:t25 < -- 192.168.[1..2].2 Firewall Forwarding Rules

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

57

These rules allow name resolution, and let the Vault forest establish and maintain the one-way trust it has with the corporate network forest. These rules are configured in a point-to-point manner to decrease risk of unauthorized access to the network. The firewall forwarding rules also allow for traffic returning from the corporate network. any --> 192.168.1/24:t established any:u53 --> 192.168.1/24 192.168.2.2 --> 192.168.1.2:u53 192.168.2.2 --> 192.168.1.2:t25 192.168.2.2 --> 192.168.1.2:t88 192.168.2.2 --> 192.168.1.2:u88 192.168.2.2 --> 192.168.1.2:t389 192.168.2.2 --> 192.168.1.2:u389 192.168.2.2 --> 192.168.1.2:t445 192.168.2.2 --> 192.168.1.2:u445 192.168.2.2:u389 --> 192.168.1.2 192.168.2.2:u88 --> 192.168.1.2

Lastly, we need to allow for traffic on certain ports from the corporate network to the Vault so that user information can be replicated into the Vault forest. We also need to allow for normal Internet traffic flow. 192.168.1/24 --> any:t established 192.168.1/24 --> any:u53 192.168.1/24 --> any:t25 192.168.1/24 --> any:t80 192.168.1/24 --> any:t443 192.168.1.2:u53 --> 192.168.2.2 192.168.1.2:u389 --> 192.168.2.2 192.168.1.2:u445  192.168.2.2 192.168.1.2:u88 --> 192.168.2.2 192.168.1.2 --> 192.168.2.2:u389 192.168.1.2 --> 192.168.2.2:t389 192.168.1/24 --> 192.168.2.2:t3268

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

58

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred. 2003 Microsoft Corporation. All rights reserved. Microsoft, ActiveX, Active Directory, NetMeeting, Outlook, PowerPoint, Windows, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Deploying and Maintaining Microsoft Exchange 2000 Conferencing Server

59