Technical White Paper

Published: July 19, 2007

Executive Summary

The technological advances from the 1970s to the 1990s enabled the birth of new messaging systems such as voice mail, e-mail, and fax, in addition to new methods for voice transmission, such as Voice over IP (VoIP). Traditionally, voice communication involved analog or digital transmission of data over distances by using physical wire through the plain old telephone service (POTS). Voice mail and fax communication occurred through POTS. The advent of the Internet and popularization of IP packet-switched networks gave rise first to e-mail, and then to VoIP communication. All these developments have gradually led to a convergence of disparate communication systems toward a common, unified infrastructure.

Microsoft incorporates emerging communication systems and technologies into its corporate environment according to business needs. By deploying Microsoft® Exchange Server 2007, Microsoft benefited from new unified messaging (UM) capabilities that combine voice mail, e-mail, and fax messages into a single Inbox for users. Technologically, Exchange Server 2007 accomplishes this through a new UM server role, which accepts traditional voice data from private branch exchanges (PBXs) through VoIP gateways or directly through IP PBXs. This results in considerable cost savings and flexibility for the Microsoft Information Technology (Microsoft IT) group, which is responsible for designing and implementing Exchange Server 2007 UM servers at Microsoft. With Exchange Server 2007 and VoIP technology, Microsoft IT eliminated separate physical telephony links between PBX switches and enterprise devices such as UM servers. Instead, VoIP gateways enable Microsoft IT to integrate traditional PBX switches into the unified IP-based communications infrastructure.

This technical white paper discusses how Microsoft IT designed and deployed an Exchange Server 2007-based unified messaging solution to support an increasingly mobile workforce with flexible and convenient access to voice mail, fax messages, calendar items, tasks, contact information, and e-mail messages in a single repository—the user's mailbox. Starting from an overview of VoIP technologies, this white paper covers the unified messaging environment at Microsoft before Exchange Server 2007. It then explains the design and deployment decisions that Microsoft IT made to transition from the third-party unified messaging environment to Exchange Server 2007-based unified messaging.

This paper contains information for business and technical decision makers who are considering deployment of the unified messaging server role in an Exchange Server 2007 organization. This paper assumes that the audience is already familiar with the concepts of TCP/IP networks, Windows Server® 2003, and the Active Directory® directory service. A high-level understanding of the features and technologies included in Exchange Server 2007 is also helpful. Detailed product information is available in the Microsoft Exchange Server 2007 TechNet Library at http://www.microsoft.com/technet/prodtechnol/exchange/2007/library/default.mspx.

Introduction

Unified messaging is the convergence of different forms of messaging, specifically voice, e-mail, and fax, in a single, integrated system. Of these messaging forms, voice mail was the first to achieve widespread use. Voice mail, invented in the early 1970s, first achieved commercial success in the mid-1980s. At that time, the rapidly declining price of semiconductors yielded processors fast enough to handle analog-to-digital conversion (that is, voice to digital signals), and innovations in disk technology resulted in more storage space for less cost. These factors, combined with the emergent PBX, enabled companies to adopt and implement voice mail systems on a large scale because voice mail became more affordable.

VoIP began to emerge in the mid-1990s with telephony applications streaming voice content over the Internet. Although the quality suffered from delays, jitter, and frequent disconnections, the IT industry quickly embraced the technology because of its compelling advantages over traditional telephone systems. IP networks are more cost-efficient to operate and provide greater flexibility than traditional time-division multiplexing (TDM)-based circuit-switched links. With increasing network bandwidths, efficient data-compression algorithms, and support for Quality of Service (QoS) levels in the physical network infrastructure, IP telephony has matured.

VoIP Trunking and Direct IP Communication

Public switched telephone network (PSTN) service providers and private companies with multiple locations use trunking to establish backbones that connect PSTNs or PBX systems in different geographical locations with each other. Traditionally, a trunk is a connection that consists of multiple individual TDM-based links, aggregated to increase the overall bandwidth. However, with the arrival of VoIP technology, TDM-based trunks are on the retreat while more cost-efficient IP-based WAN connections advance to take their place. For example, it is commonplace now for long-distance and international carriers to use VoIP trunking. TDM-to-VoIP gateways, commonly called VoIP gateways, connect local PSTNs to an IP-based backbone, such as the Internet. From the telephone to the local PSTN, the voice traffic still travels across TDM-based links, but the communication between the PSTNs now relies on VoIP.

As indicated in Figure 1, there are two options for delivering voice traffic from the PSTN to the corporate IP network: using a VoIP gateway or a dedicated IP PBX. IP PBX systems do not require a VoIP gateway to communicate over an IP-based network. All IP devices, including IP phones and IP-based equipment for video conferencing, can exchange data directly with each other over the computer network. The IP PBX switch does not need to be involved in the actual data transfer, which helps to improve the scalability of VoIP. In a pure IP PBX system, the IP PBX switch is responsible only for establishing sessions between the communication partners, thereby acting as a communication controller. A popular protocol to establish sessions is the Session Initiation Protocol (SIP). After a session between the IP phones is established, the devices use the Real-Time Transport Protocol (RTP) to transfer voice content.

Figure 1. VoIP in the corporate network

Microsoft IT uses VoIP trunking to connect older PBX switches to the corporate network through VoIP gateways. A VoIP gateway provides the necessary connectivity between the otherwise incompatible circuit-switched and packet-switched network architectures. VoIP provides Microsoft IT with the following advantages:

• The IP-based corporate network can replace legacy TDM-based trunks. The wide area network (WAN) operates at either 1.544 megabits per second (Mbps) (T1) or 2.048 Mbps (E1) speed.
• Communication within the company based on VoIP does not need to pass through public PSTN providers. This is also true for partner communication over extranet connections. Bypassing public PSTN providers helps to save costs.
• The IP-based computer network can route incoming phone calls to the user's IP phone regardless of the user's network location. For example, mobile users can receive incoming calls wherever they connect to the corporate network.
• It is possible to consolidate PSTN connections and provide telephony services to small branch offices over the IP network by using pure IP PBX systems or single IP phones.
• IP-based PBX systems facilitate remote administration because IP PBX switches provide Web-based configuration interfaces or support directory integration based on Lightweight Directory Access Protocol (LDAP).
• The IP-based corporate environment can support unified communication services, including Exchange Server 2007 for unified messaging and Microsoft Office Live Communications Server 2005 for IP telephony, call control, and instant messaging.

Unified Messaging Prior to Exchange Server 2007

From the year 2000 until Exchange Server 2007, Microsoft IT used a combination of traditional voice mail systems and a third-party UM solution to provide employees with voice mail capabilities. Microsoft IT supported 46,000 users in the unified messaging environment, 79 percent of whom accessed the UM servers from the headquarters in Redmond. Microsoft IT maintained 25 servers (including six tracing servers) for UM in eight sites located in North America, Asia, and South America. These servers answered approximately 280,000 calls per week, with 40 percent of the calls resulting in voice mail messages. The remaining 60 percent of calls resulted in answered calls or callers not leaving voice mail messages.

With the third-party UM system, Microsoft IT maintained a database for user administration of UM-enabled users. This database existed separately from the Active Directory user database. Therefore, UM user management for Microsoft IT entailed additional tasks outside managing users and user attributes through Active Directory.

Telephony and Network Infrastructure

Microsoft IT's UM environment before Exchange Server 2007 included third-party UM servers, e-mail servers, PBXs, and telephony and IP connectivity. The combination and setup of these components varied to support the user capacity needs of each UM server location. Although Microsoft IT supports over 500 office locations worldwide, only eight sites (Redmond, Silicon Valley, Shinjuku, Mexico City, Bangalore, Singapore, Sao Paulo, and Austin) housed third-party UM servers. Most of these sites were small, requiring only 16 digital phone lines each to provide UM services to regional users. The sites with more users, such as Redmond and Silicon Valley, relied on T1 connectivity.

Table 1 shows the locations that housed the third-party UM servers. The UM servers required connectivity to Microsoft Exchange Server 2003 Mailbox servers and the PBX system. Whereas Exchange Mailbox servers communicated with UM servers through the IP network, the PBXs communicated with UM servers through telephony connections, such as T1 or digital set emulation. Telephony connection runs are expensive to implement over long distances. As a result, Microsoft IT deployed the third-party UM servers in the same physical site as the PBX.

Table 1. Telephony Site Summary

* The Redmond site includes multiple PBXs and forests

Some of these sites have multiple forests and multiple PBXs. For instance, the Redmond site has one main logical layout to support the entire Redmond area. Yet, there are five Active Directory forests within Redmond for different purposes, such as legacy product support and future product testing. Multiple PBXs service these forests.

Connectivity

Connectivity in a UM system includes the telephony TDM connections between PSTNs and PBXs, the IP-based SIP/T.38 connections between VoIP gateways and UM servers, and IP network connections such as MAPI and LDAP between UM servers and the rest of the network. For its third-party UM system, Microsoft IT relied on the following types of connectivity:

• Telephony   The type of telephony connection that Microsoft IT used varied depending on the capacity needs of the area and the connectivity available. Sites that supported a lower call volume relied on a digital set emulation connection between the PBX and third-party UM servers. Larger sites required a T1 connection between the PBX and third-party UM servers to support a higher call volume. Microsoft IT used T1 Channel Associated Signaling (CAS) for connectivity. For T1 CAS SMDI call integration, Microsoft IT used RS232 integration links.
• Local area network (LAN)   Before Exchange Server 2007 UM, Microsoft IT placed third-party UM servers on the LAN that is located in the same geographical site as the PBX. Microsoft IT made this decision based on costs: Running long-distance PBX telephony connections is expensive.
• WAN   As explained in the "E-Mail Messaging Infrastructure" section later in this document, Microsoft IT consolidated mailbox servers to just four sites by using Exchange Server 2003. The third-party UM servers communicated with the Exchange Mailbox servers in these sites through WAN connections. The sites that housed UM servers had low-latency connections to the locations that housed Exchange Server 2003 Mailbox servers.

In this environment, the telephony connectivity type and number of ports, which are based on the number of UM users and call load, determine the PBX and number of third-party UM servers necessary for a particular location. Microsoft IT used the following site models:

