• Article

Communications

Deploying Unified Messaging with Exchange Server 2007

Jeff Goodwin

 

At a Glance:

  • Telephony basics
  • Unified Messaging design considerations
  • Migrating your users

So you've decided to deploy Exchange Server 2007 Unified Messaging into your environment. You've installed a Unified Messaging server role, integrated it with your existing PBX, and now you and 10 other employees have voicemail, e-mail, and fax messages stored in Exchange. Once, you

might have considered this to be a major accomplishment. But how do you deploy the same features to thousands of subscribers, spread across multiple sites, without impacting business?

I hope this article will help. I wrote it to help you understand how to deploy Unified Messaging into your environment and to help demystify the telephony concepts associated with such a deployment. If you need assistance with installation, configuration, or features of Exchange Server 2007 Unified Messaging, please refer to the "Unified Messaging Resources" sidebar at the end of this article. In addition, Microsoft has identified companies as Unified Messaging Specialists to assist customers with consulting, design, and deployment of Exchange Server 2007 Unified Messaging. If you need assistance with installation, configuration, or deployment, contact one of these experts, also listed in that sidebar.

Getting Started

Unified messaging technologies are not new to Exchange; many organizations offer unified messaging products that integrate with Exchange. However, this is the first version of Exchange that supports unified messaging natively. Since its introduction, many customers have deployed Exchange Server 2007 Unified Messaging to small groups within their organizations. However, for various reasons, they have not always deployed Unified Messaging to all of their users. One problem is that many Exchange administrators are new to the telephony concepts and technologies required to implement unified messaging services and have been struggling with designing and deploying these solutions into their enterprises.

As with any deployment project, a phased approach typically yields the best results. The five stages—planning the architecture, testing the solution, piloting a user community, training, and migrating users to the new system—are all aspects of a unified messaging project that should be considered. It is critical that you include both IT and telecom groups within your organization when planning the project.

Many features that users take for granted on traditional voicemail platforms must be duplicated or, if that's not possible, an alternative solution should be designed that will lessen the impact on user communities when a new system is implemented. This is a key area that your telecom team must assist you with. At the same time, the telecom team will need to learn from the IT team what it takes to administer, troubleshoot, and support the new voicemail platform as the deployment takes place.

Telephony Basics

You'll find planning to be much easier if you understand the basic architecture, call flow, and terminologies related to unified messaging. Figure 1 illustrates an example unified messaging solution integrated into an existing corporate telephony system. Now let's take a closer look at some of the most common concepts and technologies you are likely to encounter with such a deployment.

Figure 1 A PBX-to-Unified Messaging solution

Figure 1** A PBX-to-Unified Messaging solution **(Click the image for a larger view)

A Private Branch Exchange (PBX) is a private telephone network used within an enterprise. On such a system, each user typically has a desk phone connected to the PBX, from which calls can be placed to other internal users by dialing an extension (typically four or five digits) and to external phones.

When enterprise customers have many locations with PBXs, they sometimes decide to connect the systems together through networking technologies specific to the PBX vendor. This allows all users on the networked PBXs to call each other by dialing just an extension.

Unified messaging involves the integration of two disparate systems: Exchange messaging and the physical telephony system. The communications between the Unified Messaging server and the telephony architecture is accomplished using Session Initiation Protocol (SIP). Some PBX technologies can communicate directly with the Unified Messaging server over SIP; others will require a SIP gateway. In Figure 1, the PBX is connected to a SIP gateway via a T1 line. When a call is forwarded to Unified Messaging, the PBX sends information (calling party phone number, called party phone number, and some type of reason code) to the SIP gateway so that the Unified Messaging server will understand who the call is for.

Some PBXs can be networked together over the IP network. Telephony networking provides the ability to have calls redirected over the IP network to a centralized voicemail solution. For example, if you look ahead at Figure 2, you'll notice that Zurich is networked back to London.

Figure 2 A more complex Unified Messaging deployment

Figure 2** A more complex Unified Messaging deployment **(Click the image for a larger view)

Call Flow

Unified Messaging Resources

Suppose a call is placed to a Unified Messaging subscriber phone from an external caller. In this case, the Unified Messaging subscriber is not in the office and the phone goes unanswered. You can follow the path of the message in Figure 1.

