Unified Messaging Servers | Planning for Unified Messaging

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

Planning Amount and Hardware for UM Servers

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

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

You can follow these guidelines for UM server planning:

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

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

Inside Track—Voicemail Preview and CPU Scalability

Ankur Kothari

Senior Technical Product Manager, Exchange Server, Microsoft Corporation

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

UM Server Placement

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

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

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

Note

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