• Small site   Most of the UM sites provided services to fewer than 2,000 users. In these sites, eight phone lines per UM server supported incoming calls. Each of these small sites contained two third-party UM servers. The third-party UM servers accepted voice mail messages received by the PBX and transferred messages to the Exchange Mailbox servers.
• Medium site   Shinjuku in Tokyo was the only medium site in the third-party UM solution, with 32 digital set emulation ports dedicated to voice mail to support a higher call volume. Shinjuku used two third-party UM servers with 16 digital lines per server, instead of the eight lines per server used in smaller configurations.
• Large site   Redmond and Silicon Valley were the largest sites, designed to support a high volume of calls. They used T1 CAS connections between the PBXs and UM servers. Each T1 line carried 24 channels of voice, and a single RS232 integration link carried the SMDI call integration information.

Figure 2 illustrates these site models.

Figure 2. UM infrastructure prior to Exchange Server 2007

PBXs

PBX systems enable companies such as Microsoft to manage incoming calls by sharing a small number of outside phone lines among many internal extensions. PBXs have evolved to meet the growing needs of the virtual office, and today they are robust systems that offer voice mail, fax, Auto Attendant, and other advanced features in call routing. Microsoft IT uses the following types of PBXs to accommodate the various usage and capacity requirements in its sites:

• Intecom   Although PBXs are not specific to an Active Directory forest, the Redmond site uses Intecom PBXs for the main corporate forest and other forests.
• Nortel SL100   The Silicon Valley site relies on the Nortel SL100 PBX to provide voice mail, Direct Inward Dialing (DID), and other features.
• Nortel Meridian   Microsoft IT uses this PBX's digital set emulation connection at its smaller sites. In a digital emulation setup, the gateway emulates a multiple digital phone set that the PBX supports.

PBX Interfaces

Both the Nortel and Intecom PBXs that Microsoft IT use support various protocols, interfaces, and switching methods. However, for Microsoft IT, the following aspects of PBX interfaces are most relevant with the third-party UM environment:

• PBX-to-trunk-line connections   For connecting PBX systems to the telephone company, the Nortel and Intecom PBXs support Integrated Services Digital Network (ISDN). ISDN is a long-established connection option that takes the form of either a Basic Rate Interface (BRI) capacity of two circuits or a Primary Rate Interface (PRI) capacity of 24 circuits in North America. Intecom and Nortel SL100 PBXs use a T1 PRI, whereas Nortel Meridian uses BRI lines through digital set emulation. Although some PBXs and telephone companies support Internet Protocols for trunk connectivity, such as H.323, SIP, Media Gateway Control Protocol (MGCP), and Inter-Asterisk Exchange (IAX), The Nortel and Intecom PBXs that Microsoft IT used did not support IP trunk connectivity options.
• PBX-to-PBX connections   Intecom and Nortel PBXs have the capacity to share signaling data. Both Nortel SL100 and Intecom PBXs support T1 CAS. Additionally, Nortel PBXs supported T1 Q signaling (Q.SIG). However, when Microsoft IT deployed the third-party UM-based environment, the third-party servers did not support T1 Q.SIG.
• Third-party UM to PBX connections   At the time of installation, the third-party UM servers supported analog, T1 CAS, and digital set emulation. The cards that connected to the PBX used the specific cable that worked for the interface. For example, the T1 CAS connection used a standard RJ 48C connector.
• Data collection and SMDI   For data gathering options, PBXs include call record log files or a network interface. For SMDI integration, PBXs use a DB-9 RS232 serial interface.

PBX Features

At a basic level, PBXs are responsible for connecting an incoming call to an internal user's extension, maintaining the established connections, and keeping a log of the information associated with the call. Microsoft IT uses Nortel and Intecom PBXs to provide other common features and capabilities, such as Auto Attendant, DID, and voice mail. For a more detailed list of features available, see Table 13 in Appendix B.

E-Mail Messaging Infrastructure

Microsoft IT consolidated its messaging environment during the Exchange Server 2003 time frame. Because of the consolidation, mailbox servers now reside in only four data centers, from which they support the other office locations according to geographical boundaries. Table 2 lists the data centers and the regions for which they are responsible.

Table 2. Microsoft Data Centers and Regions of Responsibility

After consolidation, multiple locations with third-party UM servers accessed the same Exchange Server 2003 Mailbox servers in the four data centers. For example, Singapore and Shinjuku shared the servers in the Singapore data center, whereas Mexico City, Austin, Redmond, and Silicon Valley shared servers in the Redmond data center.

Reasons for Microsoft IT to Deploy Unified Messaging

For Microsoft IT, the unified messaging capabilities of Exchange Server 2007 presented an opportunity to centralize administration and monitoring of voice mail and fax, provide users with self-service capability, and consolidate sites and servers. By integrating voice mail, fax, and e-mail in a unified messaging environment, Exchange Server 2007 provides users with convenient and flexible access to messaging information. Employees can access e-mail, voice mail, calendar items, fax messages, and contacts from one mailbox. Exchange Server 2007 enables employees to access their mailboxes from a telephone by using Outlook® Voice Access, from a mobile device, or from notebook and desktop computers by using Microsoft Office Outlook. Furthermore, the unified messaging server role includes text-to-speech features and English voice recognition for access to mailbox and directory information.

Microsoft IT recognized the following improvement opportunities with Exchange Server 2007:

• Reduced costs   With UM and voice mail systems before Exchange Server 2007, expanding service to new sites was costly. It required UM server deployment and expensive voice cards, or expensive traditional voice mail system upgrades. With Exchange Server 2007, Microsoft IT could deploy gateways at regional sites and locate UM servers in four major data centers that also house Exchange Mailbox servers.
• Site and server consolidation   The Exchange Server 2007 UM role relies on VoIP gateways or direct SIP interoperability with IP PBX systems to receive information from the PBX. This capability enables Microsoft IT to expand services easily to new sites by deploying VoIP gateways at local sites and configuring shared UM servers in major data centers.
• User self-service   By combining self-service features such as personal identification number (PIN) reset with a single mailbox for multiple message types, Exchange UM puts users in control, reducing Helpdesk calls and support costs. Additionally, users can access e-mail and voice mail through a variety of methods, including the full Office Outlook client, Microsoft Office Outlook Web Access, a mobile device, or a standard telephone.
• Active Directory integration   Whereas the third-party UM system used a separate user database, Exchange Server 2007 UM natively integrates with Active Directory. UM objects, such as dial plans, VoIP gateways, and hunt groups, have a logical representation as Active Directory objects for easier administration because all the data is stored in Active Directory. Additionally, Exchange Server 2007 UM uses the Active Directory user database for a single repository of user data.
• Next generation networking (NGN)   Unified messaging and VoIP represent a general trend toward convergence of messaging systems into a single network type: the packet-switched IP network. This network transports services and data for voice, data, video, and other media by encapsulating the streams into data packets. NGN requires essential building blocks, such as an IP network, site connectivity, and existing routing topologies for the various traffic types. As part of an effort to move to NGN, Exchange Server 2007 offers Microsoft IT UM and convergence of traditional PBX systems and the IP network.
• Administration, operation, and training   With one user database (Windows® Active Directory), one message store (Exchange Server), and one messaging infrastructure to maintain for additions, moves, changes, and backups, Microsoft IT can realize savings in administering and maintaining the voice mail, fax, and e-mail messaging systems. Using one system consistently across the enterprise network also enables Microsoft IT to reduce the time spent training users and administrators.
• Employee productivity   The features that Exchange UM provides to access voice mail, fax, and e-mail messages from one mailbox, coupled with the ability to access the mailbox by phone, mobile device, or computer, creates great flexibility for Microsoft employees. Outlook Voice Access makes it possible to adjust calendar items, check and write messages, and retrieve directory information while away from the office.

Exchange Server 2007 Unified Messaging Design

When designing an environment based on Exchange Server 2007, Microsoft IT considered not only the many components in the existing environment, but also the required components in the new Exchange UM-based environment. The transition between UM solutions and the requirement to have minimal service interruptions as well as multiple sites made it necessary for Microsoft IT to carefully evaluate the components in the UM environment and design an Exchange Server 2007-based solution.

To ensure a smooth transition at all sites, Microsoft IT designed the Exchange Server 2007 UM-based environment in stages, making early design decisions for foundational aspects, and later building on early design decisions to account for all aspects of the environment. Microsoft IT conducted the following design phases:

1.     Infrastructure inventory   In this phase, Microsoft IT outlined a high-level overview of the existing environment, including sites, Exchange and Active Directory forests, telephony, and IP connectivity. This process included analyzing the number of users and capacity needs at each site, and special configurations, such as the multiple-forest Redmond site. For more details about the data gathered in this stage, see the earlier section "Unified Messaging Prior to Exchange Server 2007."

2.     Hardware selection   The major goals in this phase included selecting which hardware components to keep, remove, or modify during the migration, in addition to selecting the best new components for the Exchange Server 2007 UM-based environment. Retaining existing PBX hardware, Microsoft IT installed new VoIP gateways and Exchange Server 2007 UM servers. For more details about these decisions, see the later sections "UM Server Design," "PBX Integration," and "VoIP Gateway Selection."

3.     Topology design and selection   In this phase, Microsoft IT designed model deployments for all locations based on the information gathered in the previous phases. The design reflected anticipated site usage, Exchange and Active Directory dependencies, and available connectivity. For more information about the specific decision factors, see the later section "Connectivity Scenarios and Model Configurations."

4.     UM features   After the hardware and topology design phases, Microsoft IT focused on Exchange Server 2007 UM features to select the best options relevant to the production environment. For more information about which features Microsoft IT implemented, see the later section "UM Features Available."

5.     Administrative and operations design   To complete the design phases and prepare for rollout, Microsoft IT planned for user provisioning, administration, and system monitoring. Microsoft IT's administrative design focused on user self-service so that common requests, such as PIN reset, would require no administrative intervention. For more information about administration and monitoring, see the later sections "System Monitoring" and "Security."

Design Components

When designing the Exchange Server 2007-based UM environment, Microsoft IT worked within the specifications of the Exchange product group to choose the various telephony and IP components that Exchange Server 2007 UM requires. The Exchange product group developed Exchange Server 2007 UM with the following dependencies:

• Telephony environment connected to PBX   As callers make voice or fax calls to Microsoft numbers, the telephony infrastructure that connects the PSTN to the PBX enables the PBX to receive calls by using TDM.
• IP PBX or PBX with VoIP gateway   For Exchange Server 2007 UM servers to process the incoming calls, the PBX must direct calls to an Exchange UM server. Microsoft IT uses VoIP gateways to connect PBXs to Exchange UM servers. Exchange UM servers use T.38 for faxes and RTP for voice calls after initiating the session by using SIP.
• IP environment After the VoIP gateways direct incoming calls to an Exchange UM server, the UM server processes calls and offers features such as directory services, Outlook Voice Access, and Interactive Voice Response (IVR). To accomplish this, Exchange UM servers communicate with the Active Directory and Exchange environment by using a variety of protocols, including Simple Mail Transfer Protocol (SMTP), MAPI, and LDAP.

Figure 3 shows the typical UM design components.

Figure 3. Typical UM design components

Component Selection and Decisions

When selecting the UM components, choosing site topologies, and determining bandwidth requirements, Microsoft IT followed the decision process shown in Figure 4. There were several decisions to make that affected the entire environment, in addition to specific design and selection processes for each site.

Figure 4. UM design process flow

1.     Microsoft IT started the design process decisions by determining whether the environment required one location or multiple locations. A location refers to a geographic area with either a single PBX or multiple PBXs that share a single voice mail system. As mentioned earlier in the "Unified Messaging Prior to Exchange Server 2007" section, Microsoft IT supports eight locations.

2.     Because Microsoft requires multiple Exchange forests, Microsoft IT did not consolidate forests or locations when designing Exchange Server 2007 UM. However, as mentioned earlier, Microsoft IT previously consolidated Exchange mailbox data centers to four locations during the Exchange Server 2003 period. Because this was already in place, Microsoft IT took advantage of earlier consolidation efforts to collocate UM servers in the four major data centers.

3.     After taking an inventory of the locations, Microsoft IT considered technical and business needs for each location. For example, Microsoft tracked the typical number of calls and users in the UM environment to serve as a baseline for designing UM servers and provisioning the necessary connectivity. Microsoft IT kept existing PBXs and configured them to work with Exchange UM servers.

4.     For each location, based on the connection and PBX, Microsoft IT chose the appropriate VoIP gateway. For more information about the decision factors and available gateways, see the later "VoIP Gateway Selection" section.

5.     Microsoft IT implemented all UM features, configured them for the environment, and verified functionality through testing.

6.     After installing, configuring, and testing the new UM voice mail infrastructure, Microsoft IT migrated users from the third-party UM system to Exchange Server 2007 UM.

UM Server Design

Microsoft IT made server design decisions based on testing results during product development. Microsoft has a policy of testing software builds during product development in a process called "dogfooding," during which Microsoft IT installs a test environment in the Exchange forest in addition to a test lab for design and implementation engineers to evaluates stability and functionality. During the initial design, Microsoft IT used a dual-core AMD Opteron 2.2-gigahertz (GHz) processor, as shown in Table 3. It is important to note that the Microsoft IT made server sizing and design decisions during the beta testing period and kept the server hardware configuration for the production environment.

Table 3. Server Hardware per Server Role

In past circuit-switched PBX UM implementations, the number of simultaneous callers was limited by the physically available ports. With Exchange Server 2007 UM, the IP-switched network is limited not by the ports, but by the network bandwidth, processing time, and virtual memory. However, Exchange Server 2007 UM-based environments can be modeled in a similar way to circuit-switched PBX environments because the connection between the PBX and telecommunications provider has a specific number of ports. For example, a T1 PRI connection carries 24 channels for a possible 24 simultaneous connections. Based on performance monitoring of the number of calls during a peak period, Microsoft IT provisioned the appropriate connectivity for each site. Regardless of the type of connectivity, Microsoft IT connects at least two VoIP gateways at each site, which are configured to at least two UM server partners. If the expected call volume and user loads exceed the capacity of a single server, the Exchange Server 2007 architecture enables Microsoft IT to increase capacity by adding UM servers to the dial plan.

Server Load Considerations

UM operations from both authenticated and unauthenticated users place a load on server resources. The load varies with the time of day and the number of features used. For example, in the beginning of a workday and after lunch, there is a high load when users access voice mail and the system processes internal and incoming calls. The load depends on the demands placed on the UM server, as explained in Table 4.

Table 4. Demands Placed on UM Servers

Microsoft IT set the Maximum Concurrent Call setting of 100 on Exchange UM servers based on testing and production environment metrics. For example, with third-party UM servers, Microsoft IT measured calls by using the Current Calls counter. This value, combined with the number of ports provisioned for voice mail, yielded the recommended number of calls per server. As part of preliminary analysis for the capacity of a UM environment, including voice mail ports, Microsoft IT used Erlang analysis, as explained in Appendix A.

Message Size

Voice mail and fax messages compose the two major message types that use a significant portion of the available processing power, memory, and hard disk storage on a UM server. Voice mail and fax messages are not permanently stored on an Exchange UM server, but in the user's mailbox on an Exchange Mailbox server. For long-term storage, knowing the size of these messages is important because it affects mailbox quotas and mailbox server sizing. For immediate processing of incoming calls, message size is also relevant because a UM server converts a message into a file that is attached to an e-mail message in the user's mailbox. Therefore, as part of determining the server requirements, determining typical message size for users was important for Microsoft IT.

Incoming calls result in answered calls, hanging up, or a voice mail or fax message. The attachment size stored in the user's mailbox varies with the following factors:

• Recording duration   Typical message length is 30 seconds or less at Microsoft.
• Audio codec used for communication between the VoIP gateway and UM server   When accepting voice mail data from VoIP gateways, Exchange Server 2007 UM servers can accept the data encoded in G.711 A-Law or G.711 mu-Law pulse-code modulation (PCM) methods (uncompressed), in addition to G.723.1 (compressed). Although G.711 generally yields better quality voice data, it requires more bandwidth because it is uncompressed. Running G.723.1 in a production requirement requires configuring QoS measures, such as higher-priority packets across the firewall, because loss of compressed G.723.1-encoded data results in a lower voice quality than if the same data is lost in G.711 encoding. The Microsoft IT environment supported the higher bandwidth requirements of G.711. Therefore, to ensure the highest voice quality, Microsoft IT uses G.711 encoding for voice mail transmission between the VoIP gateway and UM server.
• Audio storage format   After accepting voice mail data encoded through G.711 or G.723.1 from VoIP gateways, Exchange Server 2007 UM servers can create either Windows Media® Audio (WMA) or Wave (WAV) files from voice mail messages to store as attachments in a user's mailbox, using one of the three codecs shown in Table 5. WMA is the most highly compressed codec (about 11,000 bytes for each 10 seconds). GSM 06.10 is also compressed (about 16,000 bytes for each 10 seconds). G.711 is uncompressed. Of the three formats, WMA produces the smallest file sizes for recordings with a duration of about 15 seconds and longer. Because the average voice mail message is approximately 30 seconds long, Microsoft IT chose WMA as the default setting.

The server load in terms of processing power and memory requirements varies depending on message duration, communication codec, and storage file type. For example, although UM servers use processing power and memory when creating files to be delivered to users, UM servers also use processing power and memory with G.711 and G.723.1 audio transport codecs when accepting voice mail data from VoIP gateways. Because G.723.1 uses compression, using G.723.1 requires more resources than using G.711. Additionally, when users access UM servers, Outlook Voice Access communication uses fewer resources than incoming calls that result in voice mail messages. Correspondingly, the true server load varies with usage details and VoIP gateway configuration. Microsoft IT designs production Exchange UM servers to handle between 60 and 100 simultaneous calls while meeting service levels. This guidance comes from product group recommendations.

Table 5. Unified Messaging Audio Codecs for Voice Mail Storage

Connectivity Scenarios and Model Configurations

Microsoft decided to standardize the Exchange Server 2007 UM environment connectivity based on site size and gateway type, in addition to the connectivity for the site and gateway. The end goal entailed a series of model, baseline combinations of PBXs, gateways, UM servers, and associated connectivity between these components.

After analyzing the connectivity requirements and chosen components, Microsoft IT created the following model configurations for use in all locations:

• T1 CAS-based environment   Sites with thousands of users, such as Redmond and Silicon Valley, require T1 PRI connections to support the traffic. As explained in the "VoIP Gateway Selection" section later in this document, the combination of PBX and gateway choices meant that the gateway supported either one T1 or dual T1 lines. Correspondingly, the Redmond location used dual T1s for each gateway, and the Silicon Valley location used one T1 for each gateway, as shown in Figure 5.
• T1 Q.SIG-based environment   In addition to using T1 CAS connections, Microsoft IT used T1 Q.SIG in the Sao Paulo location. The chief difference between T1 CAS and T1 Q.SIG is how each handles integration information. Whereas T1 CAS requires an SMDI link, T1 Q.SIG carries integration information on the twenty-fourth channel in the PRI.
• Digital set emulation-based environment   For other sites worldwide, Microsoft IT kept the Nortel PBXs, used with third-party UM servers in combination with the Intel PIMG VoIP gateways. These components used digital set emulation for telecommunications provider connectivity.

Figure 5. Connectivity scenarios for sites

UM Features Available

For Microsoft IT, designing the Exchange Server 2007 UM-based environment entailed taking into account the available features with Exchange Server 2007 UM. The following features highlight key Exchange Server 2007 functionality for users and administrators:

• Outlook Voice Access   With Exchange Server 2007 unified messaging, UM-enabled users or subscribers can access their e-mail, contacts, and calendar information by using a standard analog, digital, or cellular telephone. When a UM-enabled user dials the designated access number, an Exchange UM server prompts the user for action through the telephone user interface (TUI). This TUI enables users to access and manipulate Exchange items by either speaking English commands or using the telephone keypad (with prompts available in many languages). The voice menu is Outlook Voice Access, with which UM-enabled users can perform the following tasks:
• E-mail and voice mail   Users can listen to new and saved e-mail and voice mail messages, and forward, reply, save, and delete e-mail and voice mail messages.
• Calendar   Users can interact with their calendar, including listening to daily calendar appointments and meeting details, accepting or declining e-mail and meeting requests, sending an "I'll be late" message to meeting participants, replying to a meeting request by using voice inputs to send a message to meeting participants, and canceling meetings.
• Directory and personal contacts   Users can interact with global address list (GAL) and personal contacts. These interactions can include locating a person in the GAL or personal contacts, playing the person's contact details, calling the person's office phone or mobile phone, and sending the person a voice message.
• Auto Attendant   The UM Auto Attendant is a set of voice prompts or WAV files that are played to callers in place of a human operator or receptionist. When external or anonymous callers access the UM system, they can use telephone keypad or speech inputs to locate a user or place a call.
• User self-service   For security-enhanced access to voice mail, users have PINs. The PIN is separate from the user's Active Directory account password and is stored as an encrypted attribute of the user's Active Directory account object
• Voice mail form   The Office Outlook 2007 and Office Outlook Web Access voice mail form resembles the default e-mail form, but it gives users an interface for performing actions such as playing, stopping, or pausing voice messages, playing voice messages on a telephone, and adding and editing notes. If users are not using Office Outlook 2007 or Office Outlook Web Access as their e-mail client, the voice mail form is not available, and they receive voice messages only as attachments. The voice mail form includes the embedded Windows Media Player and a notes field. The following three options are available on the voice mail form:
• Play   Users can play and listen to voice messages by using computer speakers or headphones.
• Play On Phone   The Exchange Server 2007 Unified Messaging Play on Phone feature enables UM-enabled users to access a voice mail message. However, instead of playing the media file over their computer speakers, they can listen to the message on the user's phone or at another telephone number specified by the user.
• Edit Notes   Users can use this option to add or edit notes associated with the voice mail message.
• Active Directory representation   With Exchange Server 2007 and Active Directory, UM physical objects such as servers and gateways, and logical objects such as dial plans, have logical representations in Active Directory. This enables Microsoft IT to easily keep records of UM data and conveniently manage components. Keeping a single directory of all users in Active Directory eliminates the need for a separate, voice-mail-only directory.

PBX Integration

To integrate PBXs with the rest of the UM environment, Microsoft IT considered the following deployment prerequisites:

• Line provisioning   For PBXs to accept calls, they require a connection to the telephone company. The connection type for each location varies with the port capacity. For example, at Microsoft, Intecom PBXs require a T1 PRI CAS trunk, whereas Nortel PBXs require either a T1 PRI or phone lines that the PBX emulates as a digital set.
• Signaling integration   For each PBX, Microsoft IT decides the signaling integration configuration. For example, Microsoft IT asks whether the PBX uses SMDI, Q.SIG, or digital set emulation. The answer may change technical requirements because Q.SIG and digital set standards have built-in signaling integration, whereas T1 CAS requires a separate SMDI link.
• Line call plan   For each location and for PBXs associated with the location, Microsoft IT considers what call plan the PBX supports. A call plan can be configured to support calls worldwide, within the country, or within the locality, or to support only internal calls. Microsoft IT configures the call plan for each site to support calling numbers within the country of the site.
• Hunt group/pilot number   Because Microsoft IT migrated to an Exchange Server 2007 UM environment, Microsoft IT considered whether to reuse voice mail numbers or create new ones. Microsoft IT makes this decision on a case-by-case basis, and the decision varies with the location-specific business requirements.

VoIP Gateway Selection

Microsoft IT focused heavily on gateway selection when designing the UM environment because of the numerous gateway selection criteria. For redundancy, Microsoft IT decided that each location should have at least two gateways. Each gateway communicates to multiple UM servers by using round robin. Microsoft IT considered the factors shown in Table 6.

Table 6. Gateway Selection Considerations

Table 7 shows the VoIP gateways that are supported for Exchange Server 2007 unified messaging servers as of release to manufacturing (RTM). It is important to note that these gateway options were established during beta testing for Exchange Server 2007 and served as a starting point for Microsoft IT.

Table 7. VoIP Gateway Options for Exchange Server 2007 UM

For the latest information about supported VoIP gateways, refer to http://technet.microsoft.com/en-us/library/bb123948.aspx.

Gateway Selection Criteria

In deciding the appropriate gateway to use with Exchange Server 2007 UM servers for each site, Microsoft IT followed several constraints and requirements. For example, the gateways must support signaling integration and must connect to the PBX. Microsoft IT systematically picked the gateway for each model configuration, making the following decisions to arrive at the final gateway for each location:

• Analog/digital choice   Microsoft IT considered whether the incoming connection was digital or analog. Analog connections are typically used for locations with few users. Correspondingly, VoIP IP gateways that support analog connections support only a small number of connections. For example, the Intel PIMGG80LS and MediaPack 114/8 Foreign Exchange Office (FXO) emulate an analog phone set, which takes in-band tone or out-of-band SMDI integration for voice mail operation. These gateways support a maximum of eight phone connections, which is too small for all Microsoft IT model configurations and locations. Therefore, Microsoft IT uses digital connections in all locations. With digital connections, Microsoft IT decided between using digital set emulation or T1 PRI trunks. This decision depends on the user load and available connectivity at each location. The Nortel Meridian PBX does not support SMDI or in-band tone integration and uses a digital set emulation or T1 Q.SIG connection. Sites other than Redmond and Silicon Valley can use Nortel Meridian PBX with the Intel PIMG80PBXDNI gateway, which supports digital set emulation. This gateway emulates eight Nortel digital phone sets, so the PBX views the gateway as eight different phone sets on the same hunt group and handles the connections and requests (transfer/receive call) as a phone set.
• T1 CAS/T1 Q.SIG choice   The Redmond site (Intecom PBX) and Silicon Valley site (Nortel SL100 PBX) use T1 CAS with SMDI for voice mail. In a T1 CAS with SMDI integration setup, in addition to the T1 lines connected to the gateway, there is a single RS232 serial feed for SMDI integration for all the T1 lines on the same trunk group. Under this connection, the possible gateways available to Microsoft IT include Intel TIMG300/600DTI and Mediant 2000. Another option for a T1-based site is T1 Q.SIG. Whereas T1 CAS provides 24 channels, T1 Q.SIG provides 23 channels for voice and uses the last channel for integration information. Both Intel TIMG300/600DTI and Mediant 2000 can be configured to support T1 Q.SIG; however, Microsoft IT decided to continue using the connectivity types from the third-party UM environment and chose T1 CAS.

After Microsoft IT selected the Intel PIMG80PBXDNI gateway for sites that use Nortel Meridian PBX with digital set emulation, two options remained for the Redmond and Silicon Valley sites: Mediant 2000 and TIMG300/600DTI. Microsoft IT considered three aspects when choosing between Mediant 2000 and TIMG300/600DTI:

• Supported port density   This refers to the number of T1 trunks that a gateway supports. Intel TIMG300DTI supports a single T1 with an RS232 DB9 connection for SMDI, TIMG600DTI supports two T1s with an RS232 DB9 connection for SMDI, and Mediant 2000 supports one to eight T1s. However, for the SMDI implementation, in order to add the DB9 connection, the Mediant 2000 gateway supports only four T1s. From a port density perspective, the Mediant 2000 gateway supports more ports than the Intel TIMG600DTI gateway.
• SMDI integration   The UM environment at Microsoft uses a T1 CAS connection with SMDI integration for Redmond and Silicon Valley locations, with each site using a single number for voice mail (same trunk group). In this configuration, the environment must share a single SMDI integration. The Intel gateway includes an option to connect the RS232 serial SMDI feed to a gateway, and then use the IP network to share SMDI information with other gateways on the same trunk group. For AudioCodes Mediant 2000, there is no feature to share SMDI integration between gateways by using the IP network. For SMDI integration to reach multiple gateways, the Mediant 2000 gateway requires the use of a split RS232 cable to connect the single SMDI link/source to multiple Mediant 2000 gateways. This is not an officially supported configuration.

  There are several issues with using a split RS232 link, including the following:

• Limitation on secondary connection   When two or more gateways are connected to the PBX, only one of the gateways can send information back to the PBX. All the other secondary connectors will have the pin number 2 (for transmitting data) disconnected. This transmission back to the PBX enables the Message Waiting Indicator (MWI) feature. Also, with a split link, caller ID is limited to 10 digits.
• Limitation on length   Microsoft IT uses a baud rate of 9600 on the RS 232 DB9 port. For this configuration, the suggested cable length is a maximum of 50 feet. Microsoft stays within these limits, even with multiple splits on one cable, by physically placing the PBX and gateway in close proximity.

  Even though Intel gateways support SMDI integration through the IP network, for redundancy Microsoft IT decided to use two gateways and split the RS232 link. In this configuration, if one gateway fails, the other gateway connected with the RS232 cable continues to receive SMDI integration data. By doing this, Microsoft IT can switch over from one gateway to another, enabling gateway firmware updates with no service interruption.

• Management features   The Mediant 2000 gateway supports Syslog, which sends tracing information via User Datagram Protocol (UDP) to a remote computer. Intel gateways accomplish reporting through the RS232 connection on the back of the gateway. The Mediant 2000 gateway also includes a Web page interface for monitoring the ports' connection status. Intel gateways require extra steps to determine which port on which T1 trunk is currently connected.

After considering the connectivity, signaling integration, and PBX requirements for each site and the gateway options based on these requirements, Microsoft IT settled on the VoIP gateways shown in Table 8 for the model deployments.

Table 8. Summary Gateway Choices

Server Consolidation

As explained in the earlier section "Unified Messaging Prior to Exchange Server 2007," Microsoft IT managed three site types: large, medium, and small, depending on the connectivity requirements. The user load and connectivity requirements fit well with the creation of model site designs. For future capacity expansion, Microsoft IT can easily add more circuits, gateway servers, and UM servers to existing sites.

In addition to easy capacity expansion, Exchange Server 2007 UM offers Microsoft IT two key opportunities for consolidation:

• IP-based UM server   By using VoIP gateways in combination with telephony-based PBX servers and IP-based Exchange UM servers, Microsoft IT can locate UM servers anywhere on the IP network, including in dedicated data centers. This makes it possible to reduce the number of sites that have UM servers, providing services to multiple sites from the same set of servers.
• Exchange Server 2007 UM features   In addition to taking advantage of general Exchange Server 2007 benefits such as 64-bit architecture, Microsoft IT can use the UM features of Exchange Server 2007, such as tighter integration with Office Outlook and Active Directory, user self-service, and voice features, to offer a richer experience for users. In addition to requiring fewer servers, the new environment offers greater capacity per server, easier administration, and less administrative overhead. For example, for the more than 30,000 UM users in North America, Microsoft uses just five UM servers.

Fax Integration

Fax transmissions occur through the T.38 protocol, which specifies how to send an audio packet through a network, similarly to G.711. Communication that uses the T.38 protocol occurs over analog connections from the telephone company to the PBX and as encoded voice between the PBX and VoIP gateway. The VoIP gateway sends a fax transmission to the associated UM server, similarly to a voice mail message. The UM server attaches the fax transmission to an e-mail message for placement in the user's mailbox associated with the number after converting it into a TIFF file.

For Microsoft IT, fax integration entails fewer design challenges than voice mail because fax communication is only one way—incoming—through the T.38 protocol. With fax communication, delay is acceptable; out-of-sequence packets are also acceptable as long as the receiver can reconstruct the final fax. If a line is not available or if the connection fails, the sender can renegotiate a connection to resubmit the fax. All UM-enabled extensions at Microsoft can now also accept fax transmissions that are delivered to the Inbox.

System Monitoring

As part of designing a monitoring solution for the Exchange Server 2007 UM environment, Microsoft IT considered which components to monitor and the technology to use in monitoring. Microsoft IT uses Microsoft Operations Manager to monitor its Exchange organization. Microsoft Operations Manager includes the ability to monitor server status and generate reports about Exchange-specific information such as message queues. The following monitoring options are available:

• PBX   All PBXs that Microsoft IT uses support Simple Network Management Protocol (SNMP). Microsoft Operations Manager can retrieve data from SNMP devices and monitor status.
• VoIP gateway   Intel PIMG and TIMG VoIP gateways support e-mail alerts. Microsoft Operations Manager can use these alerts to notify administrators of failed gateways or other issues. In addition, Intel and AudioCodes gateways support SNMP.
• UM server   Microsoft IT uses Microsoft Operations Manager to check both general UM server status (by checking the event log) and performance monitor data, in addition to UM-specific information such as voice mail queues. Microsoft Operations Manager also includes the ability to check specific UM services and UM connectivity.

Security

There are many security concerns associated with a UM environment. For example, SIP proxy impersonation, network sniffing, session hijacking, and even unauthorized phone calls can compromise network security. Microsoft IT can choose from several methods to help secure the UM environment, especially UM servers and traffic between VoIP gateways and UM servers.

• Security-enhanced protocols   In the UM environment, Mutual Transport Layer Security (MTLS) can provide security for all traffic that uses SIP. This includes the traffic between VoIP gateway and the unified messaging servers.
• Trusted LANs   To prevent network sniffing and reduce overall security risks, Microsoft IT places VoIP gateways on a Virtual LAN (VLAN) separate from the corporate production environment. This makes traffic access possible only for authorized individuals with physical access to VoIP gateways. Moreover, UM servers communicate only with gateways explicitly listed in the dial plan.
• IP security (IPsec)   The Microsoft corporate network uses IPsec for all IP communication within the network.. To ensure optimal performance, Microsoft IT created an exception for gateway-UM server traffic.

In addition to these security measures, Microsoft IT enforces general security practices such as using strong authentication methods and strong passwords.

Unified Messaging Implementation

Microsoft IT approaches the implementation phase of a project by considering the components and requirements gathered during the design phase, as mentioned earlier in the "Exchange Server 2007 Unified Messaging Design" section, and systematically deploying each component or meeting each requirement.

In general, UM implementations concern the best order of deploying voice mail, e-mail, and fax components, in addition to the configuration settings for the components. For Microsoft IT specifically, the Exchange Server 2007 UM implementation entailed a period of coexistence with Exchange Server 2003 and the third-party UM system. Microsoft IT considered the following high-level implementation challenges:

• Migration of existing voice mail   In most situations, where migration takes place from a traditional voice mail system to UM, existing voice mail messages generally are not moved to the UM environment. However, because Microsoft IT had previously deployed a third-party UM system, users were able to access existing voice mail messages via their Exchange mailboxes, and there was no need to migrate these messages.
• Voice mail system coexistence   Microsoft IT decided to implement Exchange Server 2007 UM without immediately removing the previous voice mail and UM systems. In general, when there is a period of coexistence, there are several considerations. One consideration is whether the previous UM environment supports coexistence with the new environment. For Microsoft IT, the third-party UM servers used Exchange Server 2003, whereas the Exchange Server 2007 UM environment used Exchange Server 2007 UM and mailbox servers. Effectively, Microsoft IT maintained two UM systems for a short period while migrating users from the third-party environment to Exchange UM.
• Communication between new and existing voice mail systems   Microsoft IT considered the need for the third-party UM system and the Exchange Server 2007 UM system to communicate during migration and determined that Microsoft does not have this requirement. However, in some environments, the prior and current voice mail systems require connectivity during migration.
• Telecommunications requirements for running new and existing voice mail systems in parallel   For Microsoft IT, a serious consideration when choosing whether to run two voice mail systems in parallel is telecommunications requirements. For example, there are many possible limitations on the PBX, such as running out of SMDI integration ports or insufficient T1 connection ports. These are not easy problems to fix in the telecommunications world because some are inherent system design limitations, or require major upgrades.

Migration Approach

As part of the migration and coexistence considerations, Microsoft IT looked into two migration strategies available for the Microsoft UM environment: overnight migration and staged migration. Overnight migration refers to a strategy that seeks to deploy the Exchange Server 2007-based UM environment and transition all users in a short time frame during non-business hours. This strategy requires substantial preparation before deployment to ensure that all components are available during migration. Staged migration refers to a migration strategy that seeks to deploy, configure, verify, and test one aspect of the environment at a time. Table 9 shows possibilities with each migration strategy.

Table 9. Migration Strategies

Production Teams

A successful implementation of Exchange Server 2007 UM required Microsoft IT to coordinate many aspects of the deployment at each field location, including procuring necessary hardware, provisioning connectivity, installing hardware, configuring settings, and testing the deployment. Microsoft IT deployed UM services in multiple locations, sometimes using third-party vendors to help complete the migration to Exchange Server 2007 UM. As a result, Microsoft IT developed contact points between the teams to ensure efficient cross-team communication and completion of the acquisition, design engineering, and deployment processes. To accomplish these multiple tasks, Microsoft IT relied on the following teams:

• Coordination and procurement team   Because the Microsoft UM environment includes multiple locations, Microsoft IT deployed Exchange Server 2007-based UM one site at a time, starting with the locations with the most users. The Redmond location has the most UM-enabled users, so it served as a coordination center for all UM location deployments. The coordination and procurement team in Redmond is responsible for obtaining the necessary hardware, coordinating with worldwide UM locations, and ensuring that engineers have resources to deploy Exchange Server 2007 UM.
• Engineering team   Working in parallel with the coordination and procurement team, the engineering team in Redmond is responsible for translating design specifications into installation, configuration, and testing processes. The engineering team is also responsible for creating documentation about deployment settings and testing scenarios, as well as ongoing support of worldwide UM-enabled sites.
• Field site team   Each location has an on-site team that implements the VoIP gateways and configures the PBX including coordinating with the telecommunications company providing physical links to a particular location. The engineering team in Redmond provides support for field site teams, including troubleshooting and configuration testing.

Deployment Phases

To ensure consistency for all locations, Microsoft IT created a checklist for both on-site and supporting engineering teams. The checklist relied on the technological dependency that exists between UM components to create a deployment order for each location. For example, UM servers can be deployed on the IP network before other UM components, whereas VoIP gateways require PBX and UM servers to be in place before they are configured.

The items on the checklist can be separated into the following phases of deployment:

1.     Preparation   In this phase, Microsoft IT installs the Exchange UM server, configures the PBX, and gathers all the required data for installation, such as IP addresses, hunt group, and operator numbers. At the preparation phase, Microsoft IT also prepares for later testing by identifying a pool of test users. For more details about this phase, see the later section "Preparation."

2.     Procurement   During the procurement phase, Microsoft IT procures the gateway, required cables, patch panels, interface cards, and other hardware. As mentioned earlier, the team in Redmond procures all necessary hardware and arranges for delivery to worldwide locations. For more details about this phase, see the later section "Procurement."

3.     Gateway installation and configuration   After the on-site engineering team installs supporting hardware and cables, the team installs VoIP gateways for the location. Although the act of installation is not very time-consuming, configuring, testing, and validating proper installation takes coordination and considerable effort by both on-site and Redmond-based engineers. For more details about this phase, see the later section "Gateway Installation and Configuration."

4.     UM server integration   After verification that the VoIP gateway and PBX function are configured, Microsoft IT explicitly specifies the UM partner servers with which the VoIP gateway can communicate. The VoIP gateway blocks all communication with devices by default unless certain devices are specifically included. For more details about this phase, see the later section "UM Server Integration."

5.     Testing   After the UM server is specified as a communication partner in the VoIP gateway, and the VoIP gateway is specified in the UM server configuration, the environment is ready for testing. Microsoft IT configured UM servers in advance with the mailbox policies, hunt group, and other settings. Microsoft IT uses a test account and detailed checklists to test and verify that all UM components are operational. For more details about this phase, see the later section "UM Testing."

6.     Pilot number and production rollout   To test for proper connectivity, Microsoft IT engineers create a pilot number to use with the PBX and VoIP gateway. During proper operation, when an engineer dials the pilot number, the PBX should forward it to the VoIP gateway with all details, such as the number for caller ID. After testing, Microsoft IT rolls out UM services to all users for the location. For more details about this phase, see the later section "Pilot Number and Production Rollout."

7.     User support and education   After testing the UM environment by using a test account, Microsoft IT moves forward with live testing by using a select group of users. These users provide feedback and report any functionality issues. During this time, Microsoft IT also sends communication about the migration to Exchange Server 2007, including time frames and options for user self-service, such as PIN reset through Office Outlook. For more details about this phase, see the later section "User Support and Education."