The PBX sends the call to the SIP gateway, which negotiates the call via SIP over TCP with the Unified Messaging server. The server receives integration data from the SIP gateway that tells it who the call was for. The Unified Messaging server then plays the subscriber's greeting and allows the external caller to record a message. That message is then delivered to the Unified Messaging subscriber's Exchange mailbox.

This call flow is an over-simplified description of what transpires. It is important to understand that when a message is recorded, the Unified Messaging server forwards the message to the Hub Transport server via SMTP for delivery to the Mailbox server.

As Unified Messaging subscribers, users now have access to their Exchange mailbox via a telephone (using Outlook® Voice Access) or computer (using Outlook 2007 or Outlook Web Access). But subscribers can also access messages via phone using Outlook 2007 or Outlook Web Access with a feature called Play on Phone, which lets the subscriber have Unified Messaging play the selected message by ringing a specified phone rather than accessing it through the computer. When this method is used, the Unified Messaging server interacts with both the Client Access server and the Mailbox server. This is important to understand because, if you place a Unified Messaging server in a remote office that does not have a local Client Access server, the Unified Messaging server will need to traverse the WAN to contact the Client Access server, and this can cause slow performance.

System Design

There are two core Exchange architectural designs that customers fall into: centralized or decentralized. As a general rule, the Unified Messaging architecture will follow your Exchange architecture, meaning that anywhere you deploy a Mailbox server, a Unified Messaging server will also be deployed. Of course, there are exceptions to any rule.

When designing your Unified Messaging architecture, there are five basic areas you have to consider.

  • Server placement
  • Number of Unified Messaging servers
  • SIP gateway
  • Mailbox storage
  • Unified Messaging site configuration

And don't overlook business continuity. As a general rule, your disaster recovery plan related to Exchange can be used to determine elements relevant for Unified Messaging.

Sample deployment scenarios can help you understand Unified Messaging server roles. Figure 2 clearly illustrates a large enterprise deployment of Exchange Server 2007 with Unified Messaging.

In this more complex design, the primary datacenters are Seattle and London. Unified Messaging servers in these locations serve their respective user communities since the Mailbox and Hub Transport servers are local. Both sites have IP PBXs that provide call coverage to the local Unified Messaging server for call answering.

Medium-sized sites are located in New York and Glasgow. Unified Messaging servers in these locations serve their respective user communities since the Mailbox and Hub Transport servers are local. As with the primary datacenters, both sites have IP PBXs that provide call coverage to the local Unified Messaging server for call answering.

Smaller sites have no localized Mailbox or Hub Transport servers but provide Unified Messaging capabilities from the primary datacenters. Austin has an NEC PBX that uses analog connectivity to a local SIP gateway. Calls to local end users are forwarded to the SIP gateway, which negotiates with the Unified Messaging server in Seattle to provide call answering on Unified Messaging.

Zurich has an Avaya Communication Manager that is networked over the IP network to the Avaya Communication Manager in London. Calls to local users are forwarded across the Avaya Communication Manager network, which negotiates with the Unified Messaging server in London to provide call answering on Unified Messaging.

In this example, the Seattle site has Exchange Mailbox servers and Unified Messaging servers in the same physical location. When dealing with a single-site architecture, all servers (Mailbox, Unified Messaging, Client Access, and so on) and PBX equipment are contained within the same site. Corporations with multiple sites add complexity to the design. This complexity can seem overwhelming, but, with proper understanding of the some basic Unified Messaging principles, it becomes manageable.

As shown in Figure 2, if a site contains a Mailbox server, the recommendation is to place a Unified Messaging server there also. Seattle, London, New York, and Glasgow all fit this design. Neither Austin nor Zurich has a Mailbox server locally, but Unified Messaging services can still be supplied to these locations by utilizing the IP network. Austin has a local analog PBX. In this case, a SIP gateway must be used to provide the IP network connectivity to the Unified Messaging server in Seattle. Zurich has a local IP PBX that is connected back to the London PBX over the network. Thus, calls to a user in Zurich would traverse the telephony network back to the London PBX and the Unified Messaging server.

Since calls placed to subscribers in Zurich traverse the network and are handled by a centralized Unified Messaging system in London, if the network experiences an outage, calls to all subscribers in Zurich will go unanswered until the network is repaired. If local survivability is required in the event of a network outage, a Unified Messaging Server could be placed in Zurich. In the event of a network outage, the Unified Messaging server will continue to answer calls and will deliver them when the network is repaired.

