Skype for business premise USER migration to cloud error
I get the following error when I try to move a user to Teams Move-CsUser -Identity [USER] -Target "sipfed.online.lync.com" -UseOAut Move-CsUser : Rollback from Unified Contact Store failed for user: with exception: Rollback failed because user was not found or available on the Skype for Business Server.. Any ideas ?
SFB: Tearing down sessino due to failure in pending disclaimer state
Hello everyone I have monitoring reports deployed. in the conferencing diagnostic report, i am seeing unexpected failure with diagnostic header "52507; reason="Tearing down session due to failure in pending disclaimer state"". What does this mean? Cheers and stay safeauthentication issue??
Hi All I am not great with S4B so i am hoping for a little help. One of my clients is trying to set up a skype meeting on behalf of another account... he apparently has the correct permissions but gets an error stating that the user accounts in outlook and S$B do not match. i have taken a look and SIP and SMTP adresses for both users are ok. the only difference i can see is that 1 account is homed in Azure AD and the other on Windows Server AD.... how can i resolve this issue...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 team
Skype for Business Online Extension Dialing Mobile App
Hi, We have a SfB 2019 Hybrid with SfBO and On-prem PSTN with Audiocodes mediant 1000b with IIS ARR 3.0 as RP. When we move a user to the cloud, he is suddenly not able to dial out with extension from the mobile app. When he tries he instantly gets "The call couldn't be completed. Please try again later." He is able to do the same from a PC though... When I move him back to on-premises, he is again able to dial extensions from both phone and PC. I found and set this up for a few test users, sadly without any success - https://blogs.technet.microsoft.com/cloudready/2017/08/01/skype-for-business-online-extension-dialing/ Am I missing something? I cannot find any other information on this topic... It looks like it should be possible I just don't know what I am missing here. Thanks!Troubleshooting the Messaging Waiting Indicator status in Exchange 2010 Unified Messaging server
There are a number of ways an end-user may learn that they have new voice mail, such as from client software like Microsoft Outlook, OWA , Lync, Communicator, or different types of indicators on IP , smart and traditional phones. The term Message Waiting Indicator (MWI) is usually applied to notifications delivered by the user’s phone using mechanisms such as a light on the phone, a special icon or highlighted notification or even a special dial tone. Exchange 2010 includes built-in support for MWI . For more details, see Understanding Message Waiting Indicator in Exchange 2010 documentation. Exchange 2010 Unified Messaging also includes a feature called Voice Mail Preview which uses automatic speech recognition (ASR) to add a text version of the voice mail that's delivered to the user's Inbox (along with the MP3 voice message). This allows users to read their voicemail messages. See Voice Mail Preview Advisor for Exchange 2010 for details. This article describes steps on how to use the event logs on Exchange 2010 Unified Messaging (UM) and Mailbox servers to troubleshoot MWI failures. Also included in this article are settings to validate MWI configuration on Exchange. Flow of MWI notifications on Exchange servers A voice message is left for a user and is stored in the user's Exchange mailbox on a Mailbox server. The Mailbox Assistant service on the Mailbox server checks the status of voice mails in the user’s mailbox. The Mailbox Assistant service makes an RPC connection to a Unified Messaging server associated with the user’s UM Dial Plan. The UM server sends a SIP NOTIFY message with the MWI state change to a UM IP Gateway associated with the user’s UM Dial Plan. The starting point of a MWI notification is after the voicemail has been placed in the end user’s mailbox. The focus of these troubleshooting steps are on the Exchange messaging side to diagnose MWI notification issues between a Mailbox server and a UM Server, and also between the UM server and a UM IP Gateway. Contents Troubleshooting Steps: Check the event log on the mailbox server Increase the UM MWI event logging level on the Mailbox server Identify the UM IP Gateway and UM server On the UM server look for a SIP OPTIONS failure Increase the UM MWI event logging level on the UM server Check connectivity between the UM server and the UM IP Gateway. New Unified Messaging server event ID for SIP OPTION failures Summary of settings to validate Useful links Troubleshooting Steps Check the event log on the mailbox server Confirming the Mailbox server is not logging MWI errors will help to isolate the problem to a later notification handling step. The first step in sending the MWI notification is the retrieval of the MWI state from the user’s mailbox on the mailbox database. Once the state of the MWI is known, the mailbox server must be able to make an RPC connection with the UM server to relay the MWI state information. Any of the following events, if found on the Mailbox server, would be the starting point for a deeper look at the Mailbox server. Also UM event logging can be increased on the mailbox server to confirm that the MWI notification was successfully sent to the UM server. On the Exchange 2010 Mailbox server, look for Event ID 1346 in the Application Event log. It indicates there may be an issue with the database or the database might be dismounted. Log Name: Application Event ID: 1346 Source: MSExchange Unified Messaging Date: 4/15/2011 6:55:52 PM Task Category: MWI General Level: Warning Keywords: Classic User: N/A Computer: Ex2K10MailboxServer.Contoso.com Description: The Message Waiting Indicator Assistant was unable to query the mailbox database 'MailboxDB01#GUID'. The MWI assistant will try to query the mailbox database again in 720 minutes. If you continue to see this warning, there could be a problem with the mailbox database or the Mailbox server. Additional information: Microsoft.Mapi.MapiExceptionMdbOffline: MapiExceptionMdbOffline: Unable to get mailbox information. (hr=0x80004005, ec=1142) Diagnostic context: Lid: 20354 Presence of Event ID 1345 on the Mailbox server indicates there may be a problem with the user’s mailbox. The ‘Additional information’ will contain MAPI error codes and additional information to diagnose the specific issue. Here's an example: Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 6:45:52 PM Event ID: 1345 Task Category: MWI General Level: Warning Keywords: Classic User: N/A Computer: Ex2K10MailboxServer.Contoso.com Description: The Message Waiting Indicator Assistant was unable to obtain the MWI state for mailbox 'John Doe (#ExchangeGuid)' on database 'MailboxDB01#GUID'. You can safely ignore this warning if the mailbox is currently disconnected or inactive. Additional information: (Various MAPI error descriptions). Event ID 1360 on the Mailbox server indicates that there might be an RPC communication issue between the Mailbox server and the UM server. A communication issue between the mailbox and the UM server could be due to an issue on either server. For example: Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 7:05:52 PM Event ID: 1360 Task Category: UMCore Level: Warning Keywords: Classic User: N/A Computer: Ex2K10MailboxServer.Contoso.com Description: The Message Waiting Indicator Assistant failed to deliver the MWI notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension '+15555555555'. Until this problem is corrected, the MWI state for this user may be out of sync. Additional information: Server Ex2K10UMServer failed with 1722 Error 0x6ba (The RPC server is unavailable) from SendMwiMessage Note: You may also see: There are no more targets available to send an MWI message for user John Doe. If the UM MWI event logging level is increased on the Mailbox server, the success event for the MWI notification is logged to the Application event log with ID: 1343, which indicates that the Mailbox server has successfully submitted a MWI notification to the UM server. This command shows the current logging level of MWI on the mailbox server: Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto The output: Identity EventLevel -------- ---------- MSexchange Unified Messaging\MWI General Lowest This command raises the MWI logging level to ‘Expert’ and you will start to see the MWI ‘Success’ events (Event ID: 1343) in the Application event log. [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | Set-EventLogLevel -Level:Expert You can use the Get-EventLogLevel cmdlet again to verify that the MWI logging level has been raised to Expert level. For more details about diagnostic logging levels in Exchange 2010, see Manage Diagnostic Logging Levels. The increase in logging show will show that mailbox server has successfully submitted the MWI notification to the UM server. For example: Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 7:15:26 PM Event ID: 1343 Task Category: MWI General Level: Information Keywords: Classic User: N/A Computer: Ex2K10MailboxServer.Contoso.com Description: A Message Waiting Indicator (MWI) notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com' was succesfully sent to 'Ex2K10UMServer'. Identify the UM IP Gateway and UM server From the UM server: If you already know the UM server in use, then check the Application Event log for event 1344 identifying an MWI and the user affected. The PowerShell commands further below will help to validate Exchange configurations settings for the MWI. Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 6:30:52 PM Event ID: 1344 Task Category: MWI General Level: Warning Keywords: Classic User: N/A Computer: Ex2K10UMServer.Contoso.com Description: The Unified Messaging server failed to deliver the MWI notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com'. Until this problem is corrected, the MWI state for this user may be out of sync. Additional information: An MWI message couldn't be delivered in the allocated time for user John Doe. Server MyIPGateway1 failed with 0 Unable to establish a connection. Server MyIPGateway2 failed with 0 Unable to establish a connection. The ‘MyIPGateway#’ indicates one or more Exchange UM IP Gateways objects associated with the dial plan for the user. The UM IP Gateway should also be checked to confirm that the MWI is enabled with the MessageWaitingIndicatorAllowed set to True. See further below for an example. From the recipient: If you have a specific user you are validating MWI functionality, the steps below are also useful to validate that each portion of the messaging configuration has MWI enabled for the user. The user must be UM enabled, and MWI must be enabled ‘True’ on the UM Mailbox Policy and the UM IP Gateway in Exchange, to be configured to deliver MWI notifications. Please be sure to check the health and status of the user’s mailbox server first. Identify the UM server and UM IP Gateways that the user would be associated with. First find the UM dial plan linked with the user. The recipients UM dial plan (and UM Mailbox Policy) can be found for a user with Get-UMMailbox. Get-Recipient will provide much of the same data. For example: Get-UMMailbox johndoe@contoso.com | select UMEnabled, UMDialPlan, UMMailboxPolicy, UMSMSNotificationOption | FL The output: UMEnabled : True UMDialPlan : MyUMDialPlan UMMailboxPolicy : MyUMMailboxPolicy UMSMSNotificationOption : VoiceMail Alternatively, using the Get-Recipient cmdlet retrieves the following data. [PS] C:\>Get-Recipient johndoe@contoso.com | select UMEnabled, UMMailboxPolicy, UMRecipientDialPlanId | FL UMEnabled : True UMMailboxPolicy : MyUMMailboxPolicy UMRecipientDialPlanId : MyUMDialPlan Next, let's look at the UM Mailbox Policy by using the Get-UMMailboxPolicy cmdlet and confirm that the policy is MWI enabled (AllowMessageWaitingIndicator is set to True). Get-UMMailboxPolicy -Identity MyUMMailboxPolicy | select AllowMessageWaitingIndicator, AllowSMSNotification | FL AllowMessageWaitingIndicator : True AllowSMSNotification : True The UM servers and IP Gateways associated with the recipient’s dial plan can be found with the Get-UMDialplan cmdlet. For example, Get-UMDialplan -Identity MyUMDialPlan | select UMServers, UMMailboxPolicies, UMIPGateway | FL UMServers : {Ex2K10UMServer, Ex2K10UMServer2} UMMailboxPolicies : {MyUMMailboxPolicy} UMIPGateway : {MyIPGateway1, MyIPGateway2} The UM IP Gateway in Exchange should also be confirmed that the MWI is enabled and set to ‘True.’ Get-UMIPGateway -Identity MyIPGateway1 | FL MessageWaitingIndicatorAllowed MessageWaitingIndicatorAllowed : True On the UM servers listed in the dial plan look for Application event log ID 1344. This event will show the MWI failure for the user. This will also indicate which UM IP Gateways that may have a communications issue where the SIP Options fail. Look for a SIP OPTIONS failure on the Unified Messaging server Connection issues between the UM server and physical UM IP Gateway device, may appear as SIP OPTIONS failure events on the UM server. With the UM IP Gateway from either the dial plan or directly on the UM server, you can look for Application event log ID 1400 that indicates a SIP OPTIONS failure to the specific Gateway. For example: Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 6:31:28 PM Event ID: 1400 Task Category: UMCore Level: Warning Keywords: Classic User: N/A Computer: Ex2K10UMServer.Contoso.com Description: The following UM IP gateways did not respond as expected to a SIP OPTIONS request. Transport = TLS, Address = MyIPGateway1.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection. Transport = TLS, Address = MyIPGateway2.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection. Note: The error text will be different depending on the type of failure; you may also see "This operation has timed out.", “Unknown error (0x80131500)”, or as shown “Unable to establish a connection.” The Port may be different from ‘5060’. If mutual TLS has been configured the port is use will be 5061. Increase the UM MWI event logging level on the UM server To get confirmation that the Exchange UM server successfully submitted the MWI notification to the Gateway device, you will need to increase the logging level for MWI on the UM server. You may see a new Application event ID: 1343. The ID: 1343 is a ‘success’ entry for having notified the Gateway device of the MWI state. If the Exchange UM server successfully submitted the notification, then the next step would be to check the Gateway device’s functionality with the Gateway’s downstream devices. Run the command below to view the current logging level of MWI on the UM server. [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto Identity EventLevel -------- ---------- MSexchange Unified Messaging\MWI General Lowest To increase the MWI logging level to see the MWI success events you can run the following command. This will set the logging level to ‘Expert’ and you will start to see the UM MWI ‘Success’ ID: 1343 events in the Application event log. [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | Set-EventLogLevel -Level:Expert You can now see that the MWI logging level has been increased. [PS] C:\>Get-EventLogLevel "MSexchange Unified Messaging\MWI General" | FT -auto Identity EventLevel -------- ---------- MSexchange Unified Messaging\MWI General Expert The increase in the UM server’s MWI logging level show will show that UM server has successfully submitted the MWI notification to the UM IP Gateway with the following event. The failure to notify end users would then be with the Gateway device or downstream functionality. For example, Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 7:15:45 PM Event ID: 1343 Task Category: MWI General Level: Information Keywords: Classic User: N/A Computer: Ex2K10UMServer.Contoso.com Description: A Message Waiting Indicator (MWI) notification '1/29 (unread/read)' for the UM-enabled mailbox 'John Doe (#ExchangeGuid)' associated with UM extension 'johndoe@contoso.com' was succesfully sent to 'MyIPGateway1'. Check connectivity between the UM server and the UM IP Gateway There are a number of factors that impact communications between the UM server and the UM IP Gateway. If TLS (Transport Layer Security) is being used, certificates are a common item to check. When other functionality is working between the UM server and the Gateway, there could be an issue in how the SIP NOTIFY is being handled. Basic network checks to confirm TCP/IP connectivity. If the UM Gateway listed is a FQDN, confirm that the correct IP address is resolved. Validate the address resolution across all DNS servers. From the UM server use ‘Ping’ and ‘Tracert’ to confirm the routing path and IP connectivity. To validate that the port is listening you can ‘Telnet’ to the port (5060/5061). New Unified Messaging server event ID for SIP OPTIONS failures The event ID for the SIP OPTIONS failure has changed between Exchange 2007 and Exchange 2010. Exchange 2010 logs event ID 1400 in the Application event log for SIP OPTIONS failures. The content of event ID 1400 is also different from the SIP OPTIONS failure event ID 1088 logged by Exchange 2007, which logged only one failure per event. Exchange 2010 lists multiple failures per event. The event ID1088 does not alert on the Exchange 2010 UM server. In Exchange 2007 the Application log event ID 1088 for SIP OPTIONS failure: Event Type: Warning Event Source: MSExchange Unified Messaging Event Category: UMService Event ID: 1088 Date: 4/15/2011 Time: 6:18:13 PM User: N/A Computer: Ex2K7UMServer Description: The IP gateway or IP-PBX "MyIPGateway1" did not respond to a SIP OPTIONS request from the Unified Messaging server. The error code that was returned is "0" and the error text is ":Unable to establish a connection.". Note: The error text will be different depending on the type of failure, you may also see ":This operation has timed out.". In Exchange 2010 the new Application log event ID 1400 for SIP OPTIONS failure, for example. Log Name: Application Source: MSExchange Unified Messaging Date: 4/15/2011 6:31:28 PM Event ID: 1400 Task Category: UMCore Level: Warning Keywords: Classic User: N/A Computer: Ex2K10UMServer.Contoso.com Description: The following UM IP gateways did not respond as expected to a SIP OPTIONS request. Transport = TLS, Address = MyIPGateway1.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection. Transport = TLS, Address = MyIPGateway2.contoso.com, Port = 5060, Response Code = 0, Message = Unable to establish a connection. Note: The error text may be different depending on the type of failure. You may also see: "This operation has timed out." “Unknown error (0x80131500)” “Unable to establish a connection.” Additionally, the actual port used is displayed - it may be different from 5060. For example, if you've configured mutual TLS, TCP port 5061 is used. Summary of settings to validate Confirm that a voicemail has been placed in the end user’s mailbox. Confirm the user’s mailbox and mailbox database are online and responding. Look for any MWI failure events on the mailbox server. Increase the UM MWI event logging level on the mailbox server to view ‘success’ events. Confirm the user is UM enabled (Get-Recipient) and note the mailbox policy and dial plan. If the user receives an SMS text notification confirm that ‘UMSMSNotificationOption’ is set to a Voicemail option, and also that the UMMailboxPolicy setting ‘AllowSMSNotification’ is set to ‘True’. Confirm that the UM Mailbox Policy is MWI enabled. Find the UM server and UM IP Gateway being used from the UM Dial Plan. Confirm that the UM IP Gateways is MWI enabled in Exchange. Check the health of the UM server. Look for SIP OPTIONS failures on the UM server. Increase the UM MWI event logging level on the UM server to view ‘success’ events. Examine network connectivity between the UM server and the UM IP Gateway. Confirm the UM server is able to ping the UM IP Gateway and telnet to the port in use. The commands Test-UMConnectivity and Test-ExchangeUMCallFlow may be useful in testing functionality between the UM server and the UM IP Gateway but don’t specifically test MWI notifications. These troubleshooting steps will help to eliminate any issues on the Exchange server side in passing MWI notifications to end users. With all MWI settings correctly configured, any Exchange side MWI failure should be able to be isolated by the errors in the Application event log. But this only validates the Exchange side of the MWI notifications, there could be an issue on the UM IP Gateway / SIP Peer side or how the SIP NOTIFY of the MWI notifications were handled between the UM server and the UM IP Gateway device. This article doesn’t go into the handling of the SIP NOTIFY between the UM server and a UM IP Gateway. For an in-depth description on the MWI SIP NOTIFY with the UM IP Gateway / SIP Peer, please see 'Understanding Message Waiting Indicator’. Useful links Understanding Message Waiting Indicator -An in-depth description of the MWI. Configure the TCP Listening Port on a UM IP Gateway -Settings to use TLS (Transport Layer Security) with gateways. Error and Event Reference for Unified Messaging Servers -UM events and their description text. Understanding Unified Messaging IP Gateways -Description of IP Gateways and objects. An IP gateway or IP PBX didn't respond to a SIP OPTIONS request from the Unified Messaging server -Description of the event ID 1400 for the System Center Operations Manager Exchange Server 2010 Management Pack. MSExchange Unified Messaging 1400 -Description of the event ID 1400. Jon ErnastExchange 2010 Diagnostics: The Unified Messaging Troubleshooting Tool
Requirements Supported Operating Systems Windows 7 Windows Vista Windows Server 2008 and Windows Server 2008 R2 Software Requirements Microsoft .NET Framework 3.5 SP1 Microsoft .NET Framework 3.5 Family Update for Windows Vista x64 and Windows Server 2008 x64 (if the tool will be run on a computer running Windows Vista or Windows Server 2008) Windows Management Framework Core package (Windows PowerShell 2.0 and WinRM 2.0) Unified Communications Managed API 2.0, Core Runtime (64-bit) Download: Unified Messaging Troubleshooting Tool The Unified Messaging Troubleshooting Tool is a diagnostics cmdlet which every administrator should run whenever someone desperately (or not) comes to them and says "Help! My voicemail isn't working!". The tool executes a set of tests and outputs the possible root causes for any detected issues and the possible solution for those. Simple, fast and efficient, just the kind of tool you need in your daily IT adventures. Since we released the tool a while back, I've been receiving requests to post about it here on EHLO. As more and more organizations are starting to move away from the typical enterprise deployment model to a completely online world in Office 365, I thought this would be the right time to attend such requests. So, have you been using the tool? If not, here's something to get you started! Configuring the Windows PowerShell default execution policy on Windows 7 If you are running the tool in Windows 7, by default it won't be given permission to execute Powershell scripts. This is due to the default execution policy granted by Windows PowerShell which is set to Restricted, so the moment you double click on the shortcut for the tool on your desktop, you get a nasty error message: Microsoft.Exchange.UM.TroubleshootingTool.ps1 cannot be loaded because the execution of scripts is disabled on this system. Please see "get-help about signing" for more details. To bypass this, execute the following steps on your box: Start a new Powershell window as Administrator(run as Administrator) Run the following command: Set-ExecutionPolicy RemoteSigned This will grant Windows Powershell permissions to execute all scripts and configuration files, as long as they're signed by a trusted publisher. Because the troubleshooting tool is a signed Powershell script, it'll be granted the permissions to execute. Running the tool You are now ready to run the tool. Double click on the UM Troubleshooting tool shortcut on your desktop and type Test-ExchangeUmCallFlow PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: The troubleshooting tool supports two operating modes: Gateway: Emulates a call, as if it was coming from a SIP Gateway. SIPClient: Emulates a call, as if it was coming from a Lync server. Say you're running the tool to verify Bob's TelEx extension (x12345). When prompted about the execution mode, you should go ahead and confidently type Gateway. PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: Gateway NextHop: The troubleshooting tool will now prompt you for the NextHop. This should be the IP address or FQDN that the tool must connect to. Your NextHop will vary, depending on whether you're running the tool to verify the UM configuration of a mailbox in Office365 or a mailbox hosted in your on-premises Exchange organization. If you're verifying a mailbox hosted in the cloud, you should enter the FQDN of the SBC device, which will in turn forward the call to one of our UM servers. If you're running the tool against an on-premises mailbox, you should enter the FQDN of your Unified Messaging server. PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: Gateway NextHop: Umserver.constoso.com Diversion: The last information required is the diversion header to be used. It can be as simple as just the extension number to be verified, or a (somewhat) complex History-Info header, as those might also be used by SIP devices interested in preserving the information on how a call originated. Here's an example of a very complex History-Info in case you'd like to try it out: History-Info:<sip:12345@contoso.com;user=phone?Reason=SIP%3Because%3D487%3Btext%3DTimeout>;index=1,<sip:7890@contoso.com;user=phone?Reason=SIP&m#62;;index=1.1 So go ahead and enter the last parameter required: PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: Gateway NextHop: Umserver.constoso.com Diversion: 12345 That's it! The tool will then execute a set of tests and output any issues detected. PS C:\>Test-ExchangeUMCallFlow Cmdlet Test-ExchangeUMCallFlow at command pipeline position 1 Supply values for the following parameters: Mode: Gateway NextHop: Umserver.constoso.com Diversion: 12345 The diagnostic test identified a problem. Task : Resolving "UmServer.contoso.com" to an IP address Status : Failed Reason : It is not possible to resolve "UmServer.constoso.com" from this machine. Details: No such host is known Solution : Confirm that the server name "UmServer.contoso.com" is correct and that it can be accessed from this computer. Traces for this diagnostic test can be found at 'C:\Users\Administrator\AppData\Roaming\Microsoft Exchange 2010 UM Troubleshooting Tool'. By the way, did you notice the last lines outputted by the tool? Here is what is says: Traces for this diagnostic test can be found at 'C:\Users\Administrator\AppData\Roaming\Microsoft Exchange 2010 UM Troubleshooting Tool' In addition to the information returned by the tool, a set of very, very important traces are automatically generated by the tool: UMTool_Collaboration: RTC stack traces UMTool_DiagnosticLog: Lists the tests executed by the tool and their results UMTool_S4: S4 stack traces UMTool_SIPMessageLogs: The full SIP traces for the test call executed The UM team would love to hear stories where the Unified Messaging Troubleshooting tool saved your day! We'd love as well to hear any other asks you might have. Let us know by posting your comments on this blog. Bernardo SanaUnderstanding Remote Mailbox Move and Unified Messaging
Remote mailbox move (a.k.a. cross-forest mailbox move) refers to the process of migrating an Exchange mailbox from one Active Directory forest to another. Exchange 2010 supports remote mailbox moves via the MoveRequest cmdlets. Here are some of the considerations for performing remote mailbox moves on mailboxes which are enabled for Unified Messaging (UM). This article assumes that readers are familiar with Unified Messaging and how remote mailbox move operates in general. So... why do you care? Prior to Exchange 2010 SP1, if you want to perform remote mailbox move on a UM-enabled mailbox, you need to do the following: Prior to the move, UM-disable the mailbox in the source forest Execute move request on the mailbox After the move completes, UM-enable the mailbox in the target forest In addition, you need to update the telephony configuration for the corresponding phone set so that all phone calls for the mailbox owner are correctly covered by the telephony system to the UM servers in the target forest. This process poses several pain points, most importantly: Admin hassle - The admin having to manually disable and re-enable the mailbox for UM every time a UM-enabled mailbox is moved. User hassle - Voice Mail stops working for the user whose mailbox is being moved for the entire duration of the move process since the mailbox is UM-disabled. This is problematic for users with large mailboxes where the move process can take a long time to complete. In Exchange 2010 SP1, we've extended the MoveRequest cmdlets to alleviate these pain points by removing the need for an admin to UM-disable/re-enable the mailbox and reduce voice mail downtime. How it works For this to work correctly, you need to "map" the UMMailboxPolicy objects in the source forest to the UMMailboxPolicy objects in the target forest. This is achieved by stamping the name of the UMMailboxPolicy object in the source forest on the SourceForestPolicyNames attribute on the UMMailboxPolicy object in the target forest. Here's an example to explain what I mean: Suppose you have some mailboxes which are UM-enabled in the source forest and are associated with UMMailboxPolicy object (Policy S). You would like these mailboxes to be UM-enabled and associated with UMMailboxPolicy object (Policy T) in the target forest after the move completes. Prior to executing the New-MoveRequest on these mailboxes, you need to stamp the name of Policy A on Policy B's SourceForestPolicyNames attribute by running the following Exchange cmdlet in the target forest: Set-UMMailboxPolicy -identity "Policy B" -SourceForestPolicyNames "Policy A" Once the mapping is created, you can start moving the mailboxes by executing the New-MoveRequest cmdlet without having to UM-disable the mailbox first. While the move is in progress, UM continues to operate for these mailboxes in the source forest since the mailboxes are still UM-enabled. As the move request completes for a particular mailbox, the following happens: In the target forest: Upon detecting that the mailbox is UM-enabled, the migration process obtains the name of the UMMailboxPolicy object which the mailbox is associated with in the source forest. It then looks for a corresponding UMMailboxPolicy object in the target forest whose SourceForestPolicyNames attribute contains this name. The migration process also figures out what UM extensions are currently assigned to the mailbox in the source forest. Using these extensions and the UMMailboxPolicy object found earlier, the migration then UM-enables the mailbox in the target forest. The migration process also copies over information about the user's UM PIN into the target forest, ensuring the user's existing UM PIN is preserved during migration. A UM welcome message is then sent to the user, showing the access telephone number for the UMDialPlan in the target forest. Access telephone number is what users dial on their phone to get to Outlook Voice Access. In the source forest: As part of move request, the Active Directory mailbox object is updated into a Mail-Enabled User (MEU) object. All UM configuration on the MEU object is automatically removed. Once the migration process completes, voice mail outage begins. This is because your telephony system is still sending calls to the UM servers in the source forest. Voice Mail outage continues until the telephony configuration for the corresponding phone set is updated to cover calls to the UM servers in the target forest. Further reducing voice mail downtime If you want to reduce the amount of downtime even further, this is what you can do: Make sure the name of the UMMailboxPolicy object in the source forest is correctly stamped on the SourceForestPolicyNames attribute of the UMMailboxPolicy object in the target forest. Execute New-MoveRequest with SuspendWhenReadyToComplete parameter set to $true. This ensures that the New-MoveRequest pauses right before finalization occurs. As you resume the move request by running Resume-MoveRequest, you also update your PBX configuration. As the mailbox move finalizes, the mailbox in the source forest is deleted and the mailbox in the target forest becomes functional. If you update your telephony configuration as the mailbox move finalizes, you can reduce the window of voice mail outage. Note that this method can be cumbersome since it requires precise coordination between your Exchange admin and your telephony admin. SourceForestPolicyNames Attribute The SourceForestPolicyNames attribute on the UMMailboxPolicy object is part of Exchange 2010 SP1 schema. It bears the following characteristics: Multi-valued - This means that you can have multiple UMMailboxPolicy objects in the source forest mapped to a single UMMailboxPolicy object in the target forest. Unique - No two UMMailboxPolicy objects in the same forest can have the same value stamped in their SourceForestPolicyNames attribute. This prevents you from stamping the name of a single UMMailboxPolicy object in the source forest on multiple UMMailboxPolicy objects in the target forest. This is needed to avoid any ambiguity when the migration process looks for a matching policy object in the target forest. By default, when you create a new UMMailboxPolicy object using Exchange 2010 SP1 cmdlets or admin console, its SourceForestPolicyNames attribute is automatically populated with its own name. An easy way to handle remote mailbox moves is to create UMMailboxPolicy objects in both source and target forests with the same name, thereby avoiding the need to manually configure the SourceForestPolicyNames attribute. Other considerations If the mailbox is UM-enabled in the source forest but you don't want the mailbox to be UM-enabled in the target forest, you should UM-disable the mailbox prior to the move. Conversely, if the mailbox isn't UM-enabled in the source forest but you want to UM-enable the mailbox in the target forest, you should UM-enable the mailbox in the target forest after the move. Doing so helps to reduce complexity in managing the move request since you don't have to take UM configuration into account. When you firs t execute New-MoveRequest, the migration process will perform a series of UM-specific validation up front if mailbox is UM-enabled, including looking for a matching UMMailboxPolicy object in the target forest as well as validating that the UM extensions assigned to the mailbox are unique in the target forest. If the validation fails, New-MoveRequest will return an error immediately. Under rare circumstances, the UM-specific validation may succeed up front when New-MoveRequest cmdlet is executed but the migration process fails to UM-enable the mailbox as the mailbox move finalizes. When this occurs, the mailbox move will complete with warning and the mailbox will not be UM-enabled in the target forest. You will need to manually UM-enable the mailbox in the target forest. The corresponding warning message, which can be obtained through Get-MoveRequestStatistics cmdlet, looks like this: Warning: User 'John Doe' can't be enabled for Unified Messaging in the target forest for the following reason: Extension 12345 is already assigned to another user on dialplan DP1 or an equivalent dial plan. Please fix the problem and enable the user for Unified Messaging manually. An example of how this can happen is that the UM extension assigned to the mailbox was available in the target forest when the UM-specific validation occurred but is no longer so right when the move finalizes. A UM-enabled mailbox may be assigned extensions from multiple UMDialPlan objects in the source forest. Only extensions from the primary UMDialPlan will be used to UM-enable the mailbox in the target forest. Extensions from secondary UMDialPlan(s) will not be preserved. Chun Yong ChuaCall Answering Rules (Part 2): Call Answering Conditions
In Exchange 2010, users can easily create call answering rules to have a call answered based on the specified conditions. Users can create rules to answer calls from specified callers or Contacts in a certain way, handle calls differently based on their availability (Free/Busy status) or time of day. The call answering rule will only be triggered when all the associated conditions are met. In this post, I will cover: The different classes of conditions supported in UM 2010 How does UM go about evaluating a given set of call answering rules This article assumes that you have read my previous post Call Answering Rules (Part I) - Creating your first Call Answering Rule. The Call Answering Rule form The diagram below shows you the Call Answering Rule form. In particular: Condition(s) which have already been added to the rule is located on the left (in green). You can remove them by clicking on the symbol beside the condition. Condition(s) which you can further add to this rule is located on the right (in red). To start adding new condition, simplify click on the condition desired. Figure 1: The call answering rule form Different classes of conditions There are 4 different classes of conditions supported by UM 2010, namely: Caller identity Time-of-the-day Calendar free/busy status When my automated email reply is turned on Caller Identity Users can use different call answering rules for different callers. For example, if you receive a call from an important customer's phone number, you can answer it differently. To answer calls based on caller identity, users can add a caller-ID condition to a call answering rule such that the rule will only be triggered if the calling party matches one of those specified. To configure this condition: Click on "If the caller is." condition to bring up the following UI control. Figure 2: Call answering rule based on caller Specify 1 or more phone numbers, pick Contacts from the GAL or your Contacts folder, or specify the entire Contacts folder. Click on "Apply" to close the UI control. Time of Day Users can add a time-of-the-day condition to a call answering rule such that the rule will only be triggered if the time of the call matches the time period specified. For example, during working hours, calls can be answered using the "Follow-Me" action, or routed straight to voicemail during after-hours. To configure this condition: Click on If it is during this period. condition to bring up the following UI control: Figure 3: Call answering rule based on time of day Specify a period, either working hours, non-working hours or custom hours. Click on Apply to close the UI control. Calendar Free/Busy status Users can specify a condition for a call answering rule based on their availability (calendar Free/Busy status). To do so: Click on If my schedule shows that my status is. condition to bring up the following UI control: Figure 4: Call answering rule based on Free/Busy Status Pick one or more Free/Busy status which you want this rule to fire. In the example provided, I have specified that the call answering rule to be triggered if my calendar shows that I am either Busy or Away. Click on Apply to close the UI control. When my automated email reply is turned on Users can specify that a call answering rule only be fired when their automatic email reply is turned on. To do so, simply click on "If Automatic Replies are turned on" condition. Call Answering Rules and conditions It is possible to associate the same call answering rule with multiple conditions. All the conditions must be met in order for the call answering rule to be trigger. You can also create call answering rules without specifying any condition. When such a rule is encountered, it will be triggered as though all its conditions are met. Multiple Call Answering Rules You can create one or more call answering rules. You can also associate each call answering rule with one or more conditions. The diagram below illustrates an example with 3 call answering rules configured. You can enable/disable or reorder the rules. Figure 5: Multiple call answering rules As illustrated in the flow diagram below, for each call answering call received: No call answering rules configured: If you do not have any call answering rules configured, UM will offer the caller to leave a voice message. One or more call answering rules configured: If there are one or more call answering rules configured, UM will evaluate these rules in a top-down fashion. The first rule, whose conditions are met, will be fired. After evaluating all the rules, if UM is unable to find a rule whose conditions are met, UM will offer the caller to leave a voice message. Figure 6: How UM call answering rules are evaluated Call answering rules are an Exchange 2010 feature, and only available to UM-enabled users with a mailbox on an Exchange 2010 Mailbox server. -Chun Yong Chua