In addition to the steps in the checklist, Microsoft IT performs operational tasks both during implementation and after. For example, Microsoft IT deploys VoIP gateways and UM servers in a way to provide redundancy for users. The later section "Disaster Recovery and Redundancy" provides more details.

Preparation

To prepare for deployment in a particular location, Microsoft IT completes preparation tasks. Using this checklist enables Microsoft IT to easily complete preparation tasks and access environmental information. After completing the tasks in the checklist, the teams record configuration details used later in deployment, such as IP addresses and test users. Table 10 shows the tasks of each team.

Table 10. Preparation Tasks

Procurement

For Microsoft IT, ordering UM components, shipping them to the site, and ensuring that VoIP gateways meet the certification for the country of the location takes the longest time, and it varies by location. Procurement entails both purchasing physical components and obtaining any remaining settings from the local environment, such as hunt group, extensions, and other phone numbers. Microsoft IT directs the following two specific processes during the procurement phase:

• Information gathering   Microsoft IT built two information-gathering processes (one in the preparation phase and one in the procurement phase) into the overall deployment plan to ensure that all information is gathered. Microsoft IT focuses on the PBX-related information in the procurement phase. This includes information about linear hunt group, pilot number recorded (DID or DDI in Europe), port numbers recorded, local dialable numbers, area codes, local dialing strings that are supported, local test extension, and local operator extension.
• Component ordering   The other major aspect of procurement is component ordering. This includes the following aspects:
• Gateway   Microsoft IT orders the gateway after selecting the proper ones for each site and tracks orders by maintaining a list of supplier, ordered date, and received date.
• Cabling   Microsoft IT uses both telephony cables and IP network cables to connect the PBX to the telecommunications provider, and the VoIP gateway to the PBX and UM server.
• Supporting hardware   In some cases, it may be necessary to order digital line cards or other interface cards for hardware. Also, the environment at the local site sometimes requires additional patch panels for connectivity.

Gateway Installation and Configuration

Microsoft IT relies on local, on-site system integrators to install and configure the VoIP gateway and the connection between the VoIP gateway and PBX. Even though there are multiple gateway vendors, the installation, configuration, and testing follows an order. Microsoft IT documented this order in the form of a checklist. Both the local system integrator and Redmond-based engineers work through the items in the following checklist when installing and configuring VoIP gateways:

1.     Install gateway   To begin the gateway installation process, the system integrator attaches the VoIP gateway to the server rack and connects it to the patch panel.

2.     Establish local connection to PBX   After installation of the gateway, the next step is to check that the gateway can connect to the local network and transmit packets across the cable. Although there are numerous ways to do this, Microsoft IT accomplishes the test through an Internet Control Message Protocol (ICMP) ping check.

3.     Configure IP addresses   VoIP gateways are placed in a separate VLAN for security, and they block all traffic unless data packets are specifically allowed. To accomplish this, Microsoft IT specifies the assigned IP address to the gateway. The IP addresses are later used during configuration of the VoIP gateway objects on the UM server.

4.     Upload standard configuration to accept calls   Microsoft IT creates a standard configuration for all gateways, which includes the basic parameters necessary to accept incoming calls and forward them to a UM server. After installation and configuration of the basic gateway settings, Microsoft IT uploads this standard configuration.

5.     Verify SIP settings   Microsoft IT checks the settings related to SIP communication. The relevant settings include: SIP enabled, TCP (not UDP), port 5060 for TCP, and port 5061 for TCP over Transport Layer Security (TLS).

6.     Set up QoS   To ensure that VoIP packets are comprehensible as voice when reassembled, Microsoft IT specifies a QoS setting on routers to give VoIP packets higher priority.

7.     Test gateway with incoming call   After configuring settings and installing all the hardware, Microsoft IT performs a test call to the gateway. Often, the gateway and PBX require additional configuration before the gateway successfully receives a test call.

8.     Verify that gateway is getting integration information correctly   Integration information is the secondary information (non-voice) associated with a call, such as the number used for caller ID. Microsoft IT verifies that when a gateway receives an incoming call, the gateway also receives integration data. For troubleshooting, Microsoft IT looks at gateway log files to determine the point of failure.

9.     Set up monitoring   The engineering team in Redmond sets up monitoring on the VoIP gateway after the on-site systems integrator configures and verifies the gateway as operational. Gateways support both e-mail alerts and SNMP alerts.

10.   Download PBX details to create migration database   The PBX includes a list of users and extensions. By downloading a list of the users directly from the PBX, Microsoft IT ensures that all users are enabled on Exchange UM.

11.   Upgrade firmware   Before testing for connectivity, Microsoft IT checks with the gateway vendor to ensure that the VoIP gateway runs the latest released firmware. The system integrator on site upgrades the firmware to the latest available.

UM Server Integration

Microsoft IT houses Exchange Server 2007 UM servers in the four major data centers that have Mailbox servers, as shown earlier in Table 2. For each UM-enabled field location, Microsoft IT completes the configuration on gateways and adds dial plans to two or more UM servers in a data center, to provide redundancy. Microsoft IT follows a similar approach with UM server implementation as with other UM components and uses checklists. For each UM server, Microsoft IT takes the following steps:

1.     Create/configure UM dial plan   The dial plan is specific to each site and includes the access number and extension pattern for a location. For more information about dial plan configuration, see the later section "Dial Plan."

2.     Create/configure UM VoIP gateway   Microsoft IT explicitly specifies VoIP gateway in the UM configuration so that UM servers can communicate with VoIP gateways. For more information about VoIP gateway configuration, see the later section "VoIP Gateway."

3.     Create/configure UM mailbox policy   Mailbox policy, including PIN policy and dialing restrictions, is part of the UM server configuration. For more information about mailbox policy configuration, see the later section "Mailbox Policy."

4.     Create/configure UM hunt group   UM servers use a hunt group to link a pilot number ID to a dial plan. For a UM server to answer a call on a particular number, the number must be specified in the hunt group. When the IP gateway initiates a session with the UM server by using SIP, part of the SIP header includes the pilot number. The UM server verifies that the number in the SIP header is part of a particular hunt group and accepts the call. For more information about hunt group configuration, see the later section "Hunt Group."

5.     Create UM dialing rules   Microsoft IT creates appropriate dialing rules and properties for each location. For more information about dialing rules, see the later section "Dialing Rules."

6.     Assign UM dialing rules to dial plan and to mailbox policy   After creating dialing rules, Microsoft IT assigns the rules to the dial plan and to the mailbox policy.

7.     Generate GAL Grammar   A speech grammar file contains words and phrases that the speech engine will try to recognize when the grammar file is used. Grammar files define things such as the commands that are available to users while they are reviewing their mail, or their calendar, or the names of people who are recognized by the speech engine when a caller searches the directory. By default, grammar generation occurs daily at the time specified by the GrammarGenerationSchedule parameter of the unified messaging server. By default, the schedule is defined so that grammar generation will start at 2:00 A.M. each day. However, the grammar generation schedule can be changed and is controlled via the Set-UMserver cmdlet in the Exchange Management Shell. Microsoft IT generates grammar files by running the galgrammargenerator.exe command to create the first grammar files.

Dial Plan

There are two ways to create a dial plan on a UM server: through Exchange Management Console or through Powershell. When creating a dial plan through Exchange Management Console, a default mailbox policy is also created. For greater control, Microsoft IT creates the dial plan on UM servers by using the following Powershell command:

New-UMDialPlan - Name DialPlanName -NumberOfDigitsInExtension 5 -GenerateUMMailboxPolicy $false

After creating the dial plan, Microsoft IT configures the dial plan settings and options through Exchange Management Console. All the UM-related Active Directory objects are located on the Organization Configuration tab, under Unified Messaging. The dial plan properties include the following options:

• General  The UM Dial Plan General tab includes an option to send a non-delivery report if message delivery fails. Microsoft IT keeps the default setting: off. Microsoft IT also enables users to receive faxes.
• Subscriber Access   Although it is possible to create a custom welcome greeting and apply it when a user connects to the UM system, Microsoft IT retains the default greeting. This tab also includes an Associated Subscriber Access Numbers list option. When Microsoft IT initially enables a user for UM, or when a user resets the PIN by using Office Outlook 2007 or Office Outlook Web Access, an e-mail message that contains these access numbers is sent to the user. Microsoft IT includes both the full number with area code and the extension number.
• Dial Codes   The UM server uses dial codes for phone number filtering and dial string modification for outgoing calls or transferring calls. For example, for North American locations, the settings include the following codes:
  • Outside line access code: 9
  • International access code: 011
  • National number prefix: 1
  • Country code: 1

  Although this tab includes the options to specify incoming configuration, Microsoft IT leaves the default settings.

• Features   The Features tab determines the actions that users and callers can take when calling a dial plan. The options include the following:
• Allow callers to transfer to users   This option enables callers to dial extensions and transfer to an extension inside the organization.
• Allow callers to send voice messages   With this option, when the call destinations are not available, the callers have the option to send a voice mail attachment to the destination.
• Callers contact list selection   This enables the administrator to select an address list that is available for a dial plan by default. For the Redmond location, Microsoft IT configures the Dial Plan default Contact list setting to GAL. For Silicon Valley and other field sites, Microsoft IT configures the setting to Within This Dial Plan.
• Matched name selection method   In addition to matching the display name, UM servers can match other selection methods, such as title, department, location, and alias. Microsoft IT sets this option to Prompt for Alias.
• Settings   The Settings options determine the dial-by-name method and other call settings. Microsoft IT uses the default settings for all options except the Default Language option. This depends on the language most prevalent in each location. Microsoft IT also configures the Operator extension option, to enable callers to dial 0 and reach an operator.

VoIP Gateway

The VoIP gateway configuration requires the IP address or fully qualified domain name (FQDN) of the VoIP gateway, depending on the options chosen. For example, TLS requires using the FQDN. Although it is possible to create the VoIP gateway entry by using Exchange Management Console, Microsoft IT creates the gateway by using the following Powershell command:

New-umipgateway -name IPGatewayName -IPAddress xx.xx.xx.xx

Mailbox Policy

