In the first stage of the call flow, the call should be forwarded from the PBX to the IP gateway, and then from the IP gateway to the Unified Messaging server. If the call isn't forwarded to the IP gateway, the logs from the IP gateway and the PBX should provide troubleshooting information to help you troubleshoot.

Return to top

A call not accepted by the Unified Messaging server is one of the most common issues that can occur in a new deployment. This may also happen when you upgrade firmware. The best resource for this issue is to collect network trace information and analyze SIP traffic between the Unified Messaging server and the IP gateway. Tips and techniques for analyzing network trace information are discussed later in this white paper.

You can also use the Exchange UM Test Phone application to check whether Unified Messaging can receive any incoming calls. Typically, a SIP INVITE request generated by the UM Test Phone application is simple, compared to a SIP INVITE request received from an actual IP gateway. If a call from the UM Test Phone application is failing, that indicates Unified Messaging isn't configured correctly. Verify whether the:

• UM IP gateway with an IP address or fully qualified domain name (FQDN) of the UM IP gateway is created.
  
• Call succeeds with a default UM hunt group. The default UM hunt group allows all pilot numbers.
  
• UM dial plan is linked with one or more Unified Messaging servers.
  

Calls can also fail for other reasons. You can turn on diagnostics logging and analyze the events being generated in the application log. Details about diagnostics logging are discussed later in this white paper. Or, for more information, see Enabling Tracing for Unified Messaging.

Return to top

When Unified Messaging accepts a call, the incoming message is first stored in the \voicemail folder of the Unified Messaging server. This is prior to converting the message to e-mail format.

Every message in the voice mail folder has two parts:

• filename.txt
  
• filename.wav
  

Filename is a random name generated by the Unified Messaging server, and it looks like a GUID. The text (.txt) file and the wave (.wav) file have the same file name (with different extensions). The text file contains the message header, and the wave file is the actual media. If messages remain in the \voicemail folder, Unified Messaging is having problems transferring messages to the Hub Transport server. (Unified Messaging and Hub Transport server issues are discussed in detail later in this white paper.) Consider the following:

• Unified Messaging uses mutual Transport Layer Security (TLS) to communicate with a Hub Transport server. Check to make sure that the Unified Messaging server has a certificate with the FQDN of the server as a subject name or storage area network (SAN). This is required to establish a mutual TLS connection.
  
• Hub Transport servers use extended x-anonymous TLS to transport messages. Run the EHLO command to make sure extended SMTP verbs are present on the transport server.
  
• To help you in troubleshooting voice mail delivery issues, turn on diagnostics logging and view the events logged in the application log. These events dictate the troubleshooting steps described later in this white paper.
  

Return to top

In addition to call flow issues, users may encounter problems. Sometimes, voice mail is delivered to the user's mailbox, but the user is unable to access or play the voice mail message. A user may also be unable to make outbound calls. A user should be able to:

• Access voice mail using Microsoft Outlook or Office Outlook Web Access and clicking the Play button of the embedded media player.
  
• Access voice mail by calling the subscriber access number.
  
• Make outbound calls using the Play on Phone feature from either Office Outlook 2007 or Outlook Web Access.
  

The following sections describe what may go wrong in each of these situations.

Users should be able to access and play voice mail messages using Outlook or Outlook Web Access. For issues with an embedded media player in Outlook or Outlook Web Access, make sure:

• The user has downloaded the compatible version of Microsoft Windows Media Player.
  
• Other media can play on that specific workstation.
  
• The message class isn't being changed. An embedded media player only works for Unified Messaging type message classes, so if you have an application that's changing the message class, it won't work.
  

Return to top

A user can call a subscriber access number and check voice mail using Outlook Voice Access or simple dual tone multi-frequency (DTMF). The first step is to log on to the mailbox using a PIN. If this step fails, the user should be given a new PIN, assuming this is an isolated issue. If all users are having problems with PIN validation, there might be issues with either Active Directory or the Mailbox server. The actual PIN is stored on the user's mailbox (in encrypted format). The checksum of the PIN is stored in Active Directory. The Unified Messaging server must be able to access both Active Directory and the Mailbox server for PIN validation.

If a user successfully passes this stage but still can't check voice mail, there might be something wrong with the mailbox store or the user's mailbox. The best recourse is to log on to the mailbox using Outlook or Outlook Web Access and see if you can play the voice mail.

