UM Auto Attendants | Planning for Unified Messaging

Using a UM auto attendant, you can create a voice-menu system that enables your callers to navigate through voice menus to locate or transfer calls to your UM-enabled users or departments. You can create and use your own voice prompts so that you're able to fully customize the UM auto attendant to your own needs.

The UM auto attendant uses a series of WAV files that callers hear instead of a human operator. The callers can navigate the menu system, place calls, or locate users using DTMF or voice inputs.

Note

You can join auto attendants together to form multi-level menus.

The UM auto attendant allows you to provide the following:

• Corporate or informational greetings, such as business hours or directions to a location
• Custom corporate menus that you can customize to have more than one level
• A directory search function that enables callers to search the organization's name directory
• The ability for callers to connect to the telephone of—or leave a message for—UM-enabled mailboxes

You are not limited in the number of UM auto attendants you can create, and each auto attendant can support an unlimited number of extensions. However, you should design menu systems for auto attendants carefully to ensure that the user has a positive experience. If you design them incorrectly, users can become very frustrated if the time it takes to connect correctly is lengthy or navigating the system is difficult. You should especially consider creating additional UM auto attendants if you are operating in a multi-language environment so that you can provide a dial-in number for each language.

When you create a UM auto attendant, you must provide the associated UM dial plan and extension number(s) to access the UM auto attendant. After creating the UM auto attendant, you can configure alternative greetings by specifying the WAV files to use. You also can configure different settings for work and non-work hours and features such as call transferring. You can create auto attendants in the EMC or by using the New-UMAutoAttendant cmdlet in the EMS.

UM Hunt Groups | Planning for Unified Messaging

A UM hunt group is a logical representation of an existing PBX or IP PBX hunt group. When the hunt group's pilot number receives a call, the PBX or IP PBX looks for the next available extension number to deliver the call. When the call's recipient does not answer an incoming call, or the line is busy because the recipient is on another call, the PBX or IP PBX routes the call to the UM server.

UM hunt groups act as a link between UM IP gateways and UM dial plans. Therefore, you must associate a UM hunt group with at least one UM IP gateway and one UM dial plan. UM hunt groups locate the PBX hunt group from which the incoming call was received. A pilot number that is specified for a hunt group in the PBX also must be specified within the UM hunt group. The pilot number enables the UM server to associate the call with the correct UM dial plan so that it can route the call correctly.

When you create a new UM hunt group, you enable UM servers in the specific UM dial plan to communicate with the UM IP gateway. You need to specify the UM dial plan and the pilot identifier or pilot number that you want it to use with the new UM hunt group.

Note

You can create UM hunt groups only if you have already created a UM IP gateway.

UM IP Gateways | Planning for Unified Messaging

A UM IP gateway is a logical representation of a physical IP gateway hardware device that translates between the circuit-switched telephone network and an IP or packet-switched network. This represents either a VoIP gateway or an IP PBX.

The UM IP gateway contains one or more UM hunt groups and other UM IP gateway-configuration settings, including the actual IP gateway. The combination of the IP gateway object and a UM hunt group establishes a logical link between an IP gateway hardware device and a UM dial plan.

Note

Before an IP gateway can process calls, a UM IP gateway must be associated with at least one UM dial plan.

You can create a UM IP gateway using the Exchange Management Shell (EMS) or Exchange Management Console (EMC). When you create a new UM IP gateway, you enable UM servers to connect to the VoIP gateway or IP PBX. However, you can enable or disable the UM IP gateway. You can disable a UM IP gateway in two different modes:

• Disable After Completing Calls Forces UM servers associated with this UM IP gateway to stop handling any new calls.
• Disable Immediately Forces all associated UM servers to drop existing calls for this UM IP gateway.

UM Dial Plans | Planning for Unified Messaging

The UM dial plan is the basic Unified Messaging administrative unit and used for telephony extension-numbering. 