Microsoft IT creates a mailbox policy by using Powershell and later uses Exchange Management Console for configuring options. The following Powershell command creates a mailbox policy and assigns it to a dial plan:

new-ummailboxpolicy -name UMMailboxPolicyName -umDialplan UMDialPlanName

Exchange Management Console includes the following configuration options:

• General   Microsoft IT uses this option to specify the name and maximum greeting duration. Microsoft IT chose a maximum greeting duration of five minutes.
• Message Text   The options in this section enable Microsoft IT to specify some of the standard messages sent to users. The messages can include basic HTML tags for formatting. The options are:
• Fax identity   By using this option, Microsoft IT specifies the message body of an e-mail message with a fax attachment.
• Text sent when a UM Mailbox is enabled   By using this option, Microsoft IT specifies the message sent to a new UM user.
• Text sent when an Outlook Voice Access PIN is reset   By using this option, Microsoft IT specifies the message sent to existing UM users after a PIN reset.
• PIN Policies   Microsoft IT maintains a security policy for PINs, including such factors as minimum PIN length, PIN lifetime, number of previous PINs to disallow, number of incorrect PIN entries before PIN is automatically reset, and number of incorrect PIN entries before UM mailbox is locked out. To best meet security needs, Microsoft IT changes some default settings.
• Dialing Restrictions   The options for this setting specify any restrictions in dialing. Microsoft IT allows calls between users within the same dial plan and allows calls to extensions. Microsoft IT also regulates dialing restriction by applying the rules specified for the dial plan.

Hunt Group

UM servers answer an incoming call only when the number is explicitly defined. To do this, Microsoft IT adds a hunt group under the gateway, and then assigns the pilot number to it. Microsoft IT accomplishes this through the following Powershell command:

New-UMHuntGroup -name UMHuntGroupName -IPGateway IPGatewayName -UMDialplan UMDialPlanName -PilotIdentifier XXXXX

The number of hunt groups required depends on the number of pilot numbers for the voice system. Microsoft IT obtains this number from the local telecommunications team.

Dialing Rules

Dialing rules operate on two levels: the dial plan level and the mailbox policy or UM Auto Attendant level. Before enabling dialing rules on the mailbox policy or UM Auto Attendant level, Microsoft IT creates dialing rules on the dial plan level.

The Dialing Rules option includes three configuration settings:

• Name   Mailbox policy configuration settings require the name of a dialing rule to apply the dialing rule. However, multiple dialing rules can use one name. This enables Microsoft IT to configure enterprise-wide dialing rules by placing all rules for a desired behavior in a single name. For example, a dialing rule with the name NorthAmerica can include many rules. Microsoft IT can enable this rule in the mailbox policy settings and apply all rules associated with the name.
• Number Mask   A UM server uses this setting to determine the number to manipulate. For example, 91206xxxxxxx means that when UM processes any number that starts with the string 91206 and has seven digits after the string, the number is allowed and the UM server may manipulate the digits according to the settings.
• Dialed Number   After a UM server allows a number from the Number Mask setting, the Dialed Number setting determines what number the UM server dials through the gateway. For example, outgoing calls may require the prefix 9. With a number mask of 1xxxxxxxxxx for outgoing calls, the dialed number must be 91xxxxxxxxxx so that the PBX forwards the call to the telecommunications provider.

UM Testing

After installing and configuring the UM server and VoIP gateway, Microsoft IT tests the UM environment by using a test account and a pool of test users. Before Microsoft IT uses the test account, the engineering team in Redmond creates the account, requests a mailbox for the account, and creates an extension for the pilot number. For more information about the pilot number, see the later section "Pilot Number and Production Rollout."

By the time Microsoft IT performs a detailed test of the UM environment, Microsoft IT engineers have already verified that the PBX correctly forwards incoming calls to the gateway and that the gateway routes calls to the UM server. At this point, Microsoft IT tests the environment by using a checklist, as shown in Table 11. The checklist includes multiple scenarios for testing a specific UM functionality. Microsoft IT records the result, and if a test did not pass, provides a reason.

Table 11. UM Testing Checklist

UM Redundancy Testing

Microsoft IT designed the UM environment to have redundancy on both the gateway layer and the UM server layer. To verify redundancy, Microsoft IT conducts the tests shown in the checklist in Table 12. These tests confirm the fault tolerance and load balancing (load balancing is available only on Intel gateways).

Table 12. Redundancy Testing

Troubleshooting

For Microsoft IT, the most common configuration tasks that required additional troubleshooting involve the connection between a VoIP gateway and a UM server. Other deployment steps, such as line provisioning and UM configuration, follow a pre-staged deployment model and usually work as expected. Microsoft IT engineers rely on analyzing SIP traffic to troubleshoot the connection between the UM server and the VoIP gateway after successfully configuring a PBX to forward calls to a VoIP gateway through the Call Forward No Answer (CFNA) setting.

SIP is an application layer protocol that handles the setup, modification, and teardown of multimedia sessions based on a request and response model similar to other application layer protocols, such as Hypertext Transfer Protocol (HTTP). SIP handles communication between clients that send requests and servers that respond to requests. SIP clients and servers can be either software applications or hardware devices. Servers in the SIP model can have three different roles: a proxy server that forwards, a redirect server that accepts a SIP request and conveys to the client how to route the request, and a registrar server that accepts registration requests and maps a client's address to a user's sign-in name or SIP Uniform Resource Identifier (URI).

A SIP message is either a request from a client to a server or a response from a server to a client. Both the request and the response contain a start line followed by one or more headers and a message body. For example:

message = start-line

*message header

CRLF

[message-body]

The request start line specifies the type of request being issued, whereas the response start line indicates the success or failure of a request. If a request is not executed, the status line indicates the type of failure or the reason for the failure.

SIP includes a number of message headers in a SIP message. These headers contain information that enables the receiver to understand the message better or handle the message properly. Some headers make sense only in certain requests or responses. In some cases, the presence of a particular header depends on the context. The presence of a particular header in a response might be reasonable only if a server issues a response to a specific request. SIP includes the following header types:

• General headers   These headers can be used in both requests and responses and contain basic information. For example, the To header field indicates the recipient of the request, From indicates the originator of the request, and Call-ID uniquely identifies a specific invitation to a session.
• Request headers   These headers apply only to SIP requests and are used to provide additional information to the server about the request or the client. For example, Subject can be used to provide a textual description of the topic of the session. Priority is used to indicate the urgency of the request, such as emergency, urgent, normal, or nonurgent.
• Response headers   These headers apply only to response (status) messages and are used to provide further information about the response that cannot be included in the status line. For example, Unsupported is used to identify those features that are not supported by the server. Retry-After indicates when a called user will be available if the user is currently busy or unavailable.

When a VoIP gateway receives a call from the PBX, the gateway converts the call to IP and sends a SIP over TCP invitation on port 5060 or 5061 to the specified UM server. The SIP header for an incoming connection resembles the following.

Via: SIP/2.0/TCP 192.168.1.100;branch=z9hG4bKac1124052971;alias
Max-Forwards: 70
From: "202" <sip:202@audiocodes.com>;tag=1c1124045050
To: <sip:137@192.168.2.2>
Call-ID: 11247346074516006141233@192.168.1.100
CSeq: 1 INVITE
Contact: <sip:202@192.168.1.100;transport=tcp>
Supported: em,100rel,timer,replaces,path
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Diversion: <tel:137>;reason=user-busy;screen=no;privacy=off
User-Agent: Audiocodes-Sip-Gateway-MP-118 FXO/v.4.80A.032
Content-Type: application/sdp
Content-Length: 321

Microsoft IT checks the information found by logging SIP traffic with such tools as SipLogger and SipParser. The preceding SIP invitation header contains three critical fields in the header used to route the call, as follows:

• From field   This field enables caller ID.
• To field   The data after the at sign (@ ) in this field is used to locate the VoIP gateway and the TCP port. The value that follows sip: denotes the subscriber access number or pilot identifier.
• Diversion field   The details in this field specify the mailbox number to access in case of a specific type of a response, such as no answer, in addition to mailbox preference details.

Microsoft IT checks the values for the From, To, and Diversion fields to ensure that they match the expected values from configured settings. If any value does not match, the engineer responsible for configuration returns to the settings on the PBX, VoIP gateway, or UM server and checks the associated settings, such as user extension and forwarding.

Pilot Number and Production Rollout

Before going live with large numbers of users for UM, Microsoft IT enables a small group of users and further tests UM performance and functionality. To accomplish this, Microsoft IT creates a pilot number and assigns extensions to users. More specifically, Microsoft IT follows the following steps for testing the UM environment with a pilot number:

1.     Change the hunt group and Field Designator Number (FDN) to the new Exchange pilot number.

2.     Change the Voicemail Access key to the new Exchange pilot number.

3.     Notify teams to prepare for test/pilot users.

4.     List any changes to local pilot numbers and support contacts in appropriate documents.

5.     Notify test/pilot users of test time frame and information.

6.     UM-enable local test/pilot users and send Welcome e-mail message.

7.     Capture performance metrics.

8.     Enable Test-UMConnectivity task in Microsoft Operations Manager for new site and gateways for service availability.

9.     Notify teams on the status, performance, and progress of test/pilot deployment.

10.   Complete rollout to all users for the location.

User Support and Education

For Microsoft IT, Exchange Server 2007 UM features provided an opportunity to empower users with anytime, anywhere access to messages. To provide users access to the new features and environment, Microsoft IT not only designed and implemented the infrastructure, but also created an information and support repository for users. This repository consisted of help documents located on the corporate intranet, which detailed step-by-step instructions for performing common UM tasks, in addition to configuring and customizing the environment by using Office Outlook or Office Outlook Web Access. To inform users about the available documentation, Microsoft IT specifies a custom e-mail message in the UM server configuration that contains links to documentation. UM servers send this custom message when Microsoft IT enables users for UM services notifying users of the initial PIN. In addition to this e-mail message, Microsoft IT also sends out two more e-mail messages. The first e-mail message notifies the user of the upcoming UM migration, whereas the second e-mail message notifies the user of the completion of UM migration.

To enable users for UM services and assign them extensions, Microsoft IT performs the following tasks:

1.     Notify users about plans   Before performing system changes and enabling users for Exchange Server 2007 UM, Microsoft IT sends communication that includes the planned changes, the time frame for migration, details about new features, and what users should expect.

2.     Enable users in Exchange for UM   After notifying users, Microsoft IT enables them on UM servers. This includes assigning a temporary PIN and sending an e-mail message that explains the next steps and available customization options.

3.     Redirect and test extension   After completing setup in Exchange Server 2007, Microsoft IT instructs the proper team to redirect the voice mail routing for each user's extension to the UM server.

4.     Notify users about the migration   The last step is to notify each user about completing the migration. In this communication, Microsoft IT also includes links and further instructions for configuring settings or learning more about the new system.

Disaster Recovery and Redundancy

Microsoft IT designed the Exchange Server 2007 UM environment with redundancy in mind. There are multiple failover points and built-in load balancing to handle the voice and fax data. Microsoft IT minimizes the impact of disasters by having multiple devices and connections that handle messages and calls. Specifically, Microsoft IT relies on the following components for redundancy:

• PBX   The PBX first processes incoming calls. Therefore, port availability determines whether the PBX sends a call to the VoIP gateway. For incoming calls, PBXs have a pool of ports to use, which are chosen sequentially. If a port is unavailable, a PBX tries the next port. If a port is repeatedly unavailable, the PBX considers the entire trunk as unavailable and stops using it.
• VoIP gateway   The two gateway vendors that Microsoft IT uses, AudioCodes and Intel, have varying capabilities for load balancing and fault tolerance. Intel gateways support both load balancing and fault tolerance. For example, when connected to multiple UM servers, VoIP gateways distribute the load through round robin. AudioCodes gateways do not by default support load balancing.
• UM server   Microsoft IT spreads each site dial plan across at least two servers, ensuring that if one server stops functioning, the other can continue until both are brought online. Exchange Server 2007 UM servers store most of the configuration data in Active Directory, thus ensuring that new servers can be deployed rapidly in case of disaster.

Best Practices

Implementing the Exchange Server 2007 UM environment at Microsoft required not only careful planning and design, but also a deliberate implementation that resulted in uninterrupted service for users. In its experiences, Microsoft IT developed the following best practices to use when planning for and deploying Exchange Server 2007 UM servers. Although Microsoft is a unique environment, these general best practices apply to other organizations as well.

• Gather user and business requirements   For Microsoft IT, keeping the user and business needs in mind is key for a successful UM design and deployment. Microsoft IT thoroughly analyzed user and business needs by determining what UM features are critical, choosing proper server hardware to support projected use, and supporting users during the migration to Exchange Server 2007 UM.
• Maintain documentation   In a multi-site implementation of Exchange Server 2007 UM, as well as for single site deployments, it is vital to document configuration settings, design consideration, technical notes, and similar details. Microsoft IT prepares and maintains a master reference document that includes all server, gateway, dial plan, port, and access number information for each site. Additionally, the reference document includes support contact information for relevant people at each site.
• Create custom user help   Microsoft IT prepared communications for users that include links to intranet help sites with reference material, feature how-tos, setup instructions, and configuration instructions. Additionally, Microsoft IT customized e-mail messages that UM servers send when a user is enabled for UM services or for PIN reset requests, with intranet site links for more help.
• Use test accounts   For testing, Microsoft IT creates test accounts, associated mailboxes, and extensions on each dial plan and PBX. This enables real-time testing and troubleshooting in the production environment for each location.
• Plan   For businesses and messaging environments of all sizes, it is important to analyze the risks, dependencies, technical requirements, and trends for proper provisioning, hardware sizing, and workflow.
• Test before production   Microsoft IT deploys sample configurations and software builds in a test environment, and then tests configurations against typical loads to determine stability and analyze results. By testing Exchange Server 2007 UM servers before putting them in a live environment, Microsoft IT can minimize problems and their impact on users.
• Verify deployment   Microsoft IT verifies that UM features function properly after deploying UM servers. By following a testing script, Microsoft IT ensures proper functionality across the entire enterprise.
• Create IPsec exemptions   When using IPsec policies on the network, Microsoft IT excludes the VoIP gateways and UM servers from the IPsec policy. This ensures that voice transmissions meet the required quality of service.
• Maintain low bandwidth latency   The maximum suggested latency for any UM connection is 150 milliseconds (ms) for one-way communication. Long latencies are especially noticeable with long-distance connections. Microsoft IT maintains low latency by provisioning high-bandwidth connections and by creating a QoS rule on the firewall.

Conclusion

Exchange Server 2007 Unified Messaging presents an opportunity for Microsoft to build an infrastructure that moves toward next-generation VoIP telephony and communication. Exchange Server 2007 UM helps to foster a company-wide culture of easy-to-access e-mail, voice mail, and fax while employees are on the road, in the office, and at home. With Exchange Server 2007 UM, Microsoft IT can easily extend UM services to hundreds of field sites because VoIP gateways can communicate to the IP network and function by using IP connectivity. Through VoIP technology, servers can be concentrated to just a few locations, reducing administrative overhead.

Microsoft IT approached the situation of migrating to Exchange Server 2007 UM with both technical requirements and user needs in mind. For example, instead of decommissioning the previous systems and doing an overnight migration, Microsoft IT opted for a period of coexistence and staged migration, with extensive testing that used both test account and live pilot users. By using this approach, Microsoft IT provided a smooth transition process for users while verifying environmental reliability.

Microsoft IT also systematically chose the components for the UM environment by analyzing technical requirements and matching them with the available hardware, software, and configurations. For example, the different number of users at each location, combined with the available connectivity, required Microsoft IT to use multiple VoIP gateways and not a single gateway type at each site. To maintain consistency between sites, Microsoft IT developed model designs and used them for all sites; the model chosen depended on the characteristics of the location.

After deploying Exchange Server 2007-based UM in the Redmond location and migrating worldwide sites to Exchange Server 2007 from the third-party UM system, Microsoft IT plans to extend the features of Exchange Server 2007 UM to other users and locations. This will enable unified messaging to spread company wide and provide users with the next generation of messaging and productivity features. With VoIP gateways in place, Microsoft IT can quickly deploy the infrastructure at each site and enable users for UM.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/technet/itshowcase

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.

© 2007 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, Outlook, Windows, Windows Media, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

All other trademarks are property of their respective owners.

Appendix A: Erlang Traffic Analysis

Erlang traffic analysis provides a mathematical model of competition for a limited number of ports. Such analysis been used for many years for circuit-switched telephony equipment. It is important to note that this served as a beginning reference point for server sizing. Actual server loads gathered during testing and user needs ultimately determine the best server hardware and number of servers to use.

Traffic Analysis

When designing the UM servers and their place in the UM environment, Microsoft IT considered the existing traffic to provide a server that both helped meet service needs and was cost effective. Before choosing a traffic model for determining the load and initial server specifications, Microsoft IT analyzed existing traffic by using the following factors:

• Traffic load   Microsoft IT measured traffic load by using the number of calls and the average hold time (AHT). The AHT is the total time of all calls for a set period divided by the number of calls in that period. For example, if 100 callers spent a total of 5,000 seconds using the system, the average hold time load is 50 seconds (5,000/100=50). To further calculate the traffic load, Microsoft IT calculated traffic in Erlangs (the traffic load of a circuit for 3,600 seconds) by multiplying the number of calls by the AHT and dividing by 3,600. For realistic results, Microsoft IT measured the traffic load at the busiest hour.
• Service level   Microsoft IT measured the service level as the probability (P) of finding all ports busy. A value of P = 0.01 means that a caller trying to reach UM in the busiest hour of the day will, on average, have a 1 percent probability of getting a busy tone instead. Higher values of P therefore correspond to lower levels of service.
• Sampling methods   To gather a statistically accurate sample of the traffic, Microsoft IT sampled traffic continuously at 15-minute intervals to determine the system load.
• Distribution   Call distribution refers to the pattern of received calls. For example, calls can be smooth, can peak during certain times, or can come at random. At Microsoft, calls peak during busy working hours.
• Blocked call treatment   When a voice mail system does not process calls immediately when answered, those calls are considered blocked if they are put in a queue, played a tone, or rerouted. Microsoft IT has several options for blocked call treatment: Hold calls in a queue until a circuit is available (lost calls delayed), or block and drop calls where the caller either waits before re-calling (lost calls cleared) or repeats the call (lost calls held). Microsoft IT configures the environment to not place calls in the queue, but rather give a busy tone and let the caller retry.
• Number of sources   The traffic model depends on whether it is assumed that the number of calls is finite or infinite. Microsoft IT assumes an infinite number of possible calls.
• Hold times   Microsoft IT assumes that hold times are exponential because calls typically have short call times.

Based on the assumptions about its environment of a random traffic pattern, an infinite number of sources, clearing blocked calls, and exponentially distributed hold times, Microsoft IT chose the Erlang B model as a basis for calculating traffic loads and subsequent server design, as shown in Figure 6. In this traffic model, B(c,a) is the probability of a blocked call (corresponds to service level), c is the number of circuits, and a is the traffic load in Erlangs.

Figure 6. Erlang B equation

The Erlang B model provides the mathematical solution to a third unknown if any two other variables are known. The Erlang B model calculates any of the following three variables when the other two variables are known:

• Busy hour traffic   For the busiest hour of the day, the total traffic handled by a particular trunk group represents the busy hour traffic. The busy hour traffic is represented in Erlangs (variable a in Figure 6).
• Probability of blocked line (service level)   The probability of finding all ports busy determines the service level. Microsoft IT decided to use a high service level with the probability of .01, where approximately 1 percent of callers encounter a busy signal.
• Required lines   Microsoft IT used the assumed busy hour traffic and desired service level to calculate the number of lines required, which corresponds to the Exchange Server 2007 UM server setting of the maximum number of concurrent calls that a UM server will accept.

Appendix B: PBX Features

Modern PBXs provide a variety of features. Although the exact feature set varies by manufacturer, Table 13 lists some common features along with a description.

Table 13. Common PBX Features

In addition to the common features noted previously for Nortel and Intecom PBXs, Microsoft IT used the Octel Net IVR system. The IVR system was used at the call centers to provide incoming callers with a menu and identify the appropriate service to provide based on caller selections.