Return to top

Outbound calls can be generated by a Play on Phone request. Another way to generate outbound calls is by calling Outlook Voice Access and selecting a call recipient from a directory or personal address book. The following figure shows the call flow.

Play on Phone call flow

Here are some troubleshooting tips for Play on Phone issues:

• Play on Phone requests first go to the Client Access server. The Client Access server sends a SIP INVITE request to the Unified Messaging server, and Unified Messaging proxies the request to the IP gateway. The best way to troubleshoot these issues is to perform a network trace on the Unified Messaging server. Note the following:
  
  • Which Client Access server is servicing this request?
    
  • Does the Client Access server send a request to the Unified Messaging server?
    
  • Does the Unified Messaging server send a SIP INVITE request to the gateway?
    
  • Does the gateway accept the SIP INVITE request?
    

  Important:
  The Unified Messaging server and Client Access server use mutual TLS to establish the session. For mutual TLS negotiation, both the Unified Messaging server and the Client Access server must have a certificate that has the corresponding FQDN as the Subject Name or the Subject Alternate Name.

• For calls from a directory, Unified Messaging sends a REFER request to the IP gateway. The IP gateway should be able to handle REFER requests. Network trace is the best resource to troubleshoot this issue.
  
• Outbound calls are restricted by dialing rules. Enable diagnostics logging and review the application log to see if dialing rules are causing any issues.
  

Return to top

When a call is forwarded to voice mail, a request in the form of SIP INVITE is sent from the IP gateway to the Unified Messaging server.

The SIP INVITE request looks like the following.

INVITE sip:2501@65.53.2.181;transport=tcp SIP/2.0Via: SIP/2.0/TCP 65.53.0.18;branch=z9hG4bKac791424417;aliasMax-Forwards: 70From: <sip:2510@ACGWMP118.req150587.local>;tag=1c741078876To: <sip:2501@65.53.0.18;user=phone>Call-ID: 74107850232200073840@65.53.0.18CSeq: 3 INVITEDiversion: <tel:2501>;reason=no-answerContact: <sip:2510@65.53.0.18;transport=tcp>Supported: em,100rel,timer,replaces,path,resource-priorityAllow:REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATEUser-Agent: Audiocodes-Sip-Gateway-MP-118 FXS_FXO/v.5.00A.035.003Content-Type: application/sdpContent-Length: 227v=0o=AudiocodesGW 741070197 741070070 IN IP4 65.53.0.18s=Phone-Callc=IN IP4 65.53.0.18t=0 0m=audio 6010 RTP/AVP 0 101a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=ptime:20a=sendrecv

SDP Header

The SIP INVITE request has a Session Description Protocol (SDP) header with it. Although Unified Messaging supports SIP INVITE requests without SDP, the first SIP INVITE request contains an SDP header. The SDP header contains the media format and the media endpoint.

To Address

In this case, the call is coming from the IP gateway, which has 65.53.0.18 as its IP address. For Unified Messaging to accept this call, there must be a UM IP Gateway object to accept this call. The To header looks like the following.

To: <sip:2501@65.53.0.18;user=phone>

The call is intended for extension 2501, which means there must be a UM hunt group object with pilot number 2501 that matches the To address. If you only have one UM hunt group called the default UM hunt group, it will be used because it accepts all pilot numbers including the 2501 extension number.

The number 2501 is searched for within all the UM hunt groups, and when a match is found, the call is answered. Every UM hunt group is linked to a particular UM dial plan. When a matched UM hunt group is found, Unified Messaging determines the UM dial plan linked to the UM hunt group and assumes that the person being called is within that UM dial plan. In this case, the UM dial plan linked to the UM hunt group is corpdialplan, which has the context (or FQDN) of corpdialplan.proseware.org.

From Address

The From address impacts caller ID resolution. In this example, the From address is the following.

sip:2510@ACGWMP118.req150587.local

The extension is used for caller ID resolution. Caller ID resolution occurs within the UM dial plan that was determined from the To address.

Diversion Header

The Diversion header contains the destination (voice) mailbox's ID or extension. For this example, the Diversion header is the following.

Diversion: <tel:2501>;reason=no-answer

When Unified Messaging processes this incoming request, it searches for a mailbox with the tel type extension within the UM dial plan obtained from the To header. For this scenario, Unified Messaging searches for a UM-enabled user with an EUM type proxy address that matches 2501@corpdialplan.proseware.org.