The UM dial plan, plus the extension number, provides the unique identifier for each UM-enabled user. The UM dial plan also controls the numbering scheme and the outbound dialing plan.

The UM dial plan is an Active Directory container object that is a logical representation of a Telephony dial plan that you configure on a PBX. The UM dial plan establishes a link from an Exchange Server 2010 recipient's telephone extension number in Active Directory to a UM-enabled mailbox.

Before you can use Unified Messaging, your Exchange environment requires at least one UM dial plan to be created, assigned to a UM server, and associated with a UM IP gateway.

When you configure UM dial plan settings, you have to define at least the extension length. Additionally, you can configure other UM dial plan settings:

• Access numbers for subscribers (OVA phone number) or your UM -enabled users dial to access their mailbox via a phone.
  
  
• Default greetings that is used when subscribers call into the UM server.
  
  
• Dial codes for dialing external phone numbers and international numbers.
  
  
• Features such as whether subscribers can transfer callers to other users and whom callers can contact.
  
  
• Time limits for calls, messages, and idle timeouts.
  
  
• Default language for OVA and voice prompts.
  
  
• The audio codec format for voice messages, such as MP3.

Important

If you want to upgrade your existing Exchange 2007 UM environment that is connected to OCS, you need to create new UM dial plans for Exchange 2010 UM to make OCS UM-version aware. Until SP1, changing a user's dial plan means de-provisioning and re-provisioning a user from the UM system. SP1 changes that by enabling the Move Request to update the UM dial plan automatically.

Exchange 2010 SP1 will include secondary UM dial plan support, which means that you can assign two UM dial plans to your users, especially those who use two phones connected to different gateways.

Unified Messaging Servers | Planning for Unified Messaging

If you want to plan your Exchange 2010 Unified Messaging implementation, you need to consider two important factors: How many UM servers do you need, and where do you physically place your UM server roles?

Planning Amount and Hardware for UM Servers

Planning for how many Unified Messaging servers you need for your environment is logically the first question that needs to be answered before considering their configuration.

Planning the amount of UM servers depends mainly on the number of concurrent calls to the server as well as how many Voicemail Previews a CPU has to produce. These assumptions are based on an average voice mail of 50k and an average voice mail length of 30 seconds.

You can follow these guidelines for UM server planning:

• From the processor power, assume that one voice mail per core per minute can be produced. The UM role supports up to 12 cores, but because this is based on a reasonable price and performance ratio, it might rise in the future.
  
  
• Each language installed and supported on an UM server adds memory and CPU overhead because it has to rebuild the language library of words every 24 hours.
  
  
• Call answering rules do not have a measurable impact on processor power.
  
  
• Every UM server can support as many as 200 concurrent calls maximum; the default configuration is 100 concurrent calls.
  
  
• If you don't know your average concurrent callers, you can calculate that roughly 1 percent of your users produce concurrent calls at peak times. This means that if you have 5,000 UM-enabled users accessing a single UM server, they produce 50 concurrent calls during peak hours.
  
  
• You should plan to have at least two UM server roles available in your organization to provide failover capabilities.
  
  
• 8 GB memory is the recommended memory configuration for a dedicated UM server. More memory will not provide much benefit, even though UM will utilize it.

At Microsoft, three dedicated, centralized Exchange 2010 UM servers are currently available that host more than 90,000 mailboxes. 

Inside Track—Voicemail Preview and CPU Scalability

Ankur Kothari

Senior Technical Product Manager, Exchange Server, Microsoft Corporation

Scalability of the messaging role is primarily bottlenecked at the CPU. The process of taking an audio stream and determining a best-fit language model for the words spoken is primarily a processor task. We estimate that a single CPU core can handle one voice mail message per minute. An average voice mail message is roughly 25 to 30 seconds, although this can vary by industry or geography. Planning for CPU usage on this role is crucial to providing a consistent end-user experience.

UM Server Placement

