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 ErnastSpeech recognition of names by Exchange 2007 unified messaging
Introduction Exchange Server 2007 Unified Messaging (UM) supports automatic speech recognition (in English, only). UM-enabled users who call into UM can speak to it for command and control in Outlook Voice Access (e.g. "Next message", "I'll be 20 minutes late"). They can also use speech recognition for directory searches. Callers who are connected to a speech-enabled UM automated attendant can benefit greatly from a speech-enabled directory. It is much easier for a caller to say the name of the person they want to contact than to spell the name, or enter the extension number, with the telephone keypad, UM builds speech grammars to constrain speech recognition's job. One or more grammars are active when UM is listening for speech input. Some of these grammars are used for command and control. These are installed with the product and do not change unless they are upgraded in a Service Pack, or later release. However, the grammars that constrain speech recognition for the directory cannot be created until UM has been installed at the customer site. Speech access to Active Directory is a very powerful feature of UM. However, speech recognition is not infallible, names may have unexpected pronunciations, and callers will not know how the name is entered into the directory[1]. While UM may do a reasonable job of name recognition "out of the box", it is likely that some fine-tuning will be needed to get the best results. This document describes the way in which UM builds speech grammars, and explains how customer-specific adjustments can be made to improve the overall success of speech access to the directory. Speech Grammars created from Active Directory by UM Types of Grammar UM may create several speech grammars from Active Directory. Each is tailored to a particular scope (GAL, Dial Plan, or Address List). By default, callers to a Dial Plan's pilot number, or to an associated Automated Attendant, can contact anyone in that Dial Plan. By default, UM users who log into their mailbox have access to the Global Address List[2]. Therefore, a UM server will generally create a grammar for the GAL, and another for each Dial Plan to which it belongs. Additional grammars are created as required. For example, an Automated Attendant may have a contact scope defined by a particular address list. UM users logged into Outlook Voice Access are also able to send voice messages to distribution lists. A grammar containing DL names is created to support this feature. Speech grammars created from the directory contain a set of definitions, each of which comprises a name (usually the name of a user) and a unique identifier (because two or more users may have the same name). When a caller speaks a name, UM passes their speech into the recognition engine, which searches the grammar(s) for names that match. More than one user may share the same name, and some names that are spelled differently sound identical, or very similar. Therefore, several possible matches may be found. If this happens, UM then tries to help the caller to find the actual user whom they want to contact. Generation Schedule Each UM Server will generate the speech grammars that it needs. This activity requires queries to Active Directory, and computation on the results. Its consumption of resources makes it desirable to run the activity at off-peak hours. The timing is controlled by a property on the UMServer object. The property is called GrammarGenerationSchedule. It describes a seven-day, recurring timetable, referred to local time (i.e. system time on the UM server). The times of grammar generation are determined by the following rule: Grammar generation will run once in each active period on the schedule, at the start of the period (except when prohibited by rule 4). Existing grammars will be replaced. Once started, grammar generation will run to completion, through all the grammars required by the UM Server. Grammar generation will not start within an hour of a previous generation. By default, the schedule contains a single active period, starting at 2:00 AM. Automatic grammar generation will therefore run once per day (unless the schedule is changed to specify otherwise). Where there are multiple UM Servers in a Dial Plan, it may be advantageous to adjust the grammar generation times to be different on the different servers. This spreads out the query load on the Active Directory. Scheduled grammar generation is recorded by Windows informational events from UM in the application event log. Event number 1131 records the start of a scheduled grammar generation. Event number 1132 records the end of a scheduled grammar generation. On-Demand Generation Speech grammars are generated if they are referenced by configuration but are not found when the UM service starts. This means that grammars will be generated automatically after the UM role is first installed on a server. Another way to generate grammars is to use the GALGRAMMARGENERATOR.EXE tool (in %ExchangeRoot%\bin). This is provided for help with troubleshooting: it should not be needed in normal operation. What UM Extracts from Active Directory into its Speech Grammars UM is selective about the directory objects that it will examine when creating a speech grammar. The types of objects selected depends on the scope of the grammar. For the GAL grammar, UM will extract the names and identities of: Mail-enabled users Mail-enabled contacts For Dial Plan grammars, UM will extract the names and identities of: UM-enabled users in the specified Dial Plan For the distribution list grammar (used only by Outlook Voice Access), UM will extract the names and identities of: Distribution lists that are visible in address lists Conversion and Filtering of Names from Active Directory into Speech Grammars Objects in Active Directory have display names. If an administrator adds a user to the directory with the Active Directory Users and Computers administrative tool, the display name of the user is usually formed by concatenating the user's first name, middle initials (if any) and last name. However, the display name thus created - though suitable for users who can see it in the address book - may not be in a form that callers will actually say (see footnote 1). There are other reasons why the display name may not be a good identifier in the speech grammar. For example: It may be preceded by a title (e.g. Mr., Ms., Dr.) It may be followed by a suffix (e.g. Jr., III) It may be of the form Last name, First name. It may be followed by organization-specific codes (e.g. department, location) All these effects combine to reduce the probability that a given user's name will be inserted into the speech grammar in a form that will be spoken by callers. Organizations often have policies about the means of creation and layout of user's display names in Active Directory. They should not be forced to change these working practices because of UM. Therefore, UM offers administrators some control over the transformation of display names into names that are inserted into the speech grammar. Figure 1 shows an example of the processes that take place during grammar generation. For clarity, only a single user is shown. Processing a users name(s) for a speech grammar: The user's display name is "Salas-Szlejter, Karolina". This name has four features that make it unsuitable for insertion into the speech grammar in its original form. The last name precedes the first name. Callers will expect (and it is much more natural) to speak the first name, and then the last name. The correct pronunciation of Szlejter sounds like Shlayter. People who know Karolina will undoubtedly get the pronunciation right, although the speech recognition and text-to-speech systems may not have this knowledge. People who do not know Karolina may well get the pronunciation wrong, in which case their naive guesses may actually approximate those of the speech engine. The first part of the surname (Salas) contains a character (small letter 'L' with stroke) that may cause problems for speech recognition or text-to-speech systems that are unfamiliar with the character.. The dash between Salas and Szlejter, although not significant to the way that the caller pronounces the name, may be interpreted literally by the speech engine. In fact, it may allow for multiple forms, such as "dash" and "hyphen", as well as for a silent form. Point 4 may not seem as important as the other three - after all, if the "correct" (silent) pronunciation of the dash is accounted for, why worry? However, UM deliberately rejects names that are considered to have multiple equivalent forms, for reasons of efficiency and overall accuracy[3]. There are three stages in the preprocessing of a directory object for the speech grammar (once the directory query has returned the object's display name, etc.). These are shown in Figure 1. Character Translation First, character translation takes place. In Exchange Server 2007 UM, only English language speech recognition is supported. One function of character translation is to render accented characters, digraphs and other special characters into forms more suitable for an English speech engine. For example, 'á' will become 'a' , the 'l' in the example above will become a plain 'l', and 'ß' will become 'ss'. The other function is to remove characters commonly found in people's names that do not contribute to the pronunciation. It is at this stage that '-' will become ' ' (space). Pattern Filtering Next, pattern filtering takes place. The name (after character replacement) is compared to a series of patterns, described by regular expressions.[4] Each pattern has an associated set of replacement patterns, that may be used to transform the name in various ways. Multiple replacement patterns are possible: a name from the directory may therefore give rise to more than one name in the speech grammar. Once a match (and possible associated transformation of the name) has been made, the search stops: no more patterns are examined for that name. If no match is found, the name is passed through this stage unchanged. The pattern filtering is controlled by the rules in a file called SpeechGrammarFilterList.xml, a copy of which is installed on every UM server. Here is an example of a filter rule: <Pattern> <!- Firstname (Nickname) Lastname -> <Input>^(\w+)\s+\((\w+)\)\s+(\w+)</Input> <!- ==> Nickname Lastname -> <Output>$2 $3</Output> <!- ==> Firstname Lastname -> <Output>$1 $3</Output> </Pattern> The <Input> element attempts (via a regular expression) to match names such as "Timothy (Tim) Sneath" that consist of a first name, a middle name in parenthesis, and a last name. Middle names that are bracketed this way conventionally represent nicknames. As such, they represent a likely way that callers will name the user. There are two <Output> elements for this rule. The first emits the middle name (thought to be a nickname) and last name, e.g. "Tim Sneath". The second emits the first name and last name, for those people who either do not know the nickname, or prefer to use the more formal first name, e.g. "Timothy Sneath". For this user example, this means that UM will accommodate callers who say either "Tim Sneath" or "Timothy Sneath". This addresses the problem described in footnote 1. No special configuration is required to get this particular behavior. This (and a number of other "generic" patterns) ship with in UM's speech grammar filter list. Text Normalization Check The final stage of directory name processing consists of a check with the speech engine that there is only one way to say the name (after any transformations in the previous two stages). As explained in footnote 3, this is a performance optimization. Insertion into Speech Grammar If the name passes the text normalization check and is not empty, it is inserted into the speech grammar. If not, an entry recording the reason for its omission is logged to a file. The name and location of the log file are recorded in UM event 1139 (informational). The name and location of the grammar file are recorded in UM event 1140 (informational). Grammar files have a .grxml extension, and are compliant with the Speech Recognition Grammar Specification[5], or SRGS. Configuring Speech Grammar Generation by UM Most probably, some callers will report that their attempt to contact a user failed because the UM system did not recognize the name that they said. There are two basic reasons why this may happen: The user's details are not in the speech grammar. The user's details are in the speech grammar, but what the caller said was not recognized correctly. If the user's details are not in the speech grammar[6], the reason is either that they were not mail-enabled, or that the name failed the text normalization check. Further details on the latter type of failure can be found in the grammar generation log file. As the preceding descriptions should have made clear, there are many reasons why the user may not be recognized, even if the caller says their name. These can be subdivided into: Recognition errors. The caller's speech was matched against the wrong name(s), or none at all. Name errors. The caller spoke a form of the user's name different from that in the grammar. There are many reasons why type (1) errors may occur. The caller may be speaking over a noisy connection. The caller may speak indistinctly, or very softly. There is little or nothing that the UM administrator can do about this. Type (2) errors can be reduced if the administrator is able to anticipate the kinds of mismatch that occur between the users' display names, as written, and their names as callers might speak them. The speech grammar filter list (see Pattern Filtering, above) is intended to be applied to names in bulk. However, problems with names are often related to individual entries. Figure 1 illustrates a case where the user's display name (Salas-Szlejter, Karolina) is in the reverse order to what a caller might say. This is handled by the speech grammar filter list. However, the resulting name (Karolina Salas Szlejter) may be a challenge for callers who have only the written or printed name to guide them. The solution to this and similar problems is to define a second display name for the user. This is called the phonetic display name. In the Active Directory, as extended by Exchange Server 2007 organization preparation, it is stored as a string attribute called msDS-PhoneticDisplayName. UM uses the phonetic display name (if present) in two ways. If the user has not recorded their nam e (for example, if they are mail-enabled but not UM-enabled), UM will play the phonetic display name (in preference to the display name) when it uses text-to-speech conversion to speak the name. UM will process the phonetic display name, as well as the display name, when creating a names speech grammar. The phonetic display name for the user in Figure 1 has been entered by the administrator as Karoleena Salas Shlayter. Although this is not the correct spelling, it it much more likely to be matched by the speech engine to a correct pronunciation of the name. The processed display name, on the other hand, can be used to represent a naive pronunciation of the name. To set the phonetic display name, administrators can use a directory tool such as ADSIEdit. However, it is also possible (and it may be easier) to use the Set-User cmdlet that is installed with the Exchange Management Shell, for example: Set-User -Identity karolsasz@contoso.com -PhoneticDisplayName "Karoleena Salas Shlayter" Summary Exchange 2007 Unified Messaging provides speech recognition services to help callers contact users just by speaking their name. However, user names as stored in Active Directory are often better suited to visual display than to speech recognition. They may have the last name first, or be spelled in such a way that the pronunciation is hard to guess by software, or by callers. UM uses a grammar generation process that can rearrange common names in a way that makes them more likely to be recognized from speech. For individual cases, UM allows the administrator to provide a per-user phonetic display name, which can be used to provide the speech engine with a textual version of the name that more closely matches what callers are likely to say. - Michael Wilson [1] Consider a user whose name appears as "Timothy (Tim) Sneath", in the directory. While this is visible to those who have access to the Exchange Address Book, or some other view of the directory, it is invisible to UM callers, who may say "Timothy Sneath" or "Tim Sneath" when asked who they want to contact. [2] Note that dialing rules and other properties may limit the user's ability to contact a person in the directory. [3] Consider the display name "Room 12/305". Such names could be present in the directory in large numbers, representing mail-enabled resources (conference rooms). The speech engine would automatically generate many equivalent forms of such a name (of which "Room twelve slash three hundred and five" and "Room twelve three oh five" are only two). Such names would rapidly bloat the dynamic grammar, and tend to reduce the speed and accuracy of recognition. [4] More specifically, the .NET flavor of regular expressions is used. See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpcondetailsofregularexpressionbehavior.asp for details. [5] See http://www.w3.org/TR/speech-grammar/ [6] The quickest way to tell whether a user is in the grammar or not is to search the file for their e-mail alias, e.g. findstr /i karolsasz@contoso.com gal.grxmlSpotlight 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 RobinsonUPDATE 2: Exchange 2007 Processor and Memory Recommendations
NOTE: This article has also been published in the official Exchange 2007 documentation. We recommend that you check the documentation for the most up-to-date version. Please see the following links: Planning Processor Configurations - http://technet.microsoft.com/en-us/library/aa998874.aspx Planning Memory Configurations - http://technet.microsoft.com/en-us/library/bb738124.aspx Planning Server Role Ratios - http://technet.microsoft.com/en-us/library/bb738159.aspx Introduction When selecting hardware for your Exchange servers, there are many things that you must consider. Two of the most critical resources are processor and memory. This article, an update to an article original posted on 3/13/2006 as well as updated article posted on 11/27/2006, provides processor & memory guidelines for minimum, recommended and maximum recommended configurations. There are several factors that go in to choosing the right hardware for an Exchange 2007 deployment. This article provides rule of thumb guidance on the primary factors which determine the proper memory and processor configuration for a given Exchange 2007 role. In separate articles we will cover other critical pieces to Exchange 2007 sizing such as storage and network hardware. Additional guidance will be provided as available throughout the Exchange Server 2007 development process. Exchange 2007 server hardware requirements are different than previous versions of Exchange (2003) The primary hardware difference between Exchange 2003 and Exchange 2007 is the move from a 32-bit platform (Exchange 2003) to a 64-bit platform (Exchange 2007). Exchange 2007 will only be supported in production environments when it is running on an x64 edition of Windows Server 2003 (Note: The Exchange 2007 Admin only installation is supported for production when using both the x64 and x86 versions of the software running on their respective processor platforms). The change from a 32-bit platform to a 64-bit platform requires a new approach to choosing server hardware for Exchange; especially processor and memory: Processor types supported by Exchange 2007 Exchange 2007 is only supported in production when the following are true: Running the x64 version of Exchange 2007 Running on Windows 2003 x64 Editions Running on x64 compatible processors The following processors support x64 versions of Windows 2003, thereby supporting Exchange 2007 deployments: AMD Opteron Intel Xeon processor with Intel® EM64T Each of these vendors also ship x64-capable desktop processors which can also run x64 versions of Windows 2003 (e.g. AMD Athlon64 and Intel Pentium D with EM64T) but for the sake of simplicity, this article will concentrate on processors designed for server deployments. It's important to note that the Intel Itanium (IA64) processor will not work with Windows 2003 x64 Editions, and thus it will not work for Exchange 2007 deployments. Exchange 2007 is designed to run only on x64 capable processors such as those listed above; Exchange 2007 will not run on Itanium based systems. Regardless of which server processor you select, it is necessary to have the server product pass the Designed for Windows test suite to ensure Microsoft support. Servers listed on the Windows Server Catalog meet these criteria. If your server is not listed, check with your vendor to see if either the "Designed for Windows" logo testing is in progress or the server has passed the testing and is pending a website update. Multi-core processor considerations for Exchange 2007 Exchange 2007 benefits significantly when running on multi-core processors. The performance benefit for Exchange from dual-core technology depends upon the specific processor utilized. The findings from Exchange 2003 dual-core testing have been summarized in Microsoft Knowledge Base article 827281, CPU and memory scalability for Exchange Server 2003 and for Exchange 2000 Server. Multi-core processors are an attractive option for Exchange 2007 servers based on price and performance. Please ask your server vendor about dual-core benefits for Exchange, specific to a given hardware architecture. Hardware specific memory considerations for Exchange 2007 Exchange 2007 enables much better memory utilization than Exchange 2003 due to its 64-bit architecture. Because of the virtual address space limitations of a 32-bit platform, Exchange 2003 is limited to using 4 GB or less of physical memory. In contrast, customers running Exchange 2007 on Windows 2003 x64 Editions can efficiently utilize upwards of 32 GB of memory (Mailbox role). Note: 32 GB is not a physical limitation, rather the most cost-efficient current maximum memory configuration. Depending upon the number of memory slots in a server, this cost-efficient maximum memory configuration could be even less than 32GB (e.g. 16GB). This change needs to be factored in when choosing server hardware. The following factors should be considered: Server Maximum Memory Configuration - Different server architectures have different memory limits. We recommend that you check the following technical specifications of the server to determine the criteria that affect the maximum memory configuration to ensure that the appropriate amount of RAM can be installed in to an Exchange 2007 server economically: Memory Speed - Some server architectures require slower memory to scale up the memory to ten's of gigabytes in a given server (e.g., maximum server memory is limited to 16GB with PC3200 or 32GB using PC2700). You should check with the manufacturer to make sure that the memory configuration target for Exchange 2007 is compatible in terms of speed. Memory Module Size - What is the largest memory module size the server will support? Generally, the larger the memory module, the more expensive it is; 2x1GB DDR SDRAM memory modules generally cost much less than 1x2GB DDR SDRAM memory modules. When planning for an Exchange 2007 server, make sure the maximum memory module size allows you to meet your target memory requirements. Total Number of Memory Slots - How many memory modules will a given server support? The total number of slots multiplied by the maximum memory module size will provide the maximum memory configuration for the server. Also, keep in mind that memory modules must sometimes be installed in pairs. Applying the processor and memory configuration factors to specific Exchange 2007 server roles The following chart can be used to assist in purchasing server hardware destined to be used for Exchange 2007 server roles. The goal of this chart is to provide minimum, recommended and recommended maximum configurations. Minimum: The minimum processor/memory configuration suitable for specific Exchange 2007 server roles (also defined in System Requirements). Minimum hardware requirements must be met to receive Microsoft Product Support Services. Recommended: This is the recommended processor/memory configuration for specific Exchange 2007 server roles. Recommended can be defined as "the best configuration based on price and performance." The recommended configuration also provides a balance between processor and memory capacity. The goal is to match the memory configuration to the processor configuration so the system will effectively utilize the processors without becoming bottlenecked on memory and vice versa. Maximum: This is the maximum recommended processor/memory configuration for specific Exchange 2007 server roles. Maximum is defined as "the upper bound of viable processor/memory configurations for Exchange 2007 based on price and performance." Maximum is a guideline and not a "support criteria" and does not take in to account the resource requirements of 3 rd party applications. The recommended maximum may change over time based on price changes and technology advancements. Processor Configuration Table for Exchange 2007 Role Minimum Recommended Maximum Edge Transport 1 x Processor Core 2 x Processor Cores 4 x Processor Cores Hub Transport 1 x Processor Core 4 x Processor Cores 8 x Processor Cores Client Access Server (CAS) 1 x Processor Core 4 x Processor Cores 4 x Processor Cores Unified Messaging Server (UM) 1 x Processor Core 4 x Processor Cores 4 x Processor Cores Mailbox Server 1 x Processor Core 4 x Processor Cores 8 x Processor Cores Multi Role (Hub, CAS, UM, Mailbox) 1 x Processor Core 4 x Processor Cores 4 x Processor Cores ** Processor Core recommendations are based on the following processor revision: AMD Option 275 2.2GHZ dual-core www.spec.org ratings may be used to rationalize unlike processors/server configurations. Edge Transport Role Edge transport is extremely efficient in design and thus requires moderate processing power. Also, fault tolerant Edge Transport deployments will utilize multiple servers to provide redundancy. The Recommended configuration on 2 x Processor Cores takes this fault tolerant deployment consideration in to account. Large enterprises, with a large volume of inbound/outbound SMTP traffic will be able to utilize 4 x Processor Core servers to reduce aggregate Edge Transport server count. Processor utilization is based on several factors such as: message rate, average message size, number of agents enabled, anti-virus configuration, 3 rd party applications etc. Hub Transport Role The recommended configuration for Hub Transport is 4 x Processor Cores in deployments where Hub Transport is deployed along with several Mailbox servers and thousands of mailboxes. 8 x Processor Core servers can be efficiently utilized when message hygiene is configured on the Hub server (A/V, Anti-Spam). 1-2 x Processor Core configurations can be considered for deployments where there are not enough mailboxes (message traffic) to utilize a 4 x Processor Core configuration. Processor utilization is based on several factors such as: message rate, average message size, number of agents enabled, Forefront Mailbox Virus Scanning configuration, 3 rd party applications etc. Client Access Server Role (CAS) Exchange 2007 architecture has moved significant client specific functions from the Microsoft Exchange Store to the Client Access Server. Messages are now converted on the CAS server when accessed with non-MAPI clients (e.g. POP3/IMAP4). Also, Outlook Web Access rendering is now performed on the CAS server as opposed to the Mailbox Store in previous versions of Exchange. These architectural changes allow CAS to offload significant processing from the Mailbox role and to allow it to effectively utilize 4 x Processor Cores. Similar to Hub Transport, servers with 1-2 x Processor Cores can be utilized for CAS in deployments where there are not enough mailboxes/non-MAPI client traffic to utilize 4 x Processor Core servers. Unified Messaging Role (UM) The recommended configuration for the Unified Messaging role is 4 x Processor Cores. Multiple Cores are well utilized on the UM server for several architectural functions such as Voicemail WAV to WMA conversions. Similar to previous roles, 1-2 x Processor Core configurations may be utilized when the mailbox count/UM utilization does not necessitate 4 x Processor Core configurations. Mailbox Role The recommended configuration for the Mailbox role is based predominantly on mailbox count and user profile. A 4 x Processor Core server provides a good balance between price and performance and should be able to host several thousand mailboxes. Rule of thumb sizing for the Mailbox server role requires an understanding of the average client user profile. This profile can be collected using the Microsoft Exchange Server Profile Analyzer or with 3 rd Party tools/applications. The following table lists generic/common Outlook knowledge worker profiles: User Type Send/Receive per day (~50kb Message size) Light 5 sent/20 received Average 10 sent/40 received Heavy 20 sent/80 received Very Heavy 30 sent/120 received There are several factors that go in to doing Mailbox server sizing for Exchange 2007 which are above and beyond the user type listed above. These include Exchange 2007 features such as Local Continuous Replication (LCR), Forefront Mailbox Virus Scanning, 3 rd Party applications, 3 rd Party mobile devices, and Microsoft Outlook client version/mode (Online vs Cached Exchange Mode etc.). Rule of thumb sizing used primarily for budgeting purposes can be accomplished by calculating that 1000 Average profile mailboxes will require 1 x Processor Cores. E.g. A 4000 Mailbox server with an Average usage profile can be estimated to require 4 x Processor Cores. A Heavy usage profile will effectively double the required processor cycles (or halve the number of users per processor core;500 Mailboxes/Processor Core). On the other hand, a 2000 Mailbox server with an Average profile can be estimated to require a 2 x Processor Core server. The maximum number of processor cores the Exchange 2007 Mailbox role will efficiently utilize is eight. Deploying Exchange 2007 Mailbox on servers with greater than eight cores will not provide significant scalability improvements. *** Concurrency: Concurrency is defined as the percentage of the total number of users on a server that are connected and using the server at a given peak period of time. Concurrency is difficult to measure since users may use multiple clients/devices and different versions of Outlook have various connection counts to the server. For a fully utilized server, concurrency is generally in the 75-80% range. The guidance in this article assumes this average concurrency profile. Sizing additional processing capacity for Local Continuous Replication (LCR) Local Continuous Replication (LCR) has all of the Exchange 2007 Mailbox role services as well as the Exchange 2007 Replication Service running on the same server. On an LCR Mailbox server, there is additional processing overhead generated from the Replication Service copying and playing in logs to the target database copy. This additional processing cost is roughly 20% and should be factored in when sizing LCR Mailbox servers. Multi-Role (Mailbox, Hub, CAS) The Multi-Role configuration has similar guidance and limitations as the Mailbox role. To accommodate CAS and Hub Transport utilization on a single server with the mailbox, reduce the 1000 Mailboxes/core calculation based on the Average client profile by 20% (800 Mailboxes/core) when performing rule of thumb sizing for Multi-Role servers. The maximum recommended processor core configuration is listed at 4 for the Multi-Role configuration to indirectly provide guidance on the maximum number of users recommended to be hosted in this scenario. Neither Clustered Continuous Replication (CCR) nor Single Copy Cluster (SCC) support hosting the Hub nor CAS server so a Multi-Role server has to be non-clustered by definition. It is a good idea to cluster Mailbox servers that host thousands of user to ensure patch management and server failures do not have a significant impact on up time. The more users hosted on a Mailbox server the more user "pain" is caused by server downtime. For this reason, the recommended maximum processor core configuration for the Multi-Role server is listed at 4. While the this configuration will perform well up to 8 processor cores, it is not recommended due to the availability concerns outlined above. Memory Configuration Table for Exchange 2007 Once the number of processor cores have been estimated to be required per server role are understood; baseline memory recommendations can be applied. The following table illustrates the Minimum, Recommended and Maximum memory configurations for Exchange 2007 server roles. Role Minimum Recommended Maximum Edge Transport 2GB/Server 1GB/Core (2GB minimum) 16GB/Server Hub Transport 2GB/Server 1GB/Core (2GB minimum) 16GB/Server Client Access Server (CAS) 2GB/Server 2GB/Core (2GB minimum) 16GB/Server Unified Messaging Server (UM) 2GB/Server 1GB/Core (2GB minimum) 4GB/Server Mailbox Server 2GB/Server: Variable based on Storage Group Count. See below 2GB +2MB to 5MB/mailbox: Variable based on user profile, see Mailbox Memory Recommendation in table below 32GB/Server Multi Role (Hub, CAS, UM, Mailbox) 4 GB: also depends on number of storage groups (For information, see later in this topic.) 8 GB plus from 2 MB to 5 MB per mailbox. This is variable based on user profile. For more details, see "Mailbox Server Role" later in this topic. 32GB/Server Edge/Hub Transport Roles The Edge and Hub Transport roles do not require substantial quantities of memory to perform well in optimal conditions. Generally, 1GB of RAM per processor core (2GB minimum total) is sufficient to handle all but the most demanding loads/scenarios. There is one significant memory factor that should be taken in to account for large deployments: Large Queue Scenarios: Exchange 2007 Edge/Hub Transport servers are designed to handle scenarios where extremely large queues build up (e.g. 1 million messages in a single server queue). Edge/Hub Transport servers hold the queued message recipient information in memory to optimize the SMTP send and message retry operations. When sizing Edge/Hub Transport servers for large queue scenarios, use the following table to estimate the memory requirements: Memory Factors/Queued Message Memory Consumed Per Message Overhead 3KB Per Recipient Overhead 1KB The recommended maximum memory configuration of 16GB is based on the Edge/Hub Transport servers handling 1 million messages with an average number of recipients each. Most deployments will be optimally configured with the "Recommended" memory configuration of 1GB per processor core (2GB minimum total). Client Access Server Role (CAS) In general, memory utilization on Client Access servers has a linear relationship with the number of client connections and the transaction rate. Based on the current recommendations for processor and memory configurations, a Client Access server will be balanced in terms of memory and processor utilization, and it will become processor bound at approximately the same time it becomes memory bound. Mailbox Role The memory configuration process for the Mailbox role is more involved than the other roles since the optimal memory configuration depends upon the mailbox count and the client profile (similar to estimating processor core requirements). Memory sizing for the Mailbox role is critical to reducing the I/O requirements of the server. The more memory you add to the Mailbox server, the less I/O will be generated by the Exchange databases. There is a point of diminishing returns; in which adding additional memory to the server may not be justified based on price/performance. Memory guidance outlined here takes this point of diminishing returns in to account based on current memory prices and performance metrics. Also, defining the memory configuration of the Exchange 2007 Mailbox server is required prior to defining the storage requirements/configuration. The following table can be used to assist in estimating the memory requirements of a given mailbox server with a given number of hosted mailboxes with a given profile type (taken from previous profile table). User Type Mailbox Memory Recommendation Light 2GB + 2MB/Mailbox Average 2GB + 3 ½MB/Mailbox Heavy 2GB + 5MB/Mailbox Recommended Maximum Memory Configuration for Mailbox Recent x64 based servers have the ability to scale up their memory configuration to 64GB and beyond. There are several reasons why Microsoft does not recommend maximum memory configurations for Mailbox that go beyond 32GB. Cost: Based on current memory prices (specifically 4GB DIMMs), it is cost prohibitive to expand the physical memory capacity of a server beyond 32GB. Generally, the cost of physical RAM is linear up to 32GB; beyond this the cost trend is exponential. Beyond 32GB, for many configurations, it is less expensive to add disk drives as opposed to memory. Non-Transactional I/O: The Mailbox server utilizes additional physical RAM by caching more data and thus reducing the database I/O footprint for transactional I/O (I/O that is generated by send/receive/client processing of email). There are several sources of non-transactional I/O generated on the Mailbox server. These include Online Maintenance (e.g. Online Defrag), Offline Maintenance (e.g. offline defrag, database repair operations), Backup/Restore operations, Mailbox Management Processes (e.g. Messaging Records Management (MRM)), All of these operations require database I/O to properly maintain and recover the server. Although Exchange 2007 has reduced transactional I/O significantly; adequate storage performance is still required for proper maintenance of the Mailbox server. For this reason, there is a point of diminishing returns when adding memory to the server. In general, the purpose of adding memory to the Exchange Mailbox server is to reduce the storage requirements (specifically performance) and thus storage cost. Due to non-transactional I/O requirements; the storage requirements of the system may not be significantly reduced by adding server memory beyond 32GB. Cold State Operation: Cold state is defined as the state of the Mailbox server immediately following a server reboot or store.exe process restart. The Database Cache, which is used to cache database read/write operations, is small in size (or "cold") during this period so it has a significantly diminished ability to reduce read I/O operations. As the Mailbox server processes messages, the Database Cache Size grows which increases the effectiveness of the cache and subsequently reduces the I/O footprint of the server. The larger the physical memory size of the server the longer it takes the Database Cache size to reach its optimal size. If the storage is designed/sized for a server with a large amount of physical RAM (>32GB), and the I/O profile of the users assumes an optimal Database cache state (large/warm cache); then the client experience may be compromised due to insufficient disk performance during these "cold state" periods. Similar to the Non-Transactional I/O case; the storage subsystem requirement may be the same for a server that has been populated with 32GB of RAM as a server that has been populated with greater than 32GB of RAM. While the Exchange 2007 Mailbox role will utilize memory greater than 32GB, for the reasons outlined above; 32GB is the maximum recommended memory config and is considered the point of diminishing returns in terms of both cost and performance. Required Minimum Memory Configuration for Mailbox based on the number of Storage Groups The maximum number of Storage Groups configurable in Exchange 2007 has been increased to 50 in the Enterprise Edition (up from 4 with Exchange 2003). This increase provides much greater flexibility in server/storage architecture, but the increase has a significant effect on the memory utilization of the Exchange 2007 Mailbox server so Storage Group count is now a factor in minimum memory configuration for Mailbox and Multi-Role servers. Increasing the number of Storage Groups primarily effects the Database Cache utilization of ESE (Extensible Storage Engine). The ESE Database Cache is used for both read and write activity. Due to the way Checkpointing works, adding a Storage Group effectively increases the amount of the Database Cache used for write activity. This has a positive impact of reducing database write I/O; but if too many Storage Groups are configured on a server with insufficient physical memory, the effectiveness of the database read cache may be reduced which may have an overall negative effect on the performance of the server. For this reason, minimum hardware requirements for Mailbox and Multi-Role uses the following table to provide specific minimum memory requirements based on Storage Group count configured on a per server basis. Storage Group Count Minimum Required Physical Memory 1-4 2GB 5-8 4GB 9-12 6GB 13-16 8GB 17-20 10GB 21-24 12GB 25-28 14GB 29-32 16GB 33-36 18GB 37-40 20GB 41-44 22GB 45-48 24GB 49-50 26GB *** This table includes the 2GB minimum memory requirement. Mailbox and Multi-Role Server configurations must meet the requirements outlined in the above table to receive Microsoft support. The minimum physical memory requirements based on SG count closely match our recommendations on memory sizing based on mailbox count and profile (detailed above). Example 1: A 4000 user Mailbox server with a heavy user profile would calculate out to 22GB of RAM (2048MB+ (4000*5MB)). Based on the above support requirements, the administrator will have the flexibility to use up to 44 Storage Groups. Additional RAM would be required to deploy greater than 44 Storage Groups based on the above supportability requirements. Example 2: A 1000 user Mailbox server with a light user profile would calculate out to 4GB of RAM (2048MB+(1000*2MB)). Based on the above support requirements the administrator will have the flexibility to use up to 8 Storage Groups. Additional RAM would be required to deploy greater than 8 Storage Groups based on the above supportability requirements. Memory Recommendations for Local Continuous Replication (LCR) Local Continuous Replication (LCR) has all of the Exchange 2007 Mailbox role services as well as the Exchange 2007 Replication Service running on the same server. The Exchange 2007 Replication Service will work well on a LCR server based on the provided memory guidance but to ensure that the ESE Database Cache maintains optimal efficiency under LCR, it is recommended to provision an additional 1GB of physical RAM to Exchange Mailbox and Multi-Role servers (above and beyond the memory guidance listed above). Multi-Role (Mailbox, Hub, CAS) Guidance and limitations similar to the Mailbox server role apply to multiple server role configurations. To accommodate the Client Access and Hub Transport server roles on the same server as the Mailbox server role, the recommended base memory configuration is 8 GB. Memory guidance based on mailbox count and profile is the same as the Mailbox server role. The recommended maximum amount of memory is 32 GB. Neither cluster continuous replication (CCR) nor single copy cluster (SCC) supports hosting the Hub Transport or Client Access server roles in a failover cluster. A multiple role server is non-clustered by definition. It is a good idea to cluster Mailbox servers that host thousands of mailboxes to ensure that server maintenance or failures do not have a significant impact on uptime or availability. The minimum memory requirements based on the number of storage groups listed in the preceding table apply to multiple role server configurations, including configurations that contain the Mailbox server role. Server Role "Rule of Thumb" Ratio Recommendations Once optimal server role processor/memory configurations have been finalized, the next logical sizing task is to make a rough prediction of how many server roles of each type are required for your deployment. As with any sizing exercise, every environment is different; so these recommendations should be considered starting points that can then be tailored to specific environments. The recommendations are also based off of Microsoft's own Exchange 2007 deployment with the following characteristics: User Profile Heavy->Very Heavy Primary Client (Weekday working hours) Outlook 2003/2007 Cached Mode (MAPI/RPC) Primary After Hours/Weekend Clients Outlook 2003/2007 Cached Mode (RPC/HTTPS) & OWA Percentage of user base utilizing AirSync 25% The recommended "Rule of thumb" ratio for each role is based on processor cores (like our other guidance in this document), since it is common for roles to have vastly difference processor core counts. Also, the Mailbox server role is the basis for the process core ratios. Hub and CAS roles relate back the Mailbox role with regard to the rule of thumb recommendation. Role Ratio Processor Core Ratio Rule of Thumb Mailbox:Hub 7:1 (no A/V on Hub) 5:1 (with A/V on Hub) Mailbox:CAS 4:1 These recommendations have the following caveats: General: Ratio is a "rule of thumb" and may not be valid for every topology (not a support requirement or hard and fast rule). Ratios can change dramatically based on user profiles. E.g. A profile that creates correspondingly more load against the Mailbox role than the Hub role will increase the Mailbox:Hub ratio; and vice versa. This guidance follows Microsoft's internal Exchange deployment for Mailbox servers which is based on the ~500 "Heavy" users per processor core. Ratio assumes Mailbox role servers are +60% processor utilized during peak period with corresponding processor utilization on Hub or CAS. Processors used on Mailbox role and Hub/CAS roles are of same type and speed. www.spec.org ratings may be used to rationalize unlike processors/server configurations. A minimum of two Hub and two CAS servers should be deployed for redundancy to ensure uninterrupted service in case of planned or unplanned server downtime. The Exchange 2007 Management Pack for MOM 2005 SP1 combined with the Performance Troubleshooter, built in to the Exchange 2007 Management Console; can be used to determine when/if a given deployment requires additional Hub, Edge, CAS or Mailbox server roles based on performance. This method can be used to fine tune the server role ratios for a specific deployment. Hub: Hub ratio rule of thumb where A/V is enabled assumes Forefront A/V with five engines scanning. CAS: CAS ratio rule of thumb assumes SSL is enabled for all appropriate access protocols. It is not possible to provide Edge and UM ratios since their utilization are not directly tied to the Mailbox server role. UM server sizing is covered in Determining the Number of Users an Exchange 2007 Unified Messaging Server Can Support. Edge server sizing is covered next. Edge Server Sizing Determining Edge server count is based off the following key factors during peak period: Connections/sec Messages/sec Avg. Message Size Sizing is based on the number of connections/messages processed with Avg. message size being a secondary factor. Since every SMTP connection does not translate in to an SMTP message and every message initially accepted does not make it passed IMF/Anti-Virus scanning; it is very difficult to provide a simple sizing methodology based on message rate. Edge utilization will depend on several factors that are very specific per individual deployment. The following table can be used, however, to get an understanding of Edge's performance characteristics based on Microsoft's own internal Exchange 2007 deployment: SMTP Connections/Sec 55 % Connections Accepted 80% Avg. Recipients/Msg 1.25 Recipients Rejected/Sec 3.5 SMTP Messages IMF Scanned/Sec 3.7 % SMTP Messages passed IMF Scanning 80% SMTP Messages A/V Scanned/Sec 3 Avg. Message Size 70KB CPU Utilization 20%** ** Based on a 2 socket, dual-core AMD Opteron 275 2.2 GHz based server. A minimum of two Edge servers should be deployed for redundancy to ensure uninterrupted service in case of planned or unplanned server downtime. In the above example, a significant percentage of the server processing can be associated with the overhead of analyzing connections and scanning accepted messages. For this reason, it is not possible to provide a sizing metric based solely on the number of messages sent/received per second since blocking spam/viruses is a significant processor utilization function of the Edge role. Summary With effective planning and an understanding of the basic processor and memory requirements for specific Exchange 2007 server roles, a balanced/cost effective topology can be easily attained. - Matt GossageCall 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 ChuaManaging Voice Mail Options for A Shared Mailbox
Is there a way to allow users with Full Mailbox Access to a shared mailbox which has Unified Messaging enabled to manage the "Voice Mail / Call Answering Rules etc" options section in OWA? They can manage their own just fine, but not for a shared mailbox ... I know we can use PowerShell / EWS etc. but not found a way to allow via the web interface yet,Understanding 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 Chua
