White Paper: Fundamentals of Troubleshooting Unified Messaging in Exchange 2007

 

上次修改主題的時間： 2009-05-27

Seema Rahman, Escalation Engineer

June 2009

摘要

This white paper discusses the fundamentals of troubleshooting Unified Messaging (UM) in Microsoft Exchange Server 2007. By using the troubleshooting tools available in Exchange 2007, as well as the backup and disaster recovery techniques described in this white paper, you can perform the troubleshooting fundamentals for Unified Messaging.

附註：
To print this white paper, click Printer Friendly Version in your Web browser.

Applies To

Microsoft Exchange Server 2007

Table of Contents

• 簡介

• Troubleshooting Basics

• Troubleshooting Unified Messaging

  • Call Not Routed from the PBX to the IP Gateway

  • Call Not Accepted by the Unified Messaging Server

  • Voice Mail Not Delivered to the User's Mailbox

  • Users Unable to Access or Play Messages Using Outlook or Outlook Web Access

  • Users Unable to Access or Play Messages by Calling a Subscriber Access Number

  • Users Unable to Make Outbound Calls Using Play on Phone

• Analyzing a Simple Call

  • First SIP INVITE Request

  • Redirection Message

  • Second SIP INVITE Request

  • OK Message

• Troubleshooting Resources

  • Network Monitor

  • Event Log

  • Exchange Management Shell

  • Exchange Best Practices Analyzer

• Backing Up a Unified Messaging Server

  • Custom Prompt Files

  • Configuration Files

  • Grammar Files

• Disaster Recovery

  • Unified Messaging Server Unavailable

  • Mailbox Server Unavailable

  • Hub Transport Server Unavailable

• 結論

簡介

Unified Messaging servers provide the voice mail integration functionality for Exchange 2007. Unified Messaging servers communicate with Internet Protocol Private Branch eXchange (IP PBXs) to send or receive calls or IP gateways to send or receive calls from PBX. This feature has unique troubleshooting challenges for the Unified Messaging server role, which is different from other roles in Exchange 2007. In addition, Unified Messaging architecture and infrastructure impacts troubleshooting. This white paper primarily focuses on the communications mechanism of Unified Messaging with an IP gateway using Session Initiation Protocol (SIP).

Troubleshooting Unified Messaging issues is similar to troubleshooting other issues. First, you isolate where the problem is, and then you use diagnostics tools to collect and analyze the data. To get a better understanding of where the problem is, you should understand the architecture of a Unified Messaging solution and where problems can occur. Keep in mind that Unified Messaging scenarios change when you have a Unified Messaging and Microsoft Office Communications Service integrated environment. More complexity is added when you have a mixed type of environment that includes Unified Messaging, Office Communications Service, and PBX.

This white paper explains Unified Messaging architecture and what types of issues may occur. Specific scenarios are described, with troubleshooting tips. Information is also provided about tools that can be used for troubleshooting and techniques that can be used for backup and disaster recovery.

For more information about troubleshooting Unified Messaging, including information about the UM Test Phone, see Unified Messaging Server Issues.

回到頁首

Troubleshooting Basics

Several key areas of Exchange Unified Messaging can be examined using a variety of tools described in this white paper, depending on the issue. The following figure shows the key components to consider when troubleshooting a voice mail system.

Troubleshooting Unified Messaging components

回到頁首

Troubleshooting Unified Messaging

Troubleshooting techniques for Unified Messaging primarily depend on determining where the problem is occurring. Because the primary function of Unified Messaging is to receive voice mail calls, most calls are incoming. Troubleshooting techniques usually focus on incoming calls for voice mail. However, other types of calls, such as outgoing calls and UM auto attendant calls, are also discussed in detail in this scenario-based white paper.

The following figure illustrates an incoming call flow.

Incoming call flow

When an incoming call to voice mail fails, the problem usually happens at one of the following stages of the call flow:

• Call isn't routed from the PBX to the IP gateway, so the call doesn't reach the Unified Messaging server.

• Call isn't accepted by the Unified Messaging server.

• Voice mail isn't delivered to the user's mailbox.

The following sections provide troubleshooting information about problems with call flow and issues for users.

回到頁首

Call Not Routed from the PBX to the IP Gateway

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.

回到頁首

Call Not Accepted by the Unified Messaging Server

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.

回到頁首

Voice Mail Not Delivered to the User's Mailbox

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.

回到頁首

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 Unable to Access or Play Messages Using Outlook or Outlook Web Access

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.

回到頁首

Users Unable to Access or Play Messages by Calling a Subscriber Access Number

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.

回到頁首

Users Unable to Make Outbound Calls Using Play on Phone

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?

  重要事項：
  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.

回到頁首

Analyzing a Simple Call