If you have a small, single-site implementation of Exchange, you do not give much thought to where you physically place the UM server role. However, if you have a global implementation with several large branch offices located in different countries, you must ask yourself whether you want to place a UM server role close to the branch office's PBX or if you want to place the UM server role in the location where the mailboxes are hosted. The subsequent discussion uses the term PBX, meaning that the PBX can be connected to the UM role or already includes an IP PBX.

Let's use the Litware scenario and assume that you have mailboxes from your branch offices in Brussels and Amsterdam hosted on the Mailbox server in Berlin. You also have local PBXs available in Brussels and Amsterdam. Obviously you can place the UM server close to the PBX or close to the Mailbox server role. The following considerations will help you to make a valid decision for this situation:

• Placing the UM server close to the PBX but far from the Mailbox server improves the voice quality because the PBX to UM role is very close. The UM role might need a short delay to open a mailbox and read the items, but the voice quality when the message is played or sent is excellent. Having centralized UM servers and sending VoIP traffic over an unreliable or high-latency WAN should be considered carefully. A delay in opening messages could be acceptable for your users, but a delay in the voice traffic or bad voice quality is not. On the other hand, having the UM server close to the PBX but far from the Mailbox server also means that retrieving and playing personal greetings may not work well. Because the event of "leaving a voice mail" is more of a one-way conversation from the caller to the UM server, best practice is having the UM server near the Mailbox server.
  
  
• Placing the UM server close to the Mailbox role, but distant from the PBX might cause voice issues if you do not have a Quality of Service (QoS) network that prioritizes VoIP traffic over your WAN:
  • If you can guarantee or have sufficient network bandwidth available, it is best practice to place the server close to the Mailbox server role.
  • If you cannot guarantee network quality between the PBX and UM server role, your users might not be able to understand voice messages because of network latency or outages, which might cause user confusion.
    
    
• Security is another aspect worth considering. Most of the time voice mails are private, and it is sometimes difficult or even unsupported on a lot of PBXs to have the RTP protocol stream secured. This might be an easy target for eavesdropping.
  
  
• You can also consider adding a multi-role server to the site where the PBX is located, including the Mailbox, Client Access, Hub Transport, and UM roles to make sure all traffic is local and users get the best voice quality possible. However, carefully consider other implications, such as Domain Controller requirements, that you need to satisfy before installing a multi-role Exchange server onsite.

Note

The Microsoft recommended best practice is to place the UM server close to the Mailbox, Hub Transport, and Client Access servers. An IP PBX/IP gateway roundtrip needs to be less than 300 ms, which is higher latency than the RPC traffic between Exchange servers can tolerate and still perform well.

Exchange Unified Messaging Architecture

The Unified Messaging server role includes connections to different components, such as the Client Access or Mailbox server roles, and also to IP PBX or IP gateways, as shown in Figure 1.

 

Figure 1: Unified Messaging architecture

Generally, the UM server role communicates to an IP PBX or to a PBX using an IP gateway with the Voice over IP protocols (VoIP), Session Initiation Protocol (SIP), and Real-time Transport Protocol (RTP).

The UM server role uses MAPI protocol to communicate with Client Access and Mailbox server roles, and SMTP protocol to send voice mail messages to the destination mailbox viathe Hub Transport server. For Outlook Voice Access the UM server role accesses the mailbox using MAPI protocol to have full access to all items in the mailbox such as messages or contacts.

The Unified Messaging role no longer supports an inbound fax like Exchange 2007 UM. However, UM retains fax configuration properties, and continues to be sensitive to fax tones on calls that it answers and forwards these calls to a partner fax solution. The received fax messages look essentially the same as those created by Exchange 2007 UM, and will appear as a fax when the user is UM-enabled.

The communication to the other Exchange roles—namely the Hub Transport, the Mailbox, and Client Access Server roles—uses MAPI connections to perform tasks such as opening a mailbox for OVA or sending a voice mail message when the call has ended.

The Basics of Telephony

Because Unified Messaging must be integrated into your company's telephony solution, it's important to understand the most crucial terms and definitions to be able to follow.