When the user is found, the SMTP proxy address of the user is retrieved. An e-mail type message is created with an attachment, which is the media file containing the actual voice mail. The message is sent using an Exchange 2007 transport mechanism.

Troubleshooting Tips for the First SIP INVITE Request

Most of the Unified Messaging call answering issues can be resolved by analyzing the first SIP INVITE request from the IP gateway. The first SIP INVITE request gives you a good idea about the rest of the call flow. Consider the following:

• Make sure the request Uniform Resource Identifier (URI) has the IP address of the Unified Messaging server and a valid SIP extension. Also note the transport mechanism.
  
• The IP address of the To header must match the UM IP Gateway object, and the extension must match a pilot number in a UM hunt group.
  
• The user's UM dial plan is determined by the UM dial plan linked to the UM hunt group determined in the previous step.
  
• The From header is used for caller ID resolution.
  
• The SDP header contains the media endpoint and supported media codec information.
  

Return to top

The Microsoft Exchange Unified Messaging service listens to port 5060 (or 5061 for TLS), but the UM worker process listens to port 5065 (or 5066 for TCP). The Microsoft Exchange Unified Messaging service performs the initial call acceptance. After a call is accepted, the next step is to establish the media channel. The UM worker process establishes this media channel. So, the request must now be redirected to the port where the UM worker process is listening. Unified Messaging sends a 302 Moved Temporarily redirection message to the IP gateway. The contact header has the endpoint where the IP gateway should send the new request. For this example, it is the following.

CONTACT: <sip:2501@65.53.2.181:5065;transport=tcp>

The IP address and the extension number remain the same as the first SIP INVITE request URI. However, the port number has now changed to 5065.

Troubleshooting Tips for the Redirection Message

This stage is straightforward: Unified Messaging sends the 302 Moved Temporarily redirection message. If for any reason, the subsequent SIP INVITE request (sent after the 302 Moved Temporarily redirection message) is failing, you can do the following:

• Open Task Manager, and make sure you select the PID column. Check whether UMWorkerProcess.exe is running and check the port number.
  

  Note:
  There may be a brief moment where you see two instances of the UM worker process. This happens when one instance isn't responding. Unified Messaging opens a new instance of UMWorkerProcess.exe and closes the existing one.

• Check the application log for events generated by UMService and UMCore. Make sure the diagnostics logging level is set to Expert.
  

Return to top

After receiving the 302 Moved Temporarily redirection message, the IP gateway sends a second SIP INVITE request to the UM worker process. The UM worker process, after receiving the second SIP INVITE request, starts processing the media portion of the request. For this example, the second SIP INVITE request looks like the following.

INVITE sip:2501@65.53.2.181:5065;transport=tcp SIP/2.0Via: SIP/2.0/TCP 65.53.0.18;branch=z9hG4bKac791578444;aliasMax-Forwards: 70From: <sip:2510@ACGWMP118.req150587.local>;tag=1c741078876To: <sip:2501@65.53.0.18;user=phone>Call-ID: 74107850232200073840@65.53.0.18CSeq: 4 INVITEDiversion: <tel:2501>;reason=no-answerContact: <sip:2510@65.53.0.18;transport=tcp>Supported: em,100rel,timer,replaces,path,resource-priorityAllow:REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATEUser-Agent: Audiocodes-Sip-Gateway-MP-118 FXS_FXO/v.5.00A.035.003Content-Type: application/sdpContent-Length: 227v=0o=AudiocodesGW 741070197 741070070 IN IP4 65.53.0.18s=Phone-Callc=IN IP4 65.53.0.18t=0 0m=audio 6010 RTP/AVP 0 101a=rtpmap:0 PCMU/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-15a=ptime:20a=sendrecv

This SIP INVITE request looks similar to the first SIP INVITE request. The only difference is that it's sent to port 5065 on the Unified Messaging server, as noted in the request URI.

2501@65.53.2.181:5065;transport=tcp SIP/2.0

Notice the SDP header, which is the same as the initial SIP INVITE request. This is important because Unified Messaging expects the same SDP header in both SIP INVITE requests.

Troubleshooting Tips for the Second SIP INVITE Request

For troubleshooting, do the following:

• Check the request URI and the destination port of the IP address header. The port number should match the port number specified in the contact header of the redirection message.
  
• Check the SDP header, which should be similar to the one in the initial SIP INVITE request.
  
• Turn on diagnostics logging, verify the level is set to Expert, and check the application log.
  

Return to top

The call session is finally established when Unified Messaging sends a 200 OK message. With this 200 OK message, Unified Messaging also sends the media information with the SDP header.

m=audio 50944 RTP/AVP 0 101

Important:
The SDP header has the port number where Unified Messaging expects the media traffic.

Note that this 200 OK message must receive an ACK message from the IP gateway. After the ACK message is received, Unified Messaging and the IP gateway can exchange media.

Troubleshooting Tips for the OK Message

Consider the following:

• Unified Messaging doesn't support early media. The IP gateway must wait until the ACK message is sent for the 200 OK message before media exchange can begin.
  
• The Real-Time Protocol (RTP) traffic flows over User Datagram Protocol (UDP). You can filter the network trace to view the RTP traffic. The filter is based on the port number that you got from the SDP header of the SIP INVITE message (for the IP gateway) and the SDP header from the 200 OK message (for Unified Messaging). For example, you can use the following filter for Network Monitor.
  
  (UDP.SourcePort == 6010) || (UDP.SourcePort == 50944) 

  In this case, all traffic coming from 6010 and 50944 over UDP will be captured.
  
• Make sure your firewall isn't blocking RTP communications.
  

Return to top

Probably the best resource to troubleshoot Unified Messaging issues is to use a network trace. You can use the traditional Network Monitor tool (netmon.exe) to capture network traffic between a Unified Messaging server and an IP gateway. Unified Messaging traffic consists of SIP, RTP, and T.38 traffic, and you need to use the associated parsers to view this traffic. The following sections help you understand SIP traffic in a Unified Messaging environment and how to use Network Monitor to troubleshoot messaging network traffic:

• Examples of Set Filters
  
• Setting Filters
  
• Viewing SIP or TCP Conversations
  
• Finding a Specific String
  

Examples of Set Filters

You need to set filters based on the scenario you're analyzing. This example is one of the most common filters.

Sip||rtp || sdp

Basically, the preceding example means capture all traffic that has SIP, RTP, or SDP packets. This captures all the frames for a typical Unified Messaging conversation.

You can also set a filter based on an IP address. This example captures all traffic between the client and the Unified Messaging server.

( IPv4.Address ==<um server ip>)||( IPv4.Address ==<IP address of gateway>)

This example sets up a filter on ports that Unified Messaging communicates with.

(Tcp.port == 5060)||(tcp.port == 5065)||(Tcp.port == 5066)

Note:
Always click Verify before you click Apply.

Setting Filters

Using Network Monitor 3.2 to view the SIP conversation, first filter the trace to apply only to the SIP conversation by using just SIP as your filter. When you set a filter first, click Verify to verify the syntax of the filter, and then click Apply. The following figure is a screenshot that shows the Verify and Apply buttons.

Network Monitor tool showing Verify and Apply buttons

For a busy network, filtering by protocol may still generate many packets. Most troubleshooting that you do will be limited to one call at a time. One of the best ways to filter is to use the call ID as the filter.

Instead of copying and pasting the call ID as the filter, use the following method to add it as the filter. If you already have an existing filter, the new filter string will be added as an OR filter. The following figure shows setting a filter in Network Monitor 3.2.

Setting filter in Network Monitor 3.2

Select a particular SIP method, for example, the SIP INVITE method from the Frame Summary dialog box:

1. Go to the Frame Details dialog box, expand SIP, and then expand Headers.
   
2. Click CallID.
   
3. Right-click, and then click Add Selected Value to Display Filter. The following filter will be added as an OR filter.
   
   SIP.SipParser.Headers.CallID == "call-id-selected"

4. In the Frame Summary dialog box, you only see the frames that contain this call ID.
   

Viewing SIP or TCP Conversations

You can view the entire TCP stream, which can be an entire conversation for SIP. The following figure shows a conversation in Network Monitor.

View conversation in Network Monitor

Follow these steps to view the conversation:

1. Choose a TCP (or SIP) frame from the main capture window.
   
2. Right-click, and then choose the option Find Conversations.
   
3. Select SIP to view the SIP conversation, or select TCP if you want to see the TCP conversation.
   