This section describes the call flow of an incoming call for voice mail, describes what may go wrong at certain phases of the call, and offers tips for troubleshooting those problems. The following figure shows a basic diagram of an incoming call for voice mail.

Here are the basics of a simple Unified Messaging call flow:

1. Caller A places a call to B.

2. B doesn't answer the phone.

3. Call gets forwarded to voice mail. In this example, it's forwarded to the VoIP gateway first.

4. The VoIP gateway sends this call to the Unified Messaging server.

5. At this point, caller A should hear the personal greeting of B.

Consider the internal architecture: When a call comes in, the IP gateway or IP PBX sends a SIP INVITE request to the Unified Messaging server. This request is processed by the Microsoft Exchange Unified Messaging service (UMservice.exe). After processing this request, the Microsoft Exchange Unified Messaging service hands off the request to the UM worker process, which (for TCP) listens to port 5065 or 5066. Then, Unified Messaging sends a 302 Moved Temporarily redirection message to the IP gateway. The IP gateway sends a new request (SIP INVITE) to port 5065 (or 5066).

SIP dialog for incoming voice mail call

As shown in the preceding figure, the first phase of this call can be broken into several steps:

1. The first SIP INVITE request is sent from the IP gateway to the Unified Messaging server.

2. A 302 Moved Temporarily redirection message is sent from the Unified Messaging server to the IP gateway, to redirect the message to the UM worker process.

3. A new SIP INVITE request is sent from the IP gateway to the UM worker process.

4. A 200 OK message is sent from the Unified Messaging server to indicate a session is established.

5. After the session is established, you will see RTP traffic flowing between the gateway and the UM server.

The initial call can have issues in any of the stages described in the following sections. To troubleshoot, you need to:

• Perform a network trace from the Unified Messaging server.

• Turn on diagnostics logging on the Unified Messaging server.

• Perform SIP log type tracing from the IP gateway, if available.

These troubleshooting techniques assume you have data from network trace and diagnostics logging only.

回到頁首

First SIP INVITE Request

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 FirstSIP 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.

回到頁首

Redirection Message

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.

  附註：
  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.

回到頁首

Second SIP INVITE Request

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 SecondSIP 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.

回到頁首

OK Message

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

重要事項：
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.

回到頁首

Troubleshooting Resources

You can use the following resources to troubleshoot Unified Messaging issues:

• Network Monitor

• Event Log

• Exchange Management Shell

• Exchange Best Practices Analyzer

These tools are discussed in more detail in the following sections. In addition, you can find information about these and other tools in Tools for Troubleshooting and Unified Messaging Server Issues in the Exchange Server 2007 Help documentation.

Network Monitor

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)

附註：
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")

回到頁首

Event Log

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.

請注意：
UNRESOLVED_TOKEN_VAL(exRegistry)

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

Logging level for event logging

Logging level	Value
Expert	7
High	5
Medium	3
Low	1
Lowest	0

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.

回到頁首

Exchange Management Shell

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.

回到頁首

Exchange Best Practices Analyzer

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.

回到頁首

Backing Up a Unified Messaging Server

A backup plan for any organization is critical for maintenance and successful recovery. With the introduction of a Unified Messaging server, you need to incorporate new strategies for backing up that server. This section discusses specific files and data that are relevant only to the Unified Messaging environment. In addition, some disaster recovery techniques are described.

To successfully recover a Unified Messaging server, certain files must be backed up. These files aren't Exchange database files, so they aren't automatically selected if you choose an Exchange-aware backup and use the Exchange option only. You need to do a file-level backup of these files. These files don't need to be backed up every day because they are mostly configuration related. The following files need to be backed up from a Unified Messaging server:

• Custom prompt files

• Configuration files

• Grammar files

回到頁首

Custom Prompt Files

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.

回到頁首

Configuration Files

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.

回到頁首

Grammar Files

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.

回到頁首

Disaster Recovery

Disaster recovery for Unified Messaging has a significant impact on the customer environment. The potential impact is compounded when the Mailbox server is unavailable. In this case, users don't have access to their e-mail and voice mail.

Disaster recovery techniques are provided for the following situations:

• Unified Messaging server is unavailable.

• Mailbox server is unavailable.

• Hub Transport server is unavailable.

回到頁首

Unified Messaging Server Unavailable

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.

Server role	Role value
Mailbox	2
Client Access	4
Unified Messaging	16
Hub Transport	32
Edge Transport	64

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

回到頁首

Mailbox Server Unavailable

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.

回到頁首

Hub Transport Server Unavailable

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.

回到頁首

結論

Understanding Unified Messaging and where issues can occur helps you troubleshoot. By using the troubleshooting tools available in Exchange 2007, as well as the backup and disaster recovery techniques listed in this white paper, you can perform the troubleshooting fundamentals for Unified Messaging. For more information, see Unified Messaging Server Issues in the Exchange Server 2007 Help documentation.

回到頁首