New date for discontinuation of support for Session Border Controllers in Exchange Online Unified Messaging
Update 9/12/2018: We have two important updates for customers: As we prepare to discontinue support for PBX’s connecting to Exchange Online Unified Messaging, we will remove the ability for tenant admins to configure new PBX connections on or after October 8, 2018. Existing connections will not be impacted by this change. Based on customer feedback, we have moved the final date to December 1, 2019 to give customers additional time for transition. In July 2017, we announced that support for Session Border Controllers (SBC) that connect 3rd Party PBX systems to Exchange Online Unified Messaging (UM) would be discontinued as of July 2018. After feedback from customers and partners concerned about this change, we are announcing additional time for customers to prepare. The new date for discontinuation will be December 1, 2019. Customers with existing deployments remain fully supported until this date. However, Microsoft strongly advises all customers to begin their voicemail transition now. There are different alternatives for customers currently using an on-premises PBX system that connects to Exchange Online. We recognize that customers may also choose a combination of these options for their organization. Office 365. We believe the best option for customers is to transition to the cloud and use Office 365. This would include the enterprise voice workload and Cloud Voicemail. Customers would use Microsoft Teams for collaboration and voice services. Skype for Business Server. In this configuration, customers would deploy an on-premises Skype for Business server and take advantage of the services for voicemail supported by the server. 3 rd Party Voicemail System. With this approach, the customer acquires a 3rd party voicemail system that provides all the capabilities required to process voicemail and then place it in the user’s Exchange mailbox. In past communications, customers may remember that we discussed another alternative which included voicemail routing. These solutions involved vendors who rely upon Skype for Business and Exchange UM for the solution. It’s important to note that Microsoft does not certify these solutions. There may be impact to these 3rd party solutions as we evolve our architecture for voicemail. As 3rd party providers will be your primary source of support for these solutions, we recommend customers work with these vendors to ensure the longevity and supportability of the solution. We know these changes can be challenging in the near-term. But we believe that continuing to identify areas where we can evolve the service we provide while taking full advantage of the cloud is the right answer. We will continue to evaluate emerging needs as customers make the transition from legacy dedicated voice to Microsoft’s Intelligent Communications solutions. For customers that may have more questions, please contact your account team or Microsoft Support. Customers already using Office 365 can submit a support case through the Office 365 Admin Portal. Exchange teamTroubleshooting the Messaging Waiting Indicator status in Exchange 2010 Unified Messaging server
There are a number of ways an end-user may learn that they have new voice mail, such as from client software like Microsoft Outlook, OWA , Lync, Communicator, or different types of indicators on IP , smart and traditional phones. The term Message Waiting Indicator (MWI) is usually applied to notifications delivered by the user’s phone using mechanisms such as a light on the phone, a special icon or highlighted notification or even a special dial tone. Exchange 2010 includes built-in support for MWI . For more details, see Understanding Message Waiting Indicator in Exchange 2010 documentation. Exchange 2010 Unified Messaging also includes a feature called Voice Mail Preview which uses automatic speech recognition (ASR) to add a text version of the voice mail that's delivered to the user's Inbox (along with the MP3 voice message). This allows users to read their voicemail messages. See Voice Mail Preview Advisor for Exchange 2010 for details. This article describes steps on how to use the event logs on Exchange 2010 Unified Messaging (UM) and Mailbox servers to troubleshoot MWI failures. Also included in this article are settings to validate MWI configuration on Exchange. Flow of MWI notifications on Exchange servers A voice message is left for a user and is stored in the user's Exchange mailbox on a Mailbox server. The Mailbox Assistant service on the Mailbox server checks the status of voice mails in the user’s mailbox. The Mailbox Assistant service makes an RPC connection to a Unified Messaging server associated with the user’s UM Dial Plan. The UM server sends a SIP NOTIFY message with the MWI state change to a UM IP Gateway associated with the user’s UM Dial Plan. The starting point of a MWI notification is after the voicemail has been placed in the end user’s mailbox. The focus of these troubleshooting steps are on the Exchange messaging side to diagnose MWI notification issues between a Mailbox server and a UM Server, and also between the UM server and a UM IP Gateway. Contents Troubleshooting Steps: Check the event log on the mailbox server Increase the UM MWI event logging level on the Mailbox server Identify the UM IP Gateway and UM server On the UM server look for a SIP OPTIONS failure Increase the UM MWI event logging level on the UM server Check connectivity between the UM server and the UM IP Gateway. New Unified Messaging server event ID for SIP OPTION failures Summary of settings to validate Useful links Troubleshooting Steps Check the event log on the mailbox server Confirming the Mailbox server is not logging MWI errors will help to isolate the problem to a later notification handling step. The first step in sending the MWI notification is the retrieval of the MWI state from the user’s mailbox on the mailbox database. Once the state of the MWI is known, the mailbox server must be able to make an RPC connection with the UM server to relay the MWI state information. Any of the following events, if found on the Mailbox server, would be the starting point for a deeper look at the Mailbox server. Also UM event logging can be increased on the mailbox server to confirm that the MWI notification was successfully sent to the UM server. On the Exchange 2010 Mailbox server, look for Event ID 1346 in the Application Event log. It indicates there may be an issue with the database or the database might be dismounted. Log Name: Application Event ID: 1346 Source: MSExchange Unified Messaging Date: 4/15/2011 6:55:52 PM Task Category: MWI General Level: Warning Keywords: Classic User: N/A Computer: Ex2K10MailboxServer.Contoso.com Description: The Message Waiting Indicator Assistant was unable to query the mailbox database 'MailboxDB01#GUID'. The MWI assistant will try to query the mailbox database again in 720 minutes. If you continue to see this warning, there could be a problem with the mailbox database or the Mailbox server. Additional information: Microsoft.Mapi.MapiExceptionMdbOffline: MapiExceptionMdbOffline: Unable to get mailbox information. (hr=0x80004005, ec=1142) Diagnostic context: Lid: 20354 Presence of Event ID 1345 on the Mailbox server indicates there may be a problem with the user’s mailbox. The ‘Additional information’ will contain MAPI error codes and additional information to diagnose the specific issue. Here's an example: Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 6:45:52 PM Event ID: 1345 Task Category: MWI General Level: Warning Keywords: Classic User: N/A Computer: Ex2K10MailboxServer.Contoso.com Description: The Message Waiting Indicator Assistant was unable to obtain the MWI state for mailbox 'John Doe (#ExchangeGuid)' on database 'MailboxDB01#GUID'. You can safely ignore this warning if the mailbox is currently disconnected or inactive. Additional information: (Various MAPI error descriptions). Event ID 1360 on the Mailbox server indicates that there might be an RPC communication issue between the Mailbox server and the UM server. A communication issue between the mailbox and the UM server could be due to an issue on either server. For example: Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 7:05:52 PM Event ID: 1360 Task Category: UMCore Level: Warning Keywords: Classic User: N/A Computer: Ex2K10MailboxServer.Contoso.com Description: The Message Waiting Indicator Assistant failed to deliver the MWI notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension '+15555555555'. Until this problem is corrected, the MWI state for this user may be out of sync. Additional information: Server Ex2K10UMServer failed with 1722 Error 0x6ba (The RPC server is unavailable) from SendMwiMessage Note: You may also see: There are no more targets available to send an MWI message for user John Doe. If the UM MWI event logging level is increased on the Mailbox server, the success event for the MWI notification is logged to the Application event log with ID: 1343, which indicates that the Mailbox server has successfully submitted a MWI notification to the UM server. This command shows the current logging level of MWI on the mailbox server: Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto The output: Identity EventLevel -------- ---------- MSexchange Unified Messaging\MWI General Lowest This command raises the MWI logging level to ‘Expert’ and you will start to see the MWI ‘Success’ events (Event ID: 1343) in the Application event log. [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | Set-EventLogLevel -Level:Expert You can use the Get-EventLogLevel cmdlet again to verify that the MWI logging level has been raised to Expert level. For more details about diagnostic logging levels in Exchange 2010, see Manage Diagnostic Logging Levels. The increase in logging show will show that mailbox server has successfully submitted the MWI notification to the UM server. For example: Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 7:15:26 PM Event ID: 1343 Task Category: MWI General Level: Information Keywords: Classic User: N/A Computer: Ex2K10MailboxServer.Contoso.com Description: A Message Waiting Indicator (MWI) notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com' was succesfully sent to 'Ex2K10UMServer'. Identify the UM IP Gateway and UM server From the UM server: If you already know the UM server in use, then check the Application Event log for event 1344 identifying an MWI and the user affected. The PowerShell commands further below will help to validate Exchange configurations settings for the MWI. Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 6:30:52 PM Event ID: 1344 Task Category: MWI General Level: Warning Keywords: Classic User: N/A Computer: Ex2K10UMServer.Contoso.com Description: The Unified Messaging server failed to deliver the MWI notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com'. Until this problem is corrected, the MWI state for this user may be out of sync. Additional information: An MWI message couldn't be delivered in the allocated time for user John Doe. Server MyIPGateway1 failed with 0 Unable to establish a connection. Server MyIPGateway2 failed with 0 Unable to establish a connection. The ‘MyIPGateway#’ indicates one or more Exchange UM IP Gateways objects associated with the dial plan for the user. The UM IP Gateway should also be checked to confirm that the MWI is enabled with the MessageWaitingIndicatorAllowed set to True. See further below for an example. From the recipient: If you have a specific user you are validating MWI functionality, the steps below are also useful to validate that each portion of the messaging configuration has MWI enabled for the user. The user must be UM enabled, and MWI must be enabled ‘True’ on the UM Mailbox Policy and the UM IP Gateway in Exchange, to be configured to deliver MWI notifications. Please be sure to check the health and status of the user’s mailbox server first. Identify the UM server and UM IP Gateways that the user would be associated with. First find the UM dial plan linked with the user. The recipients UM dial plan (and UM Mailbox Policy) can be found for a user with Get-UMMailbox. Get-Recipient will provide much of the same data. For example: Get-UMMailbox johndoe@contoso.com | select UMEnabled, UMDialPlan, UMMailboxPolicy, UMSMSNotificationOption | FL The output: UMEnabled : True UMDialPlan : MyUMDialPlan UMMailboxPolicy : MyUMMailboxPolicy UMSMSNotificationOption : VoiceMail Alternatively, using the Get-Recipient cmdlet retrieves the following data. [PS] C:\>Get-Recipient johndoe@contoso.com | select UMEnabled, UMMailboxPolicy, UMRecipientDialPlanId | FL UMEnabled : True UMMailboxPolicy : MyUMMailboxPolicy UMRecipientDialPlanId : MyUMDialPlan Next, let's look at the UM Mailbox Policy by using the Get-UMMailboxPolicy cmdlet and confirm that the policy is MWI enabled (AllowMessageWaitingIndicator is set to True). Get-UMMailboxPolicy -Identity MyUMMailboxPolicy | select AllowMessageWaitingIndicator, AllowSMSNotification | FL AllowMessageWaitingIndicator : True AllowSMSNotification : True The UM servers and IP Gateways associated with the recipient’s dial plan can be found with the Get-UMDialplan cmdlet. For example, Get-UMDialplan -Identity MyUMDialPlan | select UMServers, UMMailboxPolicies, UMIPGateway | FL UMServers : {Ex2K10UMServer, Ex2K10UMServer2} UMMailboxPolicies : {MyUMMailboxPolicy} UMIPGateway : {MyIPGateway1, MyIPGateway2} The UM IP Gateway in Exchange should also be confirmed that the MWI is enabled and set to ‘True.’ Get-UMIPGateway -Identity MyIPGateway1 | FL MessageWaitingIndicatorAllowed MessageWaitingIndicatorAllowed : True On the UM servers listed in the dial plan look for Application event log ID 1344. This event will show the MWI failure for the user. This will also indicate which UM IP Gateways that may have a communications issue where the SIP Options fail. Look for a SIP OPTIONS failure on the Unified Messaging server Connection issues between the UM server and physical UM IP Gateway device, may appear as SIP OPTIONS failure events on the UM server. With the UM IP Gateway from either the dial plan or directly on the UM server, you can look for Application event log ID 1400 that indicates a SIP OPTIONS failure to the specific Gateway. For example: Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 6:31:28 PM Event ID: 1400 Task Category: UMCore Level: Warning Keywords: Classic User: N/A Computer: Ex2K10UMServer.Contoso.com Description: The following UM IP gateways did not respond as expected to a SIP OPTIONS request. Transport = TLS, Address = MyIPGateway1.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection. Transport = TLS, Address = MyIPGateway2.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection. Note: The error text will be different depending on the type of failure; you may also see "This operation has timed out.", “Unknown error (0x80131500)”, or as shown “Unable to establish a connection.” The Port may be different from ‘5060’. If mutual TLS has been configured the port is use will be 5061. Increase the UM MWI event logging level on the UM server To get confirmation that the Exchange UM server successfully submitted the MWI notification to the Gateway device, you will need to increase the logging level for MWI on the UM server. You may see a new Application event ID: 1343. The ID: 1343 is a ‘success’ entry for having notified the Gateway device of the MWI state. If the Exchange UM server successfully submitted the notification, then the next step would be to check the Gateway device’s functionality with the Gateway’s downstream devices. Run the command below to view the current logging level of MWI on the UM server. [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto Identity EventLevel -------- ---------- MSexchange Unified Messaging\MWI General Lowest To increase the MWI logging level to see the MWI success events you can run the following command. This will set the logging level to ‘Expert’ and you will start to see the UM MWI ‘Success’ ID: 1343 events in the Application event log. [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | Set-EventLogLevel -Level:Expert You can now see that the MWI logging level has been increased. [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto Identity EventLevel -------- ---------- MSexchange Unified Messaging\MWI General Expert The increase in the UM server’s MWI logging level show will show that UM server has successfully submitted the MWI notification to the UM IP Gateway with the following event. The failure to notify end users would then be with the Gateway device or downstream functionality. For example, Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 7:15:45 PM Event ID: 1343 Task Category: MWI General Level: Information Keywords: Classic User: N/A Computer: Ex2K10UMServer.Contoso.com Description: A Message Waiting Indicator (MWI) notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com' was succesfully sent to 'MyIPGateway1'. Check connectivity between the UM server and the UM IP Gateway There are a number of factors that impact communications between the UM server and the UM IP Gateway. If TLS (Transport Layer Security) is being used, certificates are a common item to check. When other functionality is working between the UM server and the Gateway, there could be an issue in how the SIP NOTIFY is being handled. Basic network checks to confirm TCP/IP connectivity. If the UM Gateway listed is a FQDN, confirm that the correct IP address is resolved. Validate the address resolution across all DNS servers. From the UM server use ‘Ping’ and ‘Tracert’ to confirm the routing path and IP connectivity. To validate that the port is listening you can ‘Telnet’ to the port (5060/5061). New Unified Messaging server event ID for SIP OPTIONS failures The event ID for the SIP OPTIONS failure has changed between Exchange 2007 and Exchange 2010. Exchange 2010 logs event ID 1400 in the Application event log for SIP OPTIONS failures. The content of event ID 1400 is also different from the SIP OPTIONS failure event ID 1088 logged by Exchange 2007, which logged only one failure per event. Exchange 2010 lists multiple failures per event. The event ID1088 does not alert on the Exchange 2010 UM server. In Exchange 2007 the Application log event ID 1088 for SIP OPTIONS failure: Event Type: Warning Event Source: MSExchange Unified Messaging Event Category: UMService Event ID: 1088 Date: 4/15/2011 Time: 6:18:13 PM User: N/A Computer: Ex2K7UMServer Description: The IP gateway or IP-PBX "MyIPGateway1" did not respond to a SIP OPTIONS request from the Unified Messaging server. The error code that was returned is "0" and the error text is ":Unable to establish a connection.". Note: The error text will be different depending on the type of failure, you may also see ":This operation has timed out.". In Exchange 2010 the new Application log event ID 1400 for SIP OPTIONS failure, for example. Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 6:31:28 PM Event ID: 1400 Task Category: UMCore Level: Warning Keywords: Classic User: N/A Computer: Ex2K10UMServer.Contoso.com Description: The following UM IP gateways did not respond as expected to a SIP OPTIONS request. Transport = TLS, Address = MyIPGateway1.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection. Transport = TLS, Address = MyIPGateway2.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection. Note: The error text may be different depending on the type of failure. You may also see: "This operation has timed out." “Unknown error (0x80131500)” “Unable to establish a connection.” Additionally, the actual port used is displayed - it may be different from 5060. For example, if you've configured mutual TLS, TCP port 5061 is used. Summary of settings to validate Confirm that a voicemail has been placed in the end user’s mailbox. Confirm the user’s mailbox and mailbox database are online and responding. Look for any MWI failure events on the mailbox server. Increase the UM MWI event logging level on the mailbox server to view ‘success’ events. Confirm the user is UM enabled (Get-Recipient) and note the mailbox policy and dial plan. If the user receives an SMS text notification confirm that ‘UMSMSNotificationOption’ is set to a Voicemail option, and also that the UMMailboxPolicy setting ‘AllowSMSNotification’ is set to ‘True’. Confirm that the UM Mailbox Policy is MWI enabled. Find the UM server and UM IP Gateway being used from the UM Dial Plan. Confirm that the UM IP Gateways is MWI enabled in Exchange. Check the health of the UM server. Look for SIP OPTIONS failures on the UM server. Increase the UM MWI event logging level on the UM server to view ‘success’ events. Examine network connectivity between the UM server and the UM IP Gateway. Confirm the UM server is able to ping the UM IP Gateway and telnet to the port in use. The commands Test-UMConnectivity and Test-ExchangeUMCallFlow may be useful in testing functionality between the UM server and the UM IP Gateway but don’t specifically test MWI notifications. These troubleshooting steps will help to eliminate any issues on the Exchange server side in passing MWI notifications to end users. With all MWI settings correctly configured, any Exchange side MWI failure should be able to be isolated by the errors in the Application event log. But this only validates the Exchange side of the MWI notifications, there could be an issue on the UM IP Gateway / SIP Peer side or how the SIP NOTIFY of the MWI notifications were handled between the UM server and the UM IP Gateway device. This article doesn’t go into the handling of the SIP NOTIFY between the UM server and a UM IP Gateway. For an in-depth description on the MWI SIP NOTIFY with the UM IP Gateway / SIP Peer, please see 'Understanding Message Waiting Indicator’. Useful links Understanding Message Waiting Indicator -An in-depth description of the MWI. Configure the TCP Listening Port on a UM IP Gateway -Settings to use TLS (Transport Layer Security) with gateways. Error and Event Reference for Unified Messaging Servers -UM events and their description text. Understanding Unified Messaging IP Gateways -Description of IP Gateways and objects. An IP gateway or IP PBX didn't respond to a SIP OPTIONS request from the Unified Messaging server -Description of the event ID 1400 for the System Center Operations Manager Exchange Server 2010 Management Pack. MSExchange Unified Messaging 1400 -Description of the event ID 1400. Jon ErnastExchange 2010 Diagnostics: The Unified Messaging Troubleshooting Tool
Requirements Supported Operating Systems Windows 7 Windows Vista Windows Server 2008 and Windows Server 2008 R2 Software Requirements Microsoft .NET Framework 3.5 SP1 Microsoft .NET Framework 3.5 Family Update for Windows Vista x64 and Windows Server 2008 x64 (if the tool will be run on a computer running Windows Vista or Windows Server 2008) Windows Management Framework Core package (Windows PowerShell 2.0 and WinRM 2.0) Unified Communications Managed API 2.0, Core Runtime (64-bit) Download: Unified Messaging Troubleshooting Tool The Unified Messaging Troubleshooting Tool is a diagnostics cmdlet which every administrator should run whenever someone desperately (or not) comes to them and says "Help! My voicemail isn't working!". The tool executes a set of tests and outputs the possible root causes for any detected issues and the possible solution for those. Simple, fast and efficient, just the kind of tool you need in your daily IT adventures. Since we released the tool a while back, I've been receiving requests to post about it here on EHLO. As more and more organizations are starting to move away from the typical enterprise deployment model to a completely online world in Office 365, I thought this would be the right time to attend such requests. So, have you been using the tool? If not, here's something to get you started! Configuring the Windows PowerShell default execution policy on Windows 7 If you are running the tool in Windows 7, by default it won't be given permission to execute Powershell scripts. This is due to the default execution policy granted by Windows PowerShell which is set to Restricted, so the moment you double click on the shortcut for the tool on your desktop, you get a nasty error message: Microsoft.Exchange.UM.TroubleshootingTool.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about signing" for more details. To bypass this, execute the following steps on your box: Start a new Powershell window as Administrator(run as Administrator) Run the following command: Set-ExecutionPolicy RemoteSigned This will grant Windows Powershell permissions to execute all scripts and configuration files, as long as they're signed by a trusted publisher. Because the troubleshooting tool is a signed Powershell script, it'll be granted the permissions to execute. Running the tool You are now ready to run the tool. Double click on the UM Troubleshooting tool shortcut on your desktop and type Test-ExchangeUmCallFlow PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: The troubleshooting tool supports two operating modes: Gateway: Emulates a call, as if it was coming from a SIP Gateway. SIPClient: Emulates a call, as if it was coming from a Lync server. Say you're running the tool to verify Bob's TelEx extension (x12345). When prompted about the execution mode, you should go ahead and confidently type Gateway. PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: Gateway NextHop: The troubleshooting tool will now prompt you for the NextHop. This should be the IP address or FQDN that the tool must connect to. Your NextHop will vary, depending on whether you're running the tool to verify the UM configuration of a mailbox in Office365 or a mailbox hosted in your on-premises Exchange organization. If you're verifying a mailbox hosted in the cloud, you should enter the FQDN of the SBC device, which will in turn forward the call to one of our UM servers. If you're running the tool against an on-premises mailbox, you should enter the FQDN of your Unified Messaging server. PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: Gateway NextHop: Umserver.constoso.com Diversion: The last information required is the diversion header to be used. It can be as simple as just the extension number to be verified, or a (somewhat) complex History-Info header, as those might also be used by SIP devices interested in preserving the information on how a call originated. Here's an example of a very complex History-Info in case you'd like to try it out: History-Info:<sip:12345@contoso.com;user=phone?Reason=SIP%3Because%3D487%3Btext%3DTimeout>;index=1,<sip:7890@contoso.com;user=phone?Reason=SIP&m#62;;index=1.1 So go ahead and enter the last parameter required: PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: Gateway NextHop: Umserver.constoso.com Diversion: 12345 That's it! The tool will then execute a set of tests and output any issues detected. PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: Gateway NextHop: Umserver.constoso.com Diversion: 12345 The diagnostic test identified a problem. Task : Resolving "UmServer.contoso.com" to an IP address Status : Failed Reason : It is not possible to resolve "UmServer.constoso.com" from this machine. Details: No such host is known Solution : Confirm that the server name "UmServer.contoso.com" is correct and that it can be accessed from this computer. Traces for this diagnostic test can be found at 'C:\Users\Administrator\AppData\Roaming\Microsoft Exchange 2010 UM Troubleshooting Tool'. By the way, did you notice the last lines outputted by the tool? Here is what is says: Traces for this diagnostic test can be found at 'C:\Users\Administrator\AppData\Roaming\Microsoft Exchange 2010 UM Troubleshooting Tool' In addition to the information returned by the tool, a set of very, very important traces are automatically generated by the tool: UMTool_Collaboration: RTC stack traces UMTool_DiagnosticLog: Lists the tests executed by the tool and their results UMTool_S4: S4 stack traces UMTool_SIPMessageLogs: The full SIP traces for the test call executed The UM team would love to hear stories where the Unified Messaging Troubleshooting tool saved your day! We'd love as well to hear any other asks you might have. Let us know by posting your comments on this blog. Bernardo SanaUnderstanding Remote Mailbox Move and Unified Messaging
Remote mailbox move (a.k.a. cross-forest mailbox move) refers to the process of migrating an Exchange mailbox from one Active Directory forest to another. Exchange 2010 supports remote mailbox moves via the MoveRequest cmdlets. Here are some of the considerations for performing remote mailbox moves on mailboxes which are enabled for Unified Messaging (UM). This article assumes that readers are familiar with Unified Messaging and how remote mailbox move operates in general. So... why do you care? Prior to Exchange 2010 SP1, if you want to perform remote mailbox move on a UM-enabled mailbox, you need to do the following: Prior to the move, UM-disable the mailbox in the source forest Execute move request on the mailbox After the move completes, UM-enable the mailbox in the target forest In addition, you need to update the telephony configuration for the corresponding phone set so that all phone calls for the mailbox owner are correctly covered by the telephony system to the UM servers in the target forest. This process poses several pain points, most importantly: Admin hassle - The admin having to manually disable and re-enable the mailbox for UM every time a UM-enabled mailbox is moved. User hassle - Voice Mail stops working for the user whose mailbox is being moved for the entire duration of the move process since the mailbox is UM-disabled. This is problematic for users with large mailboxes where the move process can take a long time to complete. In Exchange 2010 SP1, we've extended the MoveRequest cmdlets to alleviate these pain points by removing the need for an admin to UM-disable/re-enable the mailbox and reduce voice mail downtime. How it works For this to work correctly, you need to "map" the UMMailboxPolicy objects in the source forest to the UMMailboxPolicy objects in the target forest. This is achieved by stamping the name of the UMMailboxPolicy object in the source forest on the SourceForestPolicyNames attribute on the UMMailboxPolicy object in the target forest. Here's an example to explain what I mean: Suppose you have some mailboxes which are UM-enabled in the source forest and are associated with UMMailboxPolicy object (Policy S). You would like these mailboxes to be UM-enabled and associated with UMMailboxPolicy object (Policy T) in the target forest after the move completes. Prior to executing the New-MoveRequest on these mailboxes, you need to stamp the name of Policy A on Policy B's SourceForestPolicyNames attribute by running the following Exchange cmdlet in the target forest: Set-UMMailboxPolicy -identity "Policy B" -SourceForestPolicyNames "Policy A" Once the mapping is created, you can start moving the mailboxes by executing the New-MoveRequest cmdlet without having to UM-disable the mailbox first. While the move is in progress, UM continues to operate for these mailboxes in the source forest since the mailboxes are still UM-enabled. As the move request completes for a particular mailbox, the following happens: In the target forest: Upon detecting that the mailbox is UM-enabled, the migration process obtains the name of the UMMailboxPolicy object which the mailbox is associated with in the source forest. It then looks for a corresponding UMMailboxPolicy object in the target forest whose SourceForestPolicyNames attribute contains this name. The migration process also figures out what UM extensions are currently assigned to the mailbox in the source forest. Using these extensions and the UMMailboxPolicy object found earlier, the migration then UM-enables the mailbox in the target forest. The migration process also copies over information about the user's UM PIN into the target forest, ensuring the user's existing UM PIN is preserved during migration. A UM welcome message is then sent to the user, showing the access telephone number for the UMDialPlan in the target forest. Access telephone number is what users dial on their phone to get to Outlook Voice Access. In the source forest: As part of move request, the Active Directory mailbox object is updated into a Mail-Enabled User (MEU) object. All UM configuration on the MEU object is automatically removed. Once the migration process completes, voice mail outage begins. This is because your telephony system is still sending calls to the UM servers in the source forest. Voice Mail outage continues until the telephony configuration for the corresponding phone set is updated to cover calls to the UM servers in the target forest. Further reducing voice mail downtime If you want to reduce the amount of downtime even further, this is what you can do: Make sure the name of the UMMailboxPolicy object in the source forest is correctly stamped on the SourceForestPolicyNames attribute of the UMMailboxPolicy object in the target forest. Execute New-MoveRequest with SuspendWhenReadyToComplete parameter set to $true. This ensures that the New-MoveRequest pauses right before finalization occurs. As you resume the move request by running Resume-MoveRequest, you also update your PBX configuration. As the mailbox move finalizes, the mailbox in the source forest is deleted and the mailbox in the target forest becomes functional. If you update your telephony configuration as the mailbox move finalizes, you can reduce the window of voice mail outage. Note that this method can be cumbersome since it requires precise coordination between your Exchange admin and your telephony admin. SourceForestPolicyNames Attribute The SourceForestPolicyNames attribute on the UMMailboxPolicy object is part of Exchange 2010 SP1 schema. It bears the following characteristics: Multi-valued - This means that you can have multiple UMMailboxPolicy objects in the source forest mapped to a single UMMailboxPolicy object in the target forest. Unique - No two UMMailboxPolicy objects in the same forest can have the same value stamped in their SourceForestPolicyNames attribute. This prevents you from stamping the name of a single UMMailboxPolicy object in the source forest on multiple UMMailboxPolicy objects in the target forest. This is needed to avoid any ambiguity when the migration process looks for a matching policy object in the target forest. By default, when you create a new UMMailboxPolicy object using Exchange 2010 SP1 cmdlets or admin console, its SourceForestPolicyNames attribute is automatically populated with its own name. An easy way to handle remote mailbox moves is to create UMMailboxPolicy objects in both source and target forests with the same name, thereby avoiding the need to manually configure the SourceForestPolicyNames attribute. Other considerations If the mailbox is UM-enabled in the source forest but you don't want the mailbox to be UM-enabled in the target forest, you should UM-disable the mailbox prior to the move. Conversely, if the mailbox isn't UM-enabled in the source forest but you want to UM-enable the mailbox in the target forest, you should UM-enable the mailbox in the target forest after the move. Doing so helps to reduce complexity in managing the move request since you don't have to take UM configuration into account. When you firs t execute New-MoveRequest, the migration process will perform a series of UM-specific validation up front if mailbox is UM-enabled, including looking for a matching UMMailboxPolicy object in the target forest as well as validating that the UM extensions assigned to the mailbox are unique in the target forest. If the validation fails, New-MoveRequest will return an error immediately. Under rare circumstances, the UM-specific validation may succeed up front when New-MoveRequest cmdlet is executed but the migration process fails to UM-enable the mailbox as the mailbox move finalizes. When this occurs, the mailbox move will complete with warning and the mailbox will not be UM-enabled in the target forest. You will need to manually UM-enable the mailbox in the target forest. The corresponding warning message, which can be obtained through Get-MoveRequestStatistics cmdlet, looks like this: Warning: User 'John Doe' can't be enabled for Unified Messaging in the target forest for the following reason: Extension 12345 is already assigned to another user on dialplan DP1 or an equivalent dial plan. Please fix the problem and enable the user for Unified Messaging manually. An example of how this can happen is that the UM extension assigned to the mailbox was available in the target forest when the UM-specific validation occurred but is no longer so right when the move finalizes. A UM-enabled mailbox may be assigned extensions from multiple UMDialPlan objects in the source forest. Only extensions from the primary UMDialPlan will be used to UM-enable the mailbox in the target forest. Extensions from secondary UMDialPlan(s) will not be preserved. Chun Yong ChuaCall Answering Rules (Part 2): Call Answering Conditions
In Exchange 2010, users can easily create call answering rules to have a call answered based on the specified conditions. Users can create rules to answer calls from specified callers or Contacts in a certain way, handle calls differently based on their availability (Free/Busy status) or time of day. The call answering rule will only be triggered when all the associated conditions are met. In this post, I will cover: The different classes of conditions supported in UM 2010 How does UM go about evaluating a given set of call answering rules This article assumes that you have read my previous post Call Answering Rules (Part I) - Creating your first Call Answering Rule. The Call Answering Rule form The diagram below shows you the Call Answering Rule form. In particular: Condition(s) which have already been added to the rule is located on the left (in green). You can remove them by clicking on the symbol beside the condition. Condition(s) which you can further add to this rule is located on the right (in red). To start adding new condition, simplify click on the condition desired. Figure 1: The call answering rule form Different classes of conditions There are 4 different classes of conditions supported by UM 2010, namely: Caller identity Time-of-the-day Calendar free/busy status When my automated email reply is turned on Caller Identity Users can use different call answering rules for different callers. For example, if you receive a call from an important customer's phone number, you can answer it differently. To answer calls based on caller identity, users can add a caller-ID condition to a call answering rule such that the rule will only be triggered if the calling party matches one of those specified. To configure this condition: Click on "If the caller is." condition to bring up the following UI control. Figure 2: Call answering rule based on caller Specify 1 or more phone numbers, pick Contacts from the GAL or your Contacts folder, or specify the entire Contacts folder. Click on "Apply" to close the UI control. Time of Day Users can add a time-of-the-day condition to a call answering rule such that the rule will only be triggered if the time of the call matches the time period specified. For example, during working hours, calls can be answered using the "Follow-Me" action, or routed straight to voicemail during after-hours. To configure this condition: Click on If it is during this period. condition to bring up the following UI control: Figure 3: Call answering rule based on time of day Specify a period, either working hours, non-working hours or custom hours. Click on Apply to close the UI control. Calendar Free/Busy status Users can specify a condition for a call answering rule based on their availability (calendar Free/Busy status). To do so: Click on If my schedule shows that my status is. condition to bring up the following UI control: Figure 4: Call answering rule based on Free/Busy Status Pick one or more Free/Busy status which you want this rule to fire. In the example provided, I have specified that the call answering rule to be triggered if my calendar shows that I am either Busy or Away. Click on Apply to close the UI control. When my automated email reply is turned on Users can specify that a call answering rule only be fired when their automatic email reply is turned on. To do so, simply click on "If Automatic Replies are turned on" condition. Call Answering Rules and conditions It is possible to associate the same call answering rule with multiple conditions. All the conditions must be met in order for the call answering rule to be trigger. You can also create call answering rules without specifying any condition. When such a rule is encountered, it will be triggered as though all its conditions are met. Multiple Call Answering Rules You can create one or more call answering rules. You can also associate each call answering rule with one or more conditions. The diagram below illustrates an example with 3 call answering rules configured. You can enable/disable or reorder the rules. Figure 5: Multiple call answering rules As illustrated in the flow diagram below, for each call answering call received: No call answering rules configured: If you do not have any call answering rules configured, UM will offer the caller to leave a voice message. One or more call answering rules configured: If there are one or more call answering rules configured, UM will evaluate these rules in a top-down fashion. The first rule, whose conditions are met, will be fired. After evaluating all the rules, if UM is unable to find a rule whose conditions are met, UM will offer the caller to leave a voice message. Figure 6: How UM call answering rules are evaluated Call answering rules are an Exchange 2010 feature, and only available to UM-enabled users with a mailbox on an Exchange 2010 Mailbox server. -Chun Yong ChuaInterested in your feedback around deploying and managing Exchange Unified Messaging
We are interested in hearing feedback on your experience deploying and/or managing Unified Messaging in Exchange. We are conducting research to understand users' pain points and frustrations around deployment and management of unified messaging. Please take 5-10 minutes to answer the survey questions. This type of feedback directly impacts product decisions and we would appreciate your valuable feedback. The survey can be found here. Thank you for your time! - Brendan Reeves (User Experience Researcher)Spotlight on Exchange 2010: Receiving faxes using Exchange 2010 Unified Messaging
If you are using Exchange 2007 UM to receive faxes, you should know about the changes we have made to the inbound faxing capabilities in Exchange 2010 UM. After working with our customers and partners, we determined that it was best for specialized partners with deep fax expertise to provide the comprehensive fax capability for Exchange Server 2010. We have therefore established partnerships with several fax vendors to ensure a seamless fax experience for customers who are new to Unified Messaging as well as those upgrading from Exchange Server 2007. Exchange 2010 no longer creates fax messages itself but instead forwards the inbound fax calls to a dedicated partner fax solution. The partner fax solution establishes the fax call with the remote endpoint and receives the fax media on behalf of the UM-enabled user. It then sends an SMTP message, which contains the fax as a TIFF attachment, to the recipient's mailbox. The Exchange 2010 UM server ensures that the fax message is formatted just like the fax messages coming from Exchange 2007 UM server (Figure 1). Figure 1: Example of Exchange 2010 UM fax message. To allow users to receive faxes via Exchange 2010 UM, customers must install and configure or sign up for service with one of the UM-certified partner fax solutions. At the time of writing, fax partner testing and certification is in progress. The list of compatible, UM-certified fax partners will be made available on our website when Exchange 2010 is launched. The new fax capabilities in Exchange 2010 RTM are controlled by the following attributes: FaxEnabled on UMDialPlan objects AllowFax and FaxServerURI on UMMailboxPolicy objects FaxEnabled on UMMailbox objects By default, when the user is first UM-enabled, the UMDialPlan.FaxEnabled and UMMailbox.FaxEnabled are set to true, whereas UMMailboxPolicy.AllowFax is set to false. In order to enable a UM user for fax, all three of these attributes must be set to true and UMMailboxPolicy.FaxServerURI must point to a valid partner fax solution endpoint. Whenever UMMailboxPolicy.AllowFax is set to true, FaxServerURI must be provided to indicate to the UM server where to redirect the fax calls. FaxServerURI must have the following form: sip: : ; , where "fax server URI" is either an FQDN or an IP address of the partner fax solution; "port" is the port on which the fax server listens for incoming fax calls and "transport" is the transport protocol over which the fax calls are made (udp, tcp or tls). For example, you might configure fax as follows: [PS] D:\>Set-UMMailboxPolicy MyPolicy -AllowFax $true -FaxServerURI "sip:faxserver.abc.com:5060;transport=tcp" You may be wondering how to secure communication with the partner fax solution. Partner fax messages must be authenticated; any unauthenticated message claiming to have come from a fax partner will not be processed by the UM server but instead will be delivered as a regular email. For authenticating the connection from the partner you can use mutual TLS, sender ID validation [1, 2], or establish trust via a dedicated receive connector. A receive connector should be sufficient for authenticating the partner fax solutions deployed in the enterprise together with the UM server. The receive connector will ensure that the Exchange server treats all traffic coming from the partner fax solution as authenticated. The connector should be deployed on the Hub Transport server used by the partner fax solution to submit SMTP fax messages and should have the following property values: AuthMechanism : ExternalAuthoritative PermissionGroups : ExchangeServers, Partners RemoteIPRanges : {faxserverIP} RequireTLS : False EnableAuthGSSAPI : False LiveCredentialEnabled : False If the partner fax solution that you are using sends traffic to the UM server over a public network (e.g., a service-based partner fax solution hosted in the cloud), it is recommended to authenticate the sender using a sender ID check. This validation ensures that the IP, from which the message originated, is in fact authorized to send emails on behalf of the partner domain that the message claims to have come from. DNS acts as an intermediary by storing the sender ID records (or SPF records); fax partners must publish their SPF records in the DNS and Exchange 2010 will validate these by querying DNS. The sender ID agent must be running on Exchange Edge servers in order to perform the query. Alternatively, TLS can be used for traffic encryption or mutual TLS for encryption and authentication between the partner fax solution and Exchange. The fax functionality of Exchange 2010 discussed here is not included with the beta version of Exchange 2010 but will be available with the RTM version. In the beta build of Exchange 2010, UM fax capabilities are completely disabled. To summarize, the fax messages destined for UM-enabled users of Exchange 2010 UM RTM will look exactly the same as the ones in Exchange 2007. However, to enable this behavior, a certified partner fax solution must be deployed together with the UM server. The UMMailboxPolicy objects must be configured to point to the fax solution and the SMTP exchange between the partner fax solution and the UM server must be authenticated. - Katarzyna Puchala References: [1] Fighting SPAM and Phishing with Sender ID. Internet Resource. Last Accessed 7/21/09. http://technet.microsoft.com/en-us/magazine/2006.12.sidf.aspx?pr=blog [2] Sender ID. Internet Resource. Last Accessed 7/21/09. http://technet.microsoft.com/en-us/library/aa996295.aspx John RobinsonSpotlight on Exchange 2010: Voice Mail Preview - Part 1: Introduction
Voice Mail Preview will literally transform the way that you look at voice messages in Exchange. Exchange Unified Messaging (UM) makes it easy to manage your voice messages by delivering them in your Inbox. You can then use many types of Exchange mail client software to review your voice mail. Microsoft Outlook, Outlook Web Access (OWA), Outlook Mobile (and other clients connected via Exchange ActiveSync) and, of course Outlook Voice Access (the speech access interface in Exchange UM) are examples of the ways that you can now retrieve voice mail. Figure 1. Exchange UM voice mail in the Inbox If you're using a visual mail client such as Outlook to review your voice mail, it's great to see at a glance the message details (date/time, length) and the number or name of the sender. In Outlook and OWA, you can even add your own text in an Audio Notes field. This permits you to annotate the message so that you can see what it's about, should you return to it later. You can also search for the message by one or more words in the note, as you're used to doing for e-mail. People who have used the Audio Notes feature since Exchange 2007 have surely sometimes wished that the annotations could be generated automatically. In Exchange 2010, the Voice Mail Preview feature will do this, and more. By the time that a voice message arrives in your Inbox, UM can insert a Preview. This is machine-generated text that is derived from the voice recording. You can usually gain a good sense of the recorded content by looking at the Preview. Text in the Preview is indexed, so you can search for voice messages without Audio Notes. You can add additional information or make corrections through the Audio Notes field, if required. Figure 2. Voice Mail Preview (sample message) Figure 2 shows an example of an actual voice message with a Preview, which I received recently. Some of the text in the figure has been obscured to protect the identity of the caller. In this case, the caller was a telemarketer and I was able to glance at the message (which arrived while I was in a meeting and unable to play the audio) and decide that it was (how shall I put this?) not at all urgent. In later articles in this series, I'll look at Voice Mail Preview in more detail, describing additional capabilities, how it works, and some limitations. - Michael WilsonSpotlight on Exchange 2010: Call Answering Rules (Part I) - Creating your first Call Answering Rule
One of the core functionalities provided by Exchange UM is call answering, i.e., to answer phone calls and record voice mails on your behalf. With the introduction of Call Answering Rules in Exchange UM 2010, you can dictate how incoming phone calls should be handled, thus enriching the call answering experience of your callers. In this article, we walk through the steps of creating a simple "default" call answering rule - one that is applied to all inbound phone calls. I don't have any Call Answering Rule. So what? Out-of-the-box, there are no Call Answering Rules created for you. All your callers will get the same default, call answering experience provided by UM 2007, i.e., callers will be prompted to leave you a voice message. Users who are satisfied with the default experience can continue to retain the same experience without the need to create any rule. Creating a Default Call Answering Rule As illustrated in Figure 1, the control for managing Call Answering Rules is located under ECP > Phone > Voice Mail tab. To create a new call answering rule, click on "New Rule". Figure 1: Call Answering Rule Control Anatomy of a Call Answering Rule Each Call Answering Rule comprises two key aspects: Conditions - what criteria must be met before the rule can be applied to an inbound call. Actions - what options should be presented to the caller when all the conditions are met. These actions will be read to the caller over the phone and users can then pick an action using the phone keypad. Figure 2 shows the form for creating a Call Answering Rule, which is divided into two columns. The right column displays the list of available conditions and actions you can use to build the rule. The left column displays the list of conditions and actions which have been added to the rule. Figure 2: Call Answering Rule Form Conditions There are 4 classes of conditions supported by Call Answering Rules, including: Caller ID Time-of-the-day Free/busy status Automatic email reply is enabled/disabled By using a combination of these conditions, you can create multiple Call Answering Rules and have them triggered for different phone calls. To create a default rule that will be applied to every call, you create a rule does not contain any condition. Since we are not adding any condition, I will not delve further into these conditions but leave them to my follow-up article. Actions There are 3 kinds of actions supported by Call Answering Rules, including: Find-Me Call Transfer Leave a voice mail Adding a Find-Me action When a caller selects Find-Me action, UM will attempt to locate you on up to 2 different phone numbers, and then connect you to the caller. To add a Find-Me option, click on "Find me at the following numbers". In the Find-Me dialog and with reference to my example in Figure 3 : You can optionally specify a context that will be read to the user. In my example, I have entered "important matters" to inform my callers that they should only select this action if they have important things to discuss. You need to associate the Find-Me action with a number on the keypad. This is the key which the caller has to press to select this action. In my example, I have also specified "1" as the DTMF key to be used. You also need to specify 1 to 2 phone numbers to be dialed. If 2 numbers are specified, they will be dialed in a sequential fashion, i.e., one after the other. Each phone number has an associated duration. This indicates how long UM should try dialing the phone number before moving on to the next number or revert back to the options menu. Click on Apply to add the Find-Me option and close the dialog. Figure 3: Find-Me Dialog Adding a Call Transfer option By configuring a Call Transfer action, you provide callers with the option to be transferred to someone else. To add a Call Transfer option, click on "Transfer the caller to..." link. In the Call Transfer dialog and with reference to my example in Figure 4. You can optionally specify a context that will be read to the caller as part of this option. In my example, I have entered "Unified Messaging" to inform my callers that they can choose this option if they have questions around "Unified Messaging." You need to associate the Find-Me action with a number on the keypad. I have specified "2" as the DTMF key to be used for this option. You need to specify a transfer target for this option. This can be in the form of a phone number, or you can select an AD contact for the call transfer. When specifying the AD contact, UM will attempt to transfer the call to the UM extension of the AD contact. If the AD contact is not UM-enabled, the AD business phone number field will be used. In my example, I have selected my manager "Michael Wilson" as the transfer target. Click on Apply to add the Call Transfer option and close the dialog. Figure 4: Call Transfer Dialog Adding Voice Mail action By default, the Voice Mail option is automatically added to each Call Answering Rule. If you do not wish to offer this option, you can remove it by clicking: To add the option back, simply click "Leave a Voice Message." Saving the rule and trying it out Prior to saying the rule, you need to give a meaningful name to the rule you've created. After which, you click on the SAVE button to create the rule. Next, you should test to see if the call answering rule is working as desired by trying to call your UM-enabled phone extension and wait for the call to be answered by UM. Optional: Record a customized greeting You can record a custom greeting for each rule. By default, UM will generate a default greeting based on the actions you have configured. To record a custom greeting, you can click on: in the Call Answering Rule form and UM will call you up to record a greeting. Note: In your recording, you should include any actions you have configured on the rule itself. UM will not list the actions if a custom greeting is present. -Chun Yong Chua