4. If you want to see all the communication over IPv4, select IPv4. This option is often helpful if you suspect a networking problem or if packets are being dropped.
   

Finding a Specific String

If you want to search for a specific caller, the person being called, or a call ID, you can create a filter using the Contains condition. This example searches for all incoming voice mail calls to extension 2501.

Contains(SIP.SipParser.Headers.DefaultName,"2501")

This example searches for all SIP traffic where the From header contains 2510.

Contains(SIP.SipParser.Headers.From,"2510")

This example searches for a request with a URI that contains 3355.

Contains(SIP.SipParser.RequestLine.RequestURI,"sip:3355")

Return to top

The event log can assist you in troubleshooting Unified Messaging. First, you have to enable diagnostics logging. Then, you can use the event log to:

• Generate events for successful UM calls
  
• Generate events for successful UM startup
  

You can use the Exchange Management Shell or the registry to turn on diagnostics logging. You can use the following procedures, or see How to Enable Diagnostic Logging on a Unified Messaging Server in the Exchange Server 2007 Help documentation.

To use the Exchange Management Shell to enable diagnostics logging:

1. On the Unified Messaging server, launch the Exchange Management Shell.
   
2. Type get-eventloglevel *um* | set-eventloglevel –level Expert.
   
3. Reproduce the event, and collect the application log from the customer.
   
4. To revert, type get-eventloglevel *um* | set-eventloglevel –level Lowest.
   
   [PS] C:\>get-eventloglevel *um* | set-eventloglevel -level expert
   
   [PS] C:\>get-eventloglevel *um*
   
   Identity                                                             EventLevel
   --------                                                             ----------
   MSExchange Unified Messaging\UMWorkerProcess                         Expert
   MSExchange Unified Messaging\UMCore                                  Expert
   MSExchange Unified Messaging\UMManagement                            Expert
   MSExchange Unified Messaging\UMService                               Expert
   MSExchange Unified Messaging\UMClientAccess                          Expert
   MSExchange Unified Messaging\UMCallData                              Expert

You can also set the logging level from the registry. Be careful when using the registry, and as a best practice, export the registry before making any changes. Instead of using the registry, consider using the Exchange Management Shell commands.

Caution:
Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

The following table shows the logging level and the corresponding values.

Logging level for event logging

Set the following categories to a value of 7 to indicate Expert level logging:

• UMWorkerProcess
  
• UMCore
  
• UMManagement
  
• UMService
  
• UMClientAccess
  
• UMCallData
  

Start Registry Editor (regedit). Scroll to the following keys and then set the value of each key to 7:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange Unified Messaging\Diagnostics

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange Unified Messaging\UMWorkerProcess

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange Unified Messaging\UMCore

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange Unified Messaging\UMManagement

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange Unified Messaging\UMService

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange Unified Messaging\UMClientAccess

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchange Unified Messaging\UMCallData

Value: Lowest – 0x00000000 (0), Expert – 0x00000007 (7)

The following figure shows the Registry Editor.

Setting diagnostics logging from the registry

Generating Events for Successful UM Calls

When a call is accepted, Unified Messaging generates events in an application log that indicates the call is accepted. The following shows the sequence of events that's logged while diagnostics logging is set to Expert level. Note that you can cross-reference information like call ID, caller, and diversion in the network trace to analyze and troubleshoot a scenario.

Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMCore 
Event ID:1004
Description:
A call was received with the following parameters: Calling Party: "sip:2550@ACGWMP118.req150587.local", Called Party:"sip:2501@65.53.0.18;user=phone", Diversion Information: "<tel:2501>;reason=user-busy", CallID"266956433262200053445@65.53.0.18".

Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMCore 
Event ID:1006
Description:
The Unified Messaging server has received a call from "2550", with user extension "2501" and a call ID of"266956433262200053445@65.53.0.18".
Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMCore 
Event ID:1084
Description:
The call with ID "266956433262200053445@65.53.0.18" ended because the Unified Messaging server disconnected.



Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMCallData 
Event ID:1170
Description:
Call data: C,266956433262200053445@65.53.0.18,UMServer01,7d9f535a-54e9-4eda-bfdc-60af8c2facad,2009-04-17T19:52:31-04:00,0,00:00:15,24d31066-dcf2-4f75-b5f4-912a5aeede00,"2550","2501",B,A,C,,0,0,0,0,0,0,0,0,0,0 