Note

If your company is already connected to Office Communications Server 2007 or later with your telephone system, you don't need to consider the details in the following sections; Exchange 2010 will use OCS as the gateway.

Types of Telephone Systems

Three general types of business telephone systems can be integrated with Unified Messaging:

• Centrex Phone System Phone companies lease a Centrex phone system (also known as Central Office Telephone Exchange) to businesses. The Centrex phone system uses the phone company's central office (CO) exchange to route internal calls to an extension. A new Centrex version called IP Centrex is available. With IP Centrex, the organization does not rent phone lines from the telephone company's CO. Instead, the CO sends the phone calls through a VoIP gateway, which routes them over a VoIP gateway or through the Internet. At the organization's office, another VoIP gateway translates the call to a traditional circuit-switched call.
  
  
• Key Telephone System This phone system is similar to the Centrex system in that the organization leases several phone lines from the telephone company. However, with the Key Telephone System, each phone line connects to multiple telephones in the organization. When someone calls the company, all phones ring that are associated with that line. Businesses with Key Telephone Systems often arrange for someone to answer incoming calls, and then announce the call to the correct recipient.

  Note

  Some key telephone systems can work with UM if an IP gateway is added. However, some less sophisticated systems may not work even if a supported IP gateway is used. Make sure you contact your vendor before you try to use your key telephone system with Exchange 2010.

• Private Branch Exchange System A Private Branch Exchange (PBX) system is different from the other telephone systems in that it typically has only a single connection to the phone company and all call switching happens at the organization. The connection to the phone company usually occurs through a T1 or E1 line, both of which provide multiple channels to enable multiple calls over the same line, also called trunk lines. The PBX routes internal phone calls and those between external and internal users. In a PBX system, each user has a telephone extension. When an internal user places a call to another internal user, she uses only the extension number, and the PBX routes the call to the appropriate extension.

Types of PBX

PBX systems are the most common telephone system type that medium- and large-size organizations use. Several types of PBX systems are available:

• Analog PBX Analog PBX systems send voice and signaling information, such as the touch tones of dialed phone numbers, as actual analog sound. Analog PBX systems never digitize the sound. To direct the call, the PBX and the phone company's CO listens for the signaling information.
  
  
• Digital PBX Digital PBXs encode analog sound into a digital format. They typically encode the voice using a standard industry audio codec, G.711. After digital PBXs encode the sound, they send the digitized voice on a channel using circuit switching. The process of circuit switching establishes an end-to-end open connection, and leaves the channel open for the call's duration and for the call's users only. Some PBX manufacturers have proprietary signaling methods for call setup, such as Avaya Definity G3si PBX.
  
  
• IP PBX IP PBXs include a Network Interface Card (NIC) to provide voice over regular network. The phone converts voice into digitized packets, which it then transfers over the network. The network sends the voice packets via packet switching, a technique that enables a single network channel to handle multiple calls. The IP PBX also acts as a gateway between the internal packet-switched network and the external circuit-switched networks that phone company's use. In this situation, external phone calls arrive at the IP PBX on the normal public phone lines, and the IP PBX converts the phone call to packets sent on the internal IP-based network. An example of this is Cisco Call Manager.
  
  
• Hybrid PBX Hybrid PBXs provide both digital and IP PBX capabilities. This hybrid approach enables a customer to run a mixture of digital and IP-based phones. Most modern PBXs are in this hybrid category, such as SEN HiPath 4000.

VoIP Gateway Introduction

A VoIP gateway is a third-party hardware device or product that converts traditional phone-system or circuit-switching protocols into data-networking or packet-switched protocols. The VoIP gateway connects a telephone network with a data network.

Unified Messaging servers can connect only to packet-switched data networks. This means that organizations with a traditional PBX must deploy a VoIP gateway to communicate between the PBX and the Unified Messaging server.

Unified Messaging Protocols