Server placement is probably the most important factor to consider when designing an architecture to fit your environment. The flowchart in Figure 3 should assist you in determining proper server placement.

Figure 3 Determining server placement

Figure 3** Determining server placement **(Click the image for a larger view)

Estimating Server Needs

The next area to consider is how many Unified Messaging servers you need in order to support your user community. The answer to this really depends on several factors that are site-specific.

Unified Messaging scalability is determined by how many concurrent calls (called ports in the telephony world) the server can support. Each call into the system requires the Unified Messaging server to dedicate network, CPU, memory, and disk resources. By adding to these resources, a Unified Messaging server can support more concurrent calls. Since such resources are always limited, the Unified Messaging server can only handle so many concurrent calls at once before the resources become overloaded.

You can determine how many ports are required to support the number of subscribers by using Erlang traffic analysis calculations, which I won't delve into here. An easier way to determine how many ports are required is to simply ask your telephony administrator how many voicemail ports are being used on the existing voicemail system. Based on field experience, the port requirements on a traditional voicemail system and a Unified voicemail system should be very similar.

I generally recommend implementing no more than 60 ports on a single server. This has nothing to do with software or hardware limitations. Rather, it is based on the fact that a single server with 60 ports can support approximately 5,000 users. If that single server experiences an outage, you have just inflicted a single-server failure on your entire (very large) subscriber base.

When implementing Unified Messaging servers, you may want to consider designing an N+1 redundancy into the architecture. Figure 4 shows a completely redundant server and SIP gateway design. Using this design, if Unified Messaging Server 1 experiences an outage, calls from SIP Gateway 1 will negotiate calls with Unified Messaging Server 2 automatically. You can also program the PBX to distribute the call load evenly among the SIP gateways. For example, the first call into the system could be routed to SIP Gateway 1 and the next call into the system could be routed to SIP Gateway 2. Alternating calls among the gateways provides for even call distribution and load sharing among the Unified Messaging servers.

Figure 4 Distributing calls between servers for redundancy

Figure 4** Distributing calls between servers for redundancy **(Click the image for a larger view)

There are currently two SIP gateway providers that are supported for Exchange Server 2007 Unified Messaging solutions: AudioCodes and Dialogic. If SIP gateways are required in your design, make sure you purchase one that supports the number of sessions (ports) required by your design. For example, if your design requires 32 ports, you need a gateway that supports at least that many sessions.

If you are wondering whether your PBX will work with Unified Messaging or what gateway you should use, take a look at the "Unified Messaging Resources" sidebar. The links listed there will direct you to specific guidance from Microsoft as well as to a catalog of Unified Messaging Specialists who can help evaluate the specific needs of your organization. Speaking from personal experience, there aren't too many PBXs out there you can't make work with the SIP gateways and Exchange Unified Messaging, and some PBXs can communicate with the Unified Messaging server natively using SIP over TCP.

Exchange Unified Messaging supports three audio codecs for storing voicemail messages: G.711 PCM Linear, GSM 06.10, and Windows Media® Audio (WMA). Each PCM Linear WAV file occupies approximately 16KB for each second of audio. WMA is the default audio codec for Unified Messaging, and it compresses the audio to 1.1 kilobits (kb) for each second of audio with a 7KB header. GSM 06.10 compresses the audio to 1.6 kb for each second of audio, but it has a smaller header than WMA encoding.

Both WMA and GSM 06.10 encoding have acceptable voice quality for voice messages. Based on field experience using either WMA or GSM codecs, you can assume a 10 percent to 20 percent increase in the size of the mailbox store depending on how heavily your organization relies on voicemail.

When deciding which audio codec to use for your environment, keep in mind the mobile devices and other operating systems your end users may be using. Questions on this topic mostly relate to whether users can listen to voicemail on their Windows Mobile® devices. Other operating systems are also a concern: perhaps you have a large deployment of Linux machines that may not be able to play WMA files. Whatever the case may be, realize that such factors will add to the help desk resource requirements that you need to consider when training them.

Configuration and Testing

Whether the Unified Messaging architecture is centralized or distributed, there are many voicemail requirements that must be considered before deploying Unified Messaging into your organization. You'll find a detailed list of topics that need to be discussed by the project team in the "Unified Messaging Checklist" sidebar. The information for all topics should be gathered for each site where you are considering implementing Unified Messaging. Remember, both the IT and telecom teams need to work through these topics together.