Generating Events for Successful UM Startup

When you turn on diagnostics logging to the Expert level, you see the following events for UM startup. Important information is logged, such as the port number of the UM worker process and the certificate used for TLS.

Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMService 
Event ID:1114
Description:
The Microsoft Exchange Unified Messaging service will attempt to start in the following mode: TCP and TLS dual mode.

Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMService 
Event ID:1112
Description:
The Microsoft Exchange Unified Messaging service will attempt to use a certificate with the 
following details: IssuerName = "CN=prosCAServer, DC=proseware, DC=org", 
SerialNumber = "722C27C6000000000015", Thumbprint = "BED2404E7EBFA6C63DBB6039B1A6DA83987583F4", 
IsSelfSigned = "False", 
NotValidAfter = "7/12/2009 6:54:26 PM". 
The path to this certificate is "C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging\UMServiceCertificate.cer".

Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMCore 
Event ID:1010
Description:
The telephone interface definitions were successfully loaded from the configuration file: "C:\Program Files\Microsoft\Exchange Server\bin\Root.fsm"

Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMWorkerProcess 
Event ID:1000
Description:
The Unified Messaging Worker Process was started successfully on port "5065".

Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMService 
Event ID:1056
Description:
The state of the Unified Messaging Worker Process Manage has changed. Previous state = "initializing". 
Current state = "Ready and Accepting calls".

Event Type:Information
Event Source:MSExchange Unified Messaging
Event Category:UMService 
Event ID:1037
Description:
The Microsoft Exchange Unified Messaging service has started successfully.

Return to top

You can use several cmdlets in the Exchange Management Shell to test the operation of a computer running Exchange 2007 that has the Unified Messaging server role installed.

When you run the Test-UMConnectivity cmdlet, the Unified Messaging server initiates a diagnostic SIP call, and then returns a health state variable for the Unified Messaging server. The task can be used in two modes: to test only the Unified Messaging server operation or to test the full end-to-end operation (including items such as IP gateways, PBX, and cabling). This cmdlet can only be run locally on the Unified Messaging server.

This example tests the SIP port on a Unified Messaging server.

Test-UMConnectivity -ListenPort  5060

You can also run this cmdlet without any parameters, and it returns the current status of the server. For detailed syntax and parameter information, see Test-UMConnectivity in the Exchange 2007 Help documentation.

The following figure shows this cmdlet without any parameters and shows the output.

Sample of output from Test-UMConnectivity cmdlet

The Get-UMActiveCalls cmdlet returns information about the calls that are active and being processed by the Exchange 2007 Unified Messaging server. If the Get-UMActiveCalls cmdlet specifies either the UM dial plan or UM IP gateway, it will look in Active Directory to determine which Unified Messaging servers need to be contacted. If the Unified Messaging server is specified in the command, the Get-UMActiveCalls command returns the active calls being processed by the server specified.

You can run this command to find active calls and export the results to a .csv file.

Get-UMActiveCalls -Server ServerName | export-csv c:\temp\activecalls.csv

The parameters for this command are optional. For detailed syntax and parameter information, see Get-UMActiveCalls in the Exchange Server 2007 Help documentation.

Return to top

The Exchange Best Practices Analyzer is a set of rules that can check the configuration of the Exchange server. The Exchange Best Practices Analyzer has a set of rules for Unified Messaging. It runs as part of the installation process and checks the prerequisites for Unified Messaging. You can run the tool anytime to check the configuration of the Unified Messaging environment.

The Exchange Best Practices Analyzer checks the configuration in Active Directory. For example, if a Unified Messaging server isn't linked to a UM dial plan, the Exchange Best Practices Analyzer shows this as an error. So this tool works best if you have made configuration changes that aren't working as expected.

Return to top

Custom audio files (used for prompts by the UM dial plan or UM auto attendant) are stored on all Unified Messaging servers. They are published with a mechanism that copies the files from a prompt publishing point. Each UM dial plan has one server (by default, the first server on the UM dial plan) set as the prompt publishing point.

For the Unified Messaging servers that are members of the same UM dial plan, copy the information from the prompt publishing point. By default, the prompt publishing point is a share called ExchangeUM on the first Unified Messaging server to join the UM dial plan. By default, the prompt publishing point is located at C:\Program Files\Microsoft\Microsoft Exchange\UnifiedMessaging\Prompts\Custom.