There are a number of voice-related, IP-based protocols. A Unified Messaging environment with Exchange Server 2010 uses the following:

• Session Initiation Protocol (SIP) SIP is a real-time signaling protocol that creates, manipulates, and disconnects interactive communication sessions on an IP network. The UM role uses SIP mapped over Transmission Control Protocol (TCP) and supports TLS for secured SIP environments. SIP clients, such as IP/VoIP gateways and IP/PBXs, can use TCP port 5060 or port 5061 (for Secure SIP) to connect to UM server roles. You can find more information about the SIP protocol at http://tools.ietf.org/html/rfc3261.
  
  
• Real-time Transport Protocol (RTP ) RTP is for voice transport between the IP gateway and the Unified Messaging server. RTP provides high-quality, real-time, streaming voice delivery. One of the issues with sending voice messages over an IP network is that voice requires real-time transport with specific quality requirements to ensure that the voice sounds normal. If the protocol uses large packets, listeners must wait for the entire packet to arrive before they can respond. Any delay in packet delivery can produce undesirable periods of midstream silence. Packet loss can cause voice garbling. You can get more information about the RTP protocol at http://tools.ietf.org/html/rfc3550.

LDDS WorldCom | Vendor Implementations

The ubiquity and user-friendliness of the World Wide Web is prompting long distance carriers to reevaluate how they give users a view into their networks. Traditionally, obtaining network-performance data has been more difficult and more expensive than most customers are willing to buy into. Moving this function to the Web facilitates the acquisition of real-time performance data using the familiar browser interface. Not only are more network management tools being equipped with hooks into the World Wide Web, but some expensive management platforms are being discontinued because they do not compete well against Web-based tools that do. Among the long distance carriers that offer Web-based management tools is LDDS WorldCom.

LDDS WorldCom, the fourth largest long distance carrier in the United States, offers its customers a Web-based Network Management System (Fig. 1) that is accessed through a client equipped with a standard Web browser. With the browser, users can monitor the performance of their data and voice WANs. The system gives network administrators their choice of hour-by-hour and day-by-day statistics on frame relay, dedicated access, and toll-free circuits. For example, on a near real-time basis, frame relay users can see hourly and daily reports on the percentage of frames marked discard-eligible due to bursting above the committed information rate (CIR). Users can also compare CIRs to actual traffic load to help determine when port expansion is necessary.

Figure 1: Architecture of the LDDS WorldCom Web-based management capability, which gives users reports on their portion of the network.

The reporting service makes it simpler for managers and administrators to get into the network to obtain performance-related information, without requiring them to buy additional hardware and software compatible with their provider's network monitoring capabilities. Customers can use Web NMS to obtain usage statistics, such as: originating number, number of no-answers, and average call duration for customer toll-free numbers; trunk group activity levels on dedicated access lines; and port/PVC usage on frame relay service. In near-real time, Frame Relay customers can use Web NMS to:

§  Open a window into the network when considering a change or upgrade to their existing frame relay facilities

§  Track how much of their traffic is "bursting" above the committed information rate (CIR) to discard-eligible status

With regard to toll-free 800 or 888 numbers, the Web NMS toll-free application enables call center managers to do such things as determine on an hourly basis how many calls are being answered or dropped in queue for each telephone number. In near-real time, toll-free customers can use Web NMS to:

§  Monitor usage volumes on individual facilities to best distribute calls among multiple answering locations

§  Ensure that all calls are getting through

§  Adjust staffing based on traffic load reports

§  Track response to specific toll-free numbers used in advertising campaigns and on product packaging

In near-real time, Dedicated Access Line (DAL) customers can use Web NMS to:

§  View trunk group activity levels reports

§  Based on trunk group reports, use conventional means to best allocate available bandwidth between multiple services—for example, between outbound and inbound trunk groups

§  Based on trunk group reports, use spare capacity for point-to-point data services