After your system has been designed and the configuration finalized, a test system should be put in place to validate the design. In a multisite design, I recommend at least two separate sites be tested to show proof of concept and to validate that the design functions correctly.

A functionality testing plan should be developed from your configuration requirements and then completed. The functionality testing plan should include subscriber access methods (telephone, Outlook 2007, and Outlook Web Access), administration methods, and hardware and network outages.

After testing is completed and everyone agrees that Unified Messaging will duplicate the features of the old voicemail system or that an alternative solution has been designed to support any configuration or feature that cannot be duplicated, a pilot group of users should be selected to test the system. Enabling the pilot group will demonstrate the steps required in your environment to move (or to cut, in telephony jargon) subscribers from the old voicemail system to Unified Messaging. In general, these steps are required to cut a subscriber over:

  1. Disable the subscriber from the existing voicemail system.
  2. Enable the subscriber in Active Directory for Unified Messaging through the Exchange Management Console.
  3. Change the phone's coverage path to a Unified Messaging pilot number.

It is important to disable the subscriber from the existing voicemail system so that no messages are sent to the old mailbox.

During the pilot phase, you should capture any questions your subscribers have regarding the system's functionality. Documenting these details will allow you to address common problems during the training phase.

Training is critical to a successful cut. Your users are accustomed to accessing voicemail from the phone with a specific user interface. For example, some voicemail systems require users to press 5 to listen to messages. Exchange Unified Messaging requires users to press 1 or say "voicemail" (or use Outlook 2007 or Outlook Web Access to play back voice messages). Your Unified Messaging subscriber training should encompass telephony user interface navigation, Outlook Voice Access navigation, and Outlook/Outlook Web Access navigation.

With Exchange 2007 Unified Messaging, the ability to speak the commands is built into Outlook Voice Access. Some users tend to get excited about the new capabilities of the system, and this excitement may help ease the transition from one user interface to another.

Exchange Unified Messaging has the ability to send out a custom text e-mail message to each user as they are enabled. These custom messages can be used to provide valuable Web links to frequently asked questions (FAQs), subscriber documentation, help desk phone numbers, and so on. They may also contain information about how to access the voicemail system and the subscriber's unique password. This is one of the most powerful features you can take advantage of when enabling your end users.

Migrating Users

Unified Messaging Checklist

The following sections define some basic elements of a Unified Messaging system and suggest questions that need to be answered in preparation for deploying and configuring Exchange Server 2007 Unified Messaging. Use this as a checklist for developing a deployment plan.

Dial Plans A Unified Messaging dial plan logically corresponds to a PBX and the associated extensions. Some aspects of your dial plan to consider in advance are:

  • How many digits are there in the extension numbers?
  • What is the pilot number of the Unified Messaging system?
  • What do users need to dial to get an outside line?
  • Which audio codec will you use for messages?
  • What is the extension number of the company operator?

Hunt Groups and Pilot Numbers A hunt group is a set of telephone extensions configured to receive calls in a particular order. The pilot number is the primary extension that is called to access the hunt group. You need the same number of hunt group member extensions as the number of voicemail ports in your design.

Mailbox Policies Voicemail mailbox policies don't differ much from Exchange mailbox polices. Here are some policies you may want to discuss:

  • How many days are voicemails retained before being deleted?
  • How often are voicemail password resets required?
  • What is the voicemail backup policy?
  • What is the minimum acceptable password length?
  • What are the maximum logon attempts before locking mailbox?

Automated Attendant (AA) Automated attendants answer incoming calls that are not destined for a specific subscriber. They can provide information and direct callers to locations within the organization. Exchange Unified Messaging provides DTMF and speech capabilities for AA navigation. Factors to consider include:

  • Are there different AA prompts for daytime, nighttime, and holidays? (Prompts need to be documented and recorded.)
  • Who can be dialed from the AA menu?
  • Can speech navigation be be a capability when using AA?
  • Are multiple languages required in order to use AA?

General or Night mailbox Some organizations have a general or night voicemail box that allows callers to leave general delivery messages. If your company has one, an Exchange mailbox must be created and enabled for Unified Messaging.

Message Waiting Indication (MWI) Message waiting indication refers to the light on your phone that alerts you to unread voice messages in your mailbox. Is messaging waiting indication on phone handsets a requirement for deployment?