The prompt publishing point can be moved anywhere that's accessible to all Unified Messaging servers in the UM dial plan. Be sure to back up the contents of the prompt publishing point (all files and subdirectories) on the first sever to join the UM dial plan. The other Unified Messaging servers reload their cached copies from the prompt publishing point, if necessary.

The prompt publishing point for a UM dial plan consists of a top-level directory (named with the UM dial plan's GUID) and zero or more subdirectories, one for each UM auto attendant in the UM dial plan (each named with the UM auto attendant's GUID). The prompts themselves are .wav files, contained in the directory to whose object (UM dial plan or UM auto attendant) they refer.

Return to top

Configuration files contain information about navigation through menus and some global variables. Configuration files are installed when Unified Messaging is installed, and the files shouldn't be changed. If the files need to be changed for business requirements, we recommend that a Unified Messaging specialist make the changes. If these files are changed, they should be backed up using regular file-level backup.

The default location for the .xml files that store configuration data for Unified Messaging is C:\Program Files\Microsoft\Microsoft Exchange\bin\.

The following .xml files are used to store the configuration information:

• Globcfg.xml   This file is used by Unified Messaging for configuration information, such as the languages installed, VoIP platform in use, paths, and other server-specific information.
  
• UMConfig.xml   This file contains all the details about which prompts are to be played in a specific state and the action to take based upon input from the subscriber.
  

Return to top

Grammar files are created when you enable speech recognition. You need to do a file-level copy of all the grammar files under the %UMRoot%\bin\Grammar folder.

If you reinstall a Unified Messaging server, you must use GalGrammarGenerator to generate the grammar files or wait for the next cycle of grammar file generation. If you don't have a grammar file, you won't be able to use an Automated System Recovery (ASR)-enabled UM dial plan or UM auto attendant. Also, if you created grammar files with an exclusion list, you need to restore the files from a backup copy or use the same exclusion list to generate the files.

Return to top

If the server with the Unified Messaging role installed is unavailable, you may need to adjust the prompt publishing point, reinstall the Unified Messaging server, or remove the Unified Messaging server role.

Adjusting the Prompt Publishing Point

If you have multiple Unified Messaging servers, one server is designated as the prompt publishing point. This becomes relevant only if you're using a custom prompt. If the Unified Messaging server with the prompt publishing point becomes unavailable, you need to:

1. Change the prompt publishing point to a different Unified Messaging server.
   
2. Make sure the new server has all the prompt files. If it doesn't, restore the files from a backup copy.
   

Reinstalling the Unified Messaging Server

You reinstall the Unified Messaging server if there's a hardware failure or if the server is migrating to new hardware. In this case, all the configuration settings in Active Directory are still intact, and the server name is the same. The RecoverServer option basically skips the changes made in Active Directory during normal setup, and puts the binaries in place.

Follow these steps to reinstall a Unified Messaging server:

1. Run Setup with the RecoverServer option: Setup /mode:RecoverServer. For more information, see How to Recover a Lost Exchange Server.
   
2. After you recover the server, make sure all services start properly. You can use Administrative Tools from the Start menu to verify that all of the correct services have started such as the Microsoft Exchange Unified Messaging service.
   
3. Check to make sure that the server is linked to a UM dial plan. For more information, see How to Add a Unified Messaging Server to a UM Dial Plan.
   
4. Check to make sure that the UM server is able to receive inbound calls. For more information, see How to Modify the Number of Concurrent Calls Setting.
   
5. Restore the prompt, configuration, and grammar files from file-level backup. For more information, see Using Backup to Back Up and Restore Exchange Data.
   

When you choose the RecoverServer option, Setup looks at the MSExchCurrentServerRoles attribute of the server object in the following container to determine what roles were installed on the server that you're trying to recover:

CN=ServerName,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com

The value of this attribute is the sum of the values associated with each server role. For example, a value of 38 indicates that the server has the Mailbox, Client Access, and Hub Transport server roles installed. The following table shows the server role and role value.

The following shows the optional parameters for recovering an Exchange server.

[/TargetDir, /t]
         Specifies the location to install Exchange Server 2007 files.
         Default: "%programfiles%\Microsoft\Exchange Server"
[/DomainController, /dc]
         Specifies the domain controller that setup will use to read
         and to write to Active Directory. Netbios or FQDN format can be used.