To use the Web NMS, users actually go into WorldCom's password-protected corporate intranet. An additional level of security is provided by partitioning the servers on a customer-by-customer basis. Hyperlinks enable Web NMS users to click on individual physical or virtual circuits, check the traffic load through specific frame relay ports, or switch among hourly, daily, and historical summaries. The Web NMS screens also include online help and customer feedback links.

SNMP Research | Vendor Implementations

SNMP Research International Inc. offers a unique product that maps HTML constructs and SNMP data, supporting a standards-based transition to Web-based management. For management applications, DR-Web reduces coding effort as well as memory requirements. For developers and end-users, DR-Web preserves investments in SNMP by ensuring consistent data naming with more than 5000 standard MIB objects specified in over 60 RFCs.

The DR-Web Extensible Agent is one of three products in the DR-Web family of Web-based management tools from SNMP Research. The architecture of DR-Web provides operators with easy access to management information from any Web browser while preserving the standards-based format of management data required for programmatic manipulation by software applications. DR-Web's primary differentiator from other Web-based management solutions is the level at which SNMP/Web integration takes place in the agent/management architecture (Fig. 1).

Figure 1: Architecture of DR-Web Extensible Agent.

From any popular browser, operators can request SNMP management information from DR-Web-enabled applications, systems, or devices by making an HTTP request in the form of an Uniform Resource Locator (URL), such as:

http://my.host.machine:280/subtree/

where the host is the host name or address for the computer running DR-Web, and subtree specifies the starting point for browsing the SNMP MIB. Port 280 is the proposed port for Web-based management, pending approval by the IETF.

Upon receiving the HTTP request, DR-Web retrieves information from the Subagent and converts SNMP MIB data into HTML pages. The operator can easily create customized pages using point-and-click operations. For example, network administrators may want to create a page called "routerstatus" which contains only those MIB variables of interest to them. Operators can retrieve this customized page again and again without respecifying the variable grouping.

The DR-Web Extensible Agent is actually an enhancement to SNMP Research's EMANATE Master Agent/Subagent system. The EMANATE Master Agent is extended to support an HTTP interface as well as the existing SNMP interface to the event queueing subsystem. DR-Web converts HTTP requests and SNMP requests to EMANATE events, and dispatches them to the appropriate Subagents. Because this modular architecture requires no changes below the event queuing subsystem, all customer investment in EMANATE-based SNMP subagents is preserved. The layering approach also allows for future support of the HyperMedia Management Protocol (discussed later) as well as other new protocols without requiring changes to the Master Agent/Subagent relationship.

The DR-Web Extensible Agent meets the needs of those seeking applications, systems, or device management solutions that are both standards-based and accessible via Web browsers. Using the automatic code-generating facilities provided by SNMP Research's Subagent Development Kits, users can generate Subagents for monitoring critical application processes. Checking the status of an application or changing its priority can then be accomplished at the nearest available Web browser.

Hewlett-Packard & IBM | Vendor Implementations

Hewlett-Packard

Web-based management capabilities first appeared in enterprise management platforms, but have since migrated to LAN management platforms. Hewlett-Packard, which offers Web interfaces to its enterprise-oriented HP OpenView Network Node Manager, has extended that capability to the LAN-oriented Professional Suite, a comprehensive software solution that allows customers in small to midsize networked environments to manage virtually all elements of a PC LAN. Included with HP OpenView Professional Suite is Microsoft's Web browser, Internet Explorer.

This enhanced version of HP OpenView Professional Suite can automatically discover Web devices. It can also provide a menu that lets the administrator launch a Web browser to display the management page of any device that can be managed via Web technology. With the Web interface, a network administrator is able to access Web-based LAN management information from any location, such as a remote server site or a home computer.

HP OpenView Professional Suite combines the power of a central management console, including automatic discovery and map generation, with the ease of using the Web to manage devices. OpenView provides direct access from the map to the management page of devices that can be managed through any standard browser, including Netscape Navigator. OpenView accomplishes this by automatically discovering these devices and providing menu items that launch a Web browser with the appropriate page displayed.