Multiple Extensions Support Many organizations have employees who have multiple phones. When enabling these subscribers for Unified Messaging, you need to associate all of their extension numbers at that time. Before you start, develop a list of employees with multiple extensions.

Interactive Voice Response (IVR) Support Some traditional voicemail systems support IVR applications that Unified Messaging will not be able to duplicate. Determine whether the system being replaced has any such applications associated with it. Those applications can remain on the existing system or may have to be replaced by alternative IVR applications.

Voicemail Networking Voicemail networking provides a way to send a message from one system to another disparate system. For example, in large enterprises, the CEO may want to send out a voice message to the entire organization, or you might have general information like fire drills to announce. With a voicemail network, the CEO could record a voice message once and send it to every employee in the company no matter what voicemail system they are on. Currently, Exchange Unified Messaging does not have the ability to network to other traditional voicemail systems.

Fax Support Some traditional voicemail platforms support inbound faxing, allowing you to use your single phone number for both voice and inbound faxing. Exchange Server 2007 Unified Messaging supports inbound faxing and can be used to replace that capability. This is a one-way feature; the system does not support outbound fax capability. If that is a requirement, you will need to look at a third-party product to support it.

There are many different views on how to migrate the system into full production. The two primary methodologies are a gradual migration and flash-cut. No matter which you choose, train your help desk personnel on the common questions you recorded from your pilot group. Also, be sure to show them how to enable a user, how to validate that a user is enabled, and how to change a password.

Migrating users from the old voicemail system to Unified Messaging is easy enough, but there is one major issue you need to be aware of: voicemail networking. Just as an e-mail system lets you send, forward, and reply to other e-mail users and systems, so too does voicemail let you send, forward, and reply to other voicemail users and systems.

Consider a scenario where Alice and Brian are currently on the old voicemail system. Brian is migrated to Unified Messaging and wants to send a message to Alice on the old voicemail system. Since the two users are on separate systems, they can no longer send, forward, or reply to voicemail messages from each other; unfortunately, a voicemail island has been created.

The way this issue is resolved with traditional voicemail systems is to use some type of networking protocol converter that allows disparate systems to be networked together. Currently, however, there is no networking protocol converter that allows disparate systems to be networked to Exchange Server 2007 Unified Messaging. While this may not be important to your organization, it is something to be aware of when choosing to migrate users in small groups.

My preference is to perform a flash-cut of all users on a site basis. A flash-cut is a clean break from one system to the other. It often occurs over a weekend; users go home on Friday and come to work on Monday to a new voicemail system. Some administrators say that a flash-cut should be used only for small enterprise customers or remote sites. I disagree. I have been involved with flash-cuts as large 7,000 users at a single location where less than 1 percent of the employees needed to call the help desk for support. If all of the other phases of your project have been planned and carried out well, the cut to a full production system should go smoothly.

When cutting multiple sites into full production, however, consider cutting the smaller remote sites one at a time before cutting the largest site. Review the lessons learned from the smaller sites and implement necessary changes into your project plan.

Typically, all user training should be completed and all users enabled for Unified Messaging prior to cutting the system live. Here is a step-by-step methodology to use to prepare for a flash-cut of a voicemail system.

The first thing to do is validate that the Unified Messaging system is fully installed, configured, and tested.

Perform training in small groups. Explain to users as they attend that their mailbox will be enabled prior to going live on the system, and they are encouraged to log into their mailbox and initialize it by changing their password and recording their greeting. After training is completed, immediately enable these users so they can initialize their mailbox prior to cut.

Finally, when all training is completed, pick a weekend to disable all users from the old voicemail system and forward their phones to Exchange Unified Messaging. On Monday morning, your system is live for all users in your organization.

Making the Cut

Regardless of whether you have a single site to support or a large multisite organization, the information in this article should prove helpful. Multisite organizations can add complexities to the design, but the basic requirements are the same whether you have 50 or 5,000 users.

I can't stress strongly enough that both IT and telecom teams must work together when deploying a Unified Messaging solution. In my experience, of the many things that can derail a Unified Messaging project, discord between IT and telecom and lack of agreement on the solution are predictive of failure. The convergence of technologies isn't that difficult, but it may require someone outside your organization who understands both IT and telecom to help either bring the teams together or plan for a successful project deployment.

Jeff Goodwin is a Senior Technologist at The VIA Group, specializing in Exchange and Unified Messaging design and deployment. You can reach him at his e-mail address: jgoodwin@theviagroup.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.