[/DisableErrorReporting]
         Disables error reporting.

Removing the Unified Messaging Server Role

Prior to removing the Unified Messaging server role, check the following:

• Make sure the server isn't linked to any UM dial plan.
  
• Make sure the server isn't a prompt publishing point in a multiple Unified Messaging server environment. If the server is a prompt publishing point, make sure you move the role to a new Unified Messaging server and have a backup copy of all prompt files.
  
• If you don't plan to reinstall the Unified Messaging server role on the same computer, check the UM IP gateway configuration and make sure it isn't pointing to this server.
  

To remove the Unified Messaging role, from a command prompt, go to the %ExchangeRoot$\bin folder of Exchange 2007 and run the following command.

Exsetup /roles:UM /mode:uninstall

Return to top

A Unified Messaging disaster recovery plan requires a plan for Mailbox server recovery. In this case, users must wait for the restore to be complete before they can use their voice mailbox. The Unified Messaging server still receives voice messages and sends the messages to the Hub Transport server. If the Mailbox server isn't available, these voice messages are placed in a queue on the Hub Transport server.

You can recover voice mail messages from the Hub Transport server, restore the Mailbox server from a backup copy, or use a dial tone database during disaster recovery.

Recovering Voice Mail Messages from a Hub Transport Server

If you want to recover a certain voice mail message from the Hub Transport server, follow these steps:

1. From the Exchange Management Console, open Queue Viewer.
   
2. Find the voice mail message by using the Messages tab. You can create a filter to isolate the UM messages. One easy way is to use the filter Subject and use the string "voice mail" because all UM voice mail has this phrase in the subject line by default.
   
3. You can also run the following command to isolate the message that came from the Unified Messaging server and is in the queue on the Hub Transport server. This command is helpful if the Unified Messaging server is installed as a stand-alone server.
   
   Get-message -server UMServerName

4. After you isolate the message, find and copy the message ID.
   
5. Run the following command to export the message in .eml format.
   
   Export-message -identity "message-id" -dir c:\export\message.eml

   You can open the message using Microsoft Outlook.
   

Restoring Mailbox Server from a Backup

When the Mailbox server is restored from a backup, Unified Messaging functionality should start working. You don’t have to do anything special to enable Unified Messaging.

Using a Dial Tone Database During Disaster Recovery

A dial tone database is a blank database for a mailbox store. When a mailbox store fails to mount due to corruption (or some other reason), you may choose to use a dial tone database to give users temporary relief. These are the main features of a dial tone database:

• It is a blank database with no previous data. Dial tone databases are used because restoring the original database takes time.
  
• With a dial tone database, users have access to e-mail while the administrator works to restore the original database.
  
• After the original database is restored, all the contents of the dial tone database is merged with the original database, the dial tone database is removed, and the original database with the latest data (from the dial tone database) is mounted as the production database.
  
• For more information about using a dial tone database to recover a UM server, see How to Perform a Dial Tone Recovery on an Exchange 2007 Server with a Failed Database.
  

PIN issues are something to be aware of when you use a dial tone database recovery approach. A user's PIN to access voice mail is stored in the mailbox store. After a new dial tone database is created, users won't be able to access their voice mail because their original PIN is no longer available. As long as the dial tone database is in production, the existing PINs for UM-enabled users won't work. You can follow one of these interim plans to help users:

• Generate interim PIN   You can generate an interim PIN for all users. This PIN works as long as users are in a dial tone database. You can:
  
  1. Issue an interim PIN to all UM users.
     
  2. Send an e-mail message to all UM users about the dial tone database and the need to use a temporary PIN.
     
• No action   You may choose to take no action when the dial tone database is in production. In this scenario, users get a first time user prompt and will be able to reset their password. You need to send an e-mail message to the UM-enabled users explaining the situation.
  

After the original database is restored, UM users need to revert back to their original PIN.

Return to top

When all the Hub Transport servers in the local Active Directory site are unavailable, the incoming voice mail messages are stored in the %UMRoot%\voicemail folder. Every message has two files: GUID.txt file and GUID.wav file. The missed call notification has only the GUID.txt file. You can view the header file (GUID.txt) and determine who is the caller and calling party. In certain scenarios where the message has high importance, these two files can be given to the calling party, and the user can play the .wav file to retrieve the voice mail.

Return to top