Among the hardware that can be managed by the Professional Suite—that also can be managed via the Web—include HP PowerWise uninterruptible power supplies and HP LaserJet printers.

IBM

HP's main competitor IBM also offers systems management capabilities through the Web. Since early 1996, IBM has been giving administrators the means to monitor PC and server performance via the Internet. Starting with version 4.0 of PC SystemView (formerly known as NetFinity), any machine with a Web browser can be turned into a PC SystemView management console. A typed-in code provides access via the Internet to a server running PC SystemView Manager software containing Web-enablement code. Once logged on to a network, an administrator can use PC SystemView to perform such tasks as manage desktop or server performance, configurations, problems, and security.

Frontier Software Development | Vendor Implementations

Frontier Software Development offers WebCast, a tool that provides access to the reporting capabilities of Frontier's NETscout Manager through common Web browsers. With WebCast, network managers can see end-to-end network reports through all seven layers of traffic on any topology, including Ethernet, Token Ring, Fast Ethernet, Switched LAN, VLAN, WAN, Frame Relay, FDDI, and CDDI.

WebCast automatically converts NETscout Manager traffic reports into Web pages that can be read quickly and easily by authorized users throughout a distributed computing network. This makes network data, traps, and Java-enhanced alarms accessible through an organization's intranet at very low cost.

WebCast makes all this network data available over the Web through its EnterpriseRMON, which is a superset of RMON1 and RMON2. EnterpriseRMON extends standard RMON functions by adding client/server application traffic reports, and improves enterprise traffic management and system-level troubleshooting.

In addition to its detailed reporting capability, WebCast gives network administrators location-independent management capabilities. Administrators can use WebCast to configure probes and agents on a network or edit agent configurations through a Web browser. For example, managers can use WebCast to view utilization reports and host lists for IP and Web traffic running over a Frame Relay PVC, or look at vital statistics and information for any switched port in a Switched LAN environment.

Among its other management functions, WebCast can bill and charge back network users to help administrators control costs. WebCast software's embedded security lets network managers regulate access to ensure that sensitive information is viewed only by people who need to see and work with it. WebCast embedded security can create groups of users authorized to view any combination of auto reports, on-demand individual reports, alarming or SQL queries. Access to information is set by the network manager and the privileges are activated at the time of user log-on.

WebCast automatic polling updates reports at intervals selected by the network administrator, so the information is always current. The reports can be updated daily, weekly, monthly, or all three. WebCast also formats the reports so that busy network administrators can review the information quickly. This reduces management overhead on the network by gathering the data only once, an approach that eliminates repeat traffic and reserves valuable bandwidth for mission-critical applications and communications. Java-based traps and alarms are integrated to alert administrators to current or potential problems, before they affect network performance.

WebCast customized queries let users specify their own query criteria for the SQL data base by filling in a simple form. No SQL experience is required. The forms enable users to make a specialized report for a specific network segment or a specific timeframe.

NETscout Server is a polling and data collection engine that supports end-to-end network monitoring by enabling many probes to reside on the network while not clogging it with unnecessary traffic. NETscout Server periodically polls localized servers for data, information, and alarms from RMON-based probes and MIB2 devices, eliminating the traffic caused by constant data transmissions. With NETscout Server, companies can build manageable, scalable networks with extensive instrumentation. With WebCast, any data aggregated at remote sites can be accessed through a Web browser.

WebCast supports virtually an unlimited numbers of users and requires no additional training because it works through universally familiar Web browsers. According to Frontier, WebCast's advanced reporting and management capabilities come at about 3 percent of a dedicated workstation's cost.

WebCast is the first phase in Frontier's program to bring Web-based tools and distributed reporting to network users. The subsequent phases will introduce enhancements to NETscout Server's scalable mid-level management capabilities to allow peer-to-peer report aggregation of RMON information. Eventually, Frontier will introduce a Web interface for all of NETscout Manager's real-time diagnostic and analysis tools.