This article covers the configuration steps for introducing voice mail support into a Skype for Business (SfB) Server 2015 environment by integrating with Exchange Server 2013 Unified Messaging (UM). Note that this series of Exchange integration articles leverages Exchange Server 2013 and will continue to do so for continuities’ sake. Microsoft has recently released to the public the installation package for Exchange Server 2016 for use in on-premises deployments. These articles also apply when using Exchange Server 2016, with one exception related to Instant Messaging integration which will be the next topic addressed in a future article.
The guidance provided here is a more detailed look at what is partially covered in the official TechNet documentation. The following configuration covers generally the same approach used to integrate previous version of Lync Server and Exchange Server which was outlined in this older article. Unfortunately the official documentation is partially incomplete and is also split across the separate product guides for SfB and Exchange Server, making it difficult to understand what is needed for a successful integration. This article will tie all steps into a single set of instructions which can be completed linearly.
One caveat to be aware of is the recommendation to configure UM integration before enabling Instant Messaging (IM) integration with Outlook Web Access. Configuring UM first will enable automatic discovery of the Exchange environment in Skype for Business using the configured SIP domain namespace. Establishing this first will mean that when the IM integration is tackled there will be no need to defined the Exchange Server as a third-party Trusted Application in the SfB topology. If these are configured in the opposite order, meaning that the Instant Messaging integration is performed first, then the setup of Unified Messaging can break the IM integration due to duplicate, conflicting entries for the Exchange Server in SfB. Thus is is recommended to start with UM integration and follow these articles in the order they were posted.
The sections in this article are outlined in the following configuration steps. The steps in red are part of the Exchange Server configuration and the steps in blue are performed on the Skype for Business side.
Confirm Prerequisites
Assumptions made for the environment used with this article are that Exchange Server 2013 has been deployed with a relatively recent service pack or cumulative update applied. The version used in this guide is Exchange Server 2013 CU8 (15.00.1076.009).
Partner Application
The prerequisites steps included in this previous article must be completed first to insure that the Partner Application relationship has already been established between Skype for Business and Exchange. Other SfB features provided by Exchange like High Resolution Photos or the Unified Contact Store can be enabled in any order, only after the Partner Application relationship is established.
Exchange Certificate
A long standing best practice surrounding the Exchange Server Certificate has to do with how Lync Server parsed the SSL certificate presented to it by the Exchange Server during establishment of TLS communications. The Lync Server would ignore the certificate’s Common Name (CN) and look at only the Subject Alternative Name (SAN). With further changes coming on how third parties issue SSL certificates it is becoming more common to focus on the SAN field as the CN field will start to become optional, and eventually even defunct. That being said the same best practice to making sure to always duplicate the CN value in the SAN still holds true. Using the Exchange Server certificate wizard to create requests will allow this type of configuration. At this point it is unknown if this limitation has been addressed in Skype for Business Server 2015 but using a properly formatted certificate makes this a moot point.
- Using the Exchange Management Shell validate that the existing certificate will be sufficient for use with Skype for Business with the following Get-ExchangeCertificate cmdlet.
Get-ExchangeCertificate | fl
As highlighted above the Certificate Domains field lists all of the Subject Alternative Names on this certificate which includes the Exchange Server’s FQDN which is critical for UM integration to function. In this example the Subject field shows that the certificate’s Common Name is set to mail.jdskpye.net which is also duplicated in the SAN field. Regardless of what the CN is set to make sure that value is duplicated in the SAN (as per general best practices) and that the server FQDN is included in the SAN field.
This configuration is the most common and allows a single SSL certificate to be used for all roles on the Exchange Server. In more complex environments with separate Exchange UM servers or other configuration it is possible, but not necessary, to use a separate dedicated certificate on the UM service.
Also make note of the Thumbprint value for the desired certificate as it will be used during the configuration in the next section.
Configure UM Dial Plan
The steps in this section are all performed on the Exchange Server using either the Exchange Management Shell or Management Console.
Create New UM Dial Plan
- Using the Exchange Management Shell create a new UM dial plan with the following New-UMDialPlan cmdlet and the desired plan Name (e.g. Chicago).
New-UMDialPlan -Name "Chicago" -VoIPSecurity "Secured" -NumberOfDigitsInExtension 4 -URIType "SipName" -CountryOrRegionCode 1
In this deployment the VoIP Security option Secured is used so that both SIP signaling traffic and RTP media traffic will be transmitted between SfB and Exchange using an encrypted TLS communications. Alternatively opting to use the SIP Secured setting would only encrypt the signaling traffic while all media traffic would be transmitted unencrypted.
Additionally a value of 4 is selected for the number of digits in extension numbers on the pattern 312-555-xxxx where the last four digits are treated as the user’s extension.
- Using the Exchange Management Shell run the following cmdlet to set the following recommended parameters.
Set-UMDialPlan "Chicago" -ConfiguredInCountryOrRegionGroups "Anywhere,*,*,*" -AllowedInCountryOrRegionGroups "Anywhere"
- Assign the the UM server to the new UM dial plan and configure support for both TCP and TLS connections with the following cmdlet. The Identity parameter is the Fully Qualified Domain Name (FQDN) of the Exchange Server (e.g. exch.jdskype.net).
Configure UM Services
Set-UmService -Identity "exch.jdskype.net" -DialPlans "Chicago" -UMStartupMode "Dual"
Now that TLS is enabled for the UM service the Exchange Server certificate needs to be assigned to the service to support TLS communications for signaling and media.
- Enter the following cmdlet using the Thumbprint value of the same certificate that was queried in the earlier prerequisites steps to insure that the proper certificate is assigned to the UM service.
Enable-ExchangeCertificate -Server "exch.jdskype.net" -Thumbprint "372EDC073A1C21C91FE2C6045FD70B26AD5E239C" -Services "UM"
- To commit these changes and enable TLS communications on the UM service it needs to be restarted, which can be performed quickly from PowerShell using the following cmdlet.
Restart-Service MSExchangeUM
- Next perform the same configuration as above on the UM Call Router service with the following cmdlet.
Set-UMCallRouterSettings -Server "exch.jdskype.net" -UMStartupMode "Dual" -DialPlans "Chicago"
- The UM Call Router service also need to be assigned to the same certificate as the UM service.
Enable-ExchangeCertificate -Server "exch.jdskype.net" -Thumbprint "372EDC073A1C21C91FE2C6045FD70B26AD5E239C" -Services "UMCallRouter"
- Just like the UM service the UM Call Router service needs to be restarted to enable the new configuration.
Restart-Service MSExchangeUMCR
Customize UM Dial Plan
When the new UM dial plan was created the Exchange Server will have automatically created a default UM Mailbox Policy. This object will be named with the label ‘Default Policy” appended to the dial plan’s name (e.g. Chicago Default Policy).
The TechNet documentation seems to omit this fact and instructs the creation of another UM mailbox policy. A simpler approach is to just modify the default object using the following cmdlet.
- To configure the recommended AllowedInCountryOrRegionGroups parameter use the following cmdlet.
Get-UMMailboxPolicy | Set-UMMailboxPolicy -AllowedInCountryOrRegionGroups "Anywhere" -MinPINLength "4" -AllowCommonPatterns $true
As only a single policy exists then instead of querying for and entering the name of the default mailbox policy use the Get-UMMailboxPolicy cmdlet to automatically pass the results to the cmdlet as shown above. Additionally some optional parameters were configured to allow for a four digit PIN to be defined instead of the default 6 digit length. While not recommended for production environments this can be a welcome time saver in lab or test environments.
Define Attendants
The next step to be performed on the Exchange Server is to define and configure the Auto Attendant and Outlook Voice Access (formerly referred to as ’Subscriber Access’) numbers.
- Using the Exchange Admin Center navigate to the Unified Messaging > UM Dial Plans section and then open the dial plan that was created earlier (e.g. Chicago).
- Click the Configure button to edit the dial plan and then select the Outlook Voice Access section.
- Enter the desired phone number to be assigned to the Outlook Voice Access attendant in the proper +E.164 format (e.g. +13125551001) and then add it to the configuration using the ‘+’ button.
- Click Save to return to the main dial plan window and then scroll down to the UM Auto Attendants section.
- Click the ‘+’ button to create a new Auto Attendant and then enter a unique Name (e.g. ExchangeAA), enable the auto attendant, and then enter another unique phone number (e.g. +13125551000).
Traditionally Exchange does not do well with spaces in auto attendant names and thus it is still recommended to follow that guidance.
- Click Save to and then Close to commit these changes to the server.
Enable Users
To validate that the UM configuration is functional then at least one user account must be enabled for Unified Messaging. This process can be completed from either the management console or shell.
- To enable the first account launch the Exchange Admin Center which should default to the Recipients > Mailboxes section.
- Highlight the desired user account and then select Enable under the Unified Messaging section in the right-hand window pane.
- In the Enable UM Mailbox window browse for and select the default mailbox policy (e.g. Chicago Default Policy) and then advance to the next window.
- Define a four digit Extension Number if one is not already populated and then, if desired, enter a custom PIN and unselect the option to force the user to change this PIN after they sign in.
In this example the users extension was pre-populated due to the existence of a defined telephone number in the user’s Active Directory object. Because the dial plan policy was created to use 4-digit extensions then Exchange will automatically take the last 4 digits of the user’s phone number (e.g. 1100).
- Complete the wizard to save the changes and enable this account for Unified Messaging.
Alternatively the same steps can be performed using Exchange PowerShell cmdlets, so a second account configuration using this process is also covered as an example.
- Using the Exchange Management Shell enter the following cmdlet to perform roughly the same exact configuration on another existing Exchange user.
Enable-UMMailbox -Extensions 1101 -SIPResourceIdentifier "steve@jdskype.net" -Identity "JDSKYPE\steve" -UMMailboxPolicy "Chicago Default Policy"
Make sure to enter a unique extension or to omit that parameter if the account’s phone number is already populated with the desired information. The PIN was not manually set on this account which means Exchange will have automatically assigned a random PIN and then sent an email to the user’s mailbox with that information.
Configure UM IP Gateway
This step is handled by a script which creates the UM IP Gateway and IP Hunt Group as well as grants permissions to Skype for Business Server to read specific UM-related objects in Active Directory.
Make sure to allow for any outstanding AD replication to complete before running this script so that the newly created UM dial plan and any other changes are read by the script in their updated state. If run too soon then sometimes the Dial Plans listed in the last line of the script output will display as “not found” even though the configuration is correct up to that point. If that happens it is safe to simply re-run the script, even multiple times if needed, as it will identify any previously successful configuration and thus report that no new changes were applied in those cases.
- Using the Exchange Management Shell execute the ExchUCUtil.ps1 script located in the Exchange Server’s Scripts directory, as shown in the path below.
cd "C:\Program Files\Microsoft\Exchange Server\V15\Scripts"
C:\Program Files\Microsoft\Exchange Server\V15\Scripts>.\ExchUCUtil.ps1
Note that in this example the Skype for Business Front End server shown at the bottom of the script output displays “{(not found)}” for the DialPlans field. The value should be displayed as the UM Dial Plan name (e.g. Chicago). As mentioned above this can usually be resolved by going back and re-executing the script after a few minutes have passed.
- If this issue appears then repeat the previous step until the results successfully report the expected dial plan as shown below.
To validate the creation of the UM IP Gateway open the Exchange Management Console and then navigate to the Unified Messaging > UM IP Gateways section. Refresh the page if the new gateway does not appear at first.
Create Attendant Contacts
With the configuration now complete on the Exchange Server the remainder of the steps in this article are performed on the Skype for Business Front End server.
The OcsUmUtil.exe utility is still used to create the Active Directory contact objects for Skype for Business Server to resolve and locate the Exchange Outlook Voice Access and Auto Attendant services.
In older versions of Exchange Server it was required to create an Enterprise Voice Dial Plan in OCS/Lync that matched the exact FQDN of the Exchange UM Dial Plan. Since the release of Exchange Server 2010 SP1 this is no longer required as indicated by the informational text at the bottom of the utility. The UM Dial Plan will be automatically discovered and thus no additional Enterprise Voice configuration is required on the SfB Server to enable UM integration.
- Launch the OcsUmUtil.exe program located in the Skype for Business Server’s Support directory, as shown in the path below.
C:\Program Files\Common Files\Skype for Business Server 2015\Support
- Click Load Data and the Active Directory forest name should appear in the Exchange UM Dial Plan Forest field.
- Click Add to create the first contact for Outlook Voice Access, which is still referred to as the Subscriber Access number in this tool.
- Select the desired AD Organizational Unit to save the new contact object and then enter a unique Name for the contact (e.g. ChicagoSA).
While the remainder of the fields can be left with the default entries it is a common practice to change the SIP Address to a less confusing SIP URI. In this examples the default value (e.g. Chicago.jdskype.net@jdskype.net) has been changed to a simpler string (e.g. ChicagoSA@jdskype.net).
- Click OK to save the configuration for the Subscriber Access contact.
- Click Add to create the second contact for the Auto Attendant.
- Change the Contact Type to Auto-Attendant and then enter a unique Name for the contact (e.g. ChicagoAA). The same Organizational Unit value as defined for the previous contact should already be populated.
Just as before either retain the default SIP address or edit it to use a customized address as shown in this example (e.g. ChicagoAA@jdskpye.net).
- Click OK to save the configuration for the Auto Attendant contact.
- Close the Exchange UM Integration Utility and then open Active Directory Users and Computers to browse to the target OU and validate that the new contacts were successfully created.
Verify Integration
Now that the integration on both server platforms is complete the final step is to test UM connectivity between Exchange and Skype for Business.
- Sign into a Skype for Business client with one of the UM-enabled user accounts (e.g. jeff@jdskype.net) then search for the SIP URI of the Auto Attendant and place a Skype Call to the contact.
At this point one of two things will occur: the call will work or it will not. If the integrated voice response is “Thank you for calling Microsoft Exchange auto attendant” then the integration was successful. If not then the following common issues could be the root cause.
Call Failure
If the call fails without any response from the Exchange UM Server then one of the most common reasons, other than a simple configuration mistake, could be that the Exchange UM IP Gateway configuration script did not complete as mentioned earlier in this article.
- Check the Lync Server event log on the Skype for Business server to see if the following error message was reported at the same time as the attempted call.
Log Name: Lync Server
Source: LS Exchange Unified Messaging Routing
Event ID: 44008
Task Category: (1040)
Level: Error
Keywords: Classic
Computer: FE.jdskype.netDescription:
Dial Plan UnknownDialplan [Chicago.jdskype.net] is not recognized by routing application
Cause: Dial plan does not exist, or Skype for Business Server 2015 does not have permission to read the relevant Active Directory objects.
Resolution:
If the dialplan is valid, then run exchucutil.ps1 in appropriate Exchange forest to give permission to Skype for Business Server 2015. If the dialplan is not valid, then clean up proxyAddresses attribute for the affected users.
If this message exists then this is an indication that the ExchUmUtil.ps1 script that was run earlier did not configure the UM IP Gateway correctly. As pointed out earlier the script may have failed to associate the UM Dial Plan to the gateway, thus causing this error on the Skype for Business server. Return to that step to re-run the Exchange script and validate that the dial plan is displayed correctly, which should clear this error and then allow for calls to reach the UM attendant services.
Unexpected Response
If the call successfully connects to the attendant but an unexpected response is heard then this could point to a different issue. If the interactive voice response was “Please call back later. Goodbye.” then this typically occurs when the UM configuration is brand new and the server has not yet had a chance to generate the grammar speech files. As documented in this blog article the pending generation process can be expedited by restarting the Exchange Mailbox Assistants service.
- Using PowerShell enter the following cmdlet to quickly stop and restart the Mailbox Assistant service.
Restart-Service MSExchangeMailboxAssistants
- View the Application Event Log on the Exchange server to verify that the following entry has been logged after the service has been running for a few minutes.
Log Name: Application
Source: MSExchange Unified Messaging
Event ID: 1613
Task Category: UMCore
Level: Information
Keywords: Classic
Computer: EXCH.jdskype.netDescription:
Speech grammar generation started for "Enterprise". Run ID: "7a97b157-b74f-4a21-b667-faf56e85f047", Recipient type: "User"
At this point a call to the Auto Attendant should result in the proper welcome message.
This concludes the setup of Exchange Unified Messaging with Skype for Business Server 2015. If following along with this entire series of Exchange Server integration articles for Skype for Business 2015 then at this point the Partner Application has been established and leveraged to enable High Resolution Photos and now Unified Messaging.
Future articles will address Instant Messaging integration with Outlook Web Access as well as other features like IM archiving and enabling the Unified Contact Store.
Hi Jeff,
Thanks for the article. I am trying to configure this but have hit a snag. My CAS and Mailbox roles are on separate boxes, I can see when SfB tries to connect to the UM service (using Wireshark) it is trying to connect to the Mailbox server rather than the CAS server, the mailbox server does not appear to be listening on port 5061 (which seems to be by design).
Do you know why SfB would be trying the MB server rather than the CAS? Something it found from the autodiscover maybe?
Thanks,
Stephen
Hi Jeff, thanks for another great blog post.
I followed your article to the t but still running in to issues. When a incoming call is transferred to UM for voice mail I get “busy” signal.
On the lync front end I see the following. I assure you, we have a server assigned to the dialplan. Error isn’t much help.
Attempts to route to servers in an Exchange UM Dialplan failed
No server in the dialplan [CGYUMDP.pmclp.local] accepted the call with id [211685c7-d200-482d-ae77-a34adbab6189].
Cause: Dialplan is not configured properly.
Resolution:
Check the configuration of the dialplan on Exchange UM Servers.
On the Exchange UM there is nothing in the event logs.
Certificate assigned to exchange UM service and um call router has CalVS1233.contoso.local as the common name as well in the subject alternative name.
on the lync side we specified port 5067 for tls and 5060 for tcp as listening ports. Because of this I did change change the UM Call Router Settings for TLS listening port to 5067 to match Lync.
From s4b logging I see the following “The peer actively refused the connection attempt” peer being the Exchange server. Also I see the frontend is trying to send to exchange over port 5061. Running netstat I see nothing is listening on 5061 on our exchange server.
Any suggestions or advice on what the problem might be would be greatly appreciated. Thanks Jeff.
KDS
Resolved.
Under UM Server settings you can configure the port for UM Call Router Settings for TLS Listening port. The pop up in EAC when doing the hover over says “Enter the TLS listening port configured on the VoIP gateway, IP PBX, or Lync server.” Our TLS listening port is set to 5067 so naturally one would think that this must need to change to 5067. However, if you do change this it changes the what port the UM Call routing service listens on, I don’t think it has anything to do with what TLS listening port lync /S4B is set to. Confusing and misleading.
Once I changed the port back to 5061 and restarted um services voice mail started working.
Great article. Have two questions though, We have Multiple Exchange servers, all multirole, load balanced. Do you have to assign one of them as the UM Call router by FQDN or can you assign a common load balanced name for it?
Second. We already have UM working with our Avaya Aura system and are migrating to Skype for Business. Can you use the same OVA number and Autoattendant with multiple Dial Plans? We have one for Avaya, unsecured and will obviously need a second for Secured. Do I need to identify another number for OVA for this dial plan? Another AA?
Are calls able to route from Exchange Auto Attendant back into the Skype enviromment? i.e. go from PSTN -> Skype -> Exchange Auto Attendant, where a user types in an extension they want to dial to talk to someone. I’m trying to get it working but am not having much luck, and fundamentally i’m not convinced it’ll work.
Yes that should still function in a SfB Server environment.
Hi micheal,
Did this scenario work out for you?
Thank you for this amazing article especially the “Call Failure” part
Jeff,
This comment isn’t entirely relevant to this post, but it’s along the same vein. I’m still running Lync 2013 and Exchange 2013. My boss wants to go to Exchange 2016 (we don’t have any plans to change Lync to Skype for Business 2015 for now). I’ve been able to find a couple of people asking if Exchange 2016 will work with Lync 2010/2013, but haven’t found any answers.
Do you know if Lync 2013 and Exchange 2016 will play together nicely? Perhaps more importantly… do you think MS would support this environment, since as of writing this comment the various TechNet articles discussing compatibility only mention Exchange 2013?
Hi Jeff,
This article was excellent as per your usual. I just wanted to offer an additional scenario.
We recently upgraded to Skype for business 2015 and Exchange 2016. Doing the exchange part broke our UM auto attendant due to certificate issues. Our exchange server has a public certificate based on our external domain (ex: mail. contoso.com) but Lync/Skype4B only wants to address your exchange server by its internal domain name which for us is based on a “.local” root so we couldnt use that same certificate for the UM services.
What we did:
If the internal domain is something that cannot be registered with public certificate authorities such as a “ex1.contoso.local” the fix is to create a separate certificate request in exchange just for your exchange internal AD name “ex1.contoso.local” (I just used the exchange admin console, dont select Self signed and delete all the other host domain names in that request) and submit it to your Windows Cert Server (Web Server template) then download it from the certsrv and complete the install in the exchange server.
Then use that certificate for Jeff’s instructions on assigning the 2 UM services on the Exchange Server.
(I suppose if the Lync server isnt in your internal domain then additionally you would want to install the windows root certificate on the Lync server but that isnt necessary if both servers belong to the same internal .local domain. For Edge and RPX servers I also imported the window root chain certificate but thats for trusting the Lync server I believe.)
Because Microsoft no longer recommends using internal root domains like .local, due to the issues of working with public certificate authorities, it is difficult to find tutorials that deal with our scenario even though there must be 100 of thousands of domains based on .local (Small Business Server was the biggest culprit). Unfortunately migrating a domain that was originally built using “.local” to a public domain one can be daunting in networks with a lot of servers.
Anyhow Jeff feel free to correct me on any of my statements, I know you already get all of this, I am just hoping this note would help others in my scenario who want to see that example.
[…] Skype for Business and Exchange UM Integration (Jeff Schertz’s Blog) […]
Hi Jeff Schertz!
We’re implementing SFB 2015 in our company, but users that have the same email address have their contacts merged by the client when they shouldn’t have.
We have two kinds of users: employees and outsourced collaborators. Due to legal reasons, the outsourced collaborators cannot have an individual email address on our Exchange server, so people who work in a same sector get to share a common mailbox. Say John is an employee at dev, so his default email address is john@example.com. Jack and Moe work alongside John, but they’re outsourced, so they share the mailbox devs@dev.example.com (yes, they get a subdomain, but that shouldn’t matter here).
John, Jack and Moe all got registered on **** with their UPN’s, which are created from their corporate ID’s. The ID’s have no relation with email addresses, being numerical. When they were registered, their SIP addresses were also generated from their UPN’s. So, they all can log onto **** with their UPN’s, like 1101@example.com, 1102@example.com, and 1103@example.com.
The problem arises when we search for them on the **** client. John shows up just fine. However, when we search for Jack, we get Moe. The client thinks they’re the same contact because they have the same email. It seems to me the WindowsEmailAddress AD attribute gets copied to the mail attribute on the **** address book. (Please note I’m no AD expert.)
Deleting contacts from Outlook or Exchange is not an option for us. Neither is changing the way the email addresses are linked to outsourced collaborators, due to the legal reasons mentioned above.
What we tried so far:
Tuned the Global client policy server-side: AddressBookAvailability changed to WebSearchOnly;DisableEmailComparisonCheck changed to True
Fooled around with ABSConfig:
Set proxyAddresses attribute to ProxyAddresses- Tel Only;
Tried to make the Address Book ignore mail addresses, setting mail to blank; we had no success with that, because running ABServer against the raw address book files displays the mail field on all users that have an email address, whether they’re employees or outsourced
I’ve seen solutions to a similar problem, but the thing here is we’re not supposed to touch Exchange or Outlook. Is there a way to stop the clients from merging users based on their emails?
Thanks Jeff. Can a similar integration be done if UM is on Exchange 2010.
regards
Jayesh
Yes UM is supported in Exchange 2010. THe newer non-UM intregration features that came with Exchange 2013 are obviously not included though.
Jeff,
Can you give some insight on S4B Online and Exchange UM on-prem deployments? Is this possible and what needs to be done?
We are migrating to S4B and Exchange Online very soon, and will have a variety of hybrid configs, and want to v-mail to be accessible for users whether on Exchange online or on-prem, while either on S4B online or Lync 2013 on-prem.
Cheers!
Great article, I am working on a migration from Exchange 2010 UM with Lync 2013 on-prem to O365 UM now and this gave some good insights. The thing that I am having trouble finding is port-requirements when introducing O365 – Exchange Online UM. We have an internal SBC and Lync environment that should connect to O365 (and back), but finding the exact requirements proves hard.
So far I have SIP (5060 to 5068) and SRTP (5004), but I cannot find anything else. Any tips there? Thanks!
Hello Jeff,
We have Exchange 2013 UM integrated with SFB 2015, and everything is working great, except when I’m doing maintenance on the Exchange 2013 servers.
I use the steps outlined in many blogs online, where when all said an done all the components are inactive, including the UMCallRouter. There are no mailbox databases active on this server, however I still get regular errors w/ the SFB boxes trying to route UM calls to the downed server
****
An attempt to route to an Exchange UM server failed.
The attempt failed with response code 504: DC1MSG003.PROMEGA.COM.
Request Target: [DP-MADISON@DC1MSG003.PROMEGA.COM], Call Id: [05b8940d-3767-4e64-85dd-7f2c5c10b1e7].
Failure occurrences: 1, since 2/8/2017 8:02:41 PM.
Cause: An attempt to route to an Exchange UM server failed because the UM server was unable to process the request or did not respond within the allotted time.
Resolution:
Check this server is correctly configured to point to the appropriate Exchange UM server. Also check whether the Exchange UM server is up and whether it in turn is also properly configured.
Please see the ‘Product Knowledge’ and the ‘Alert Context’ tab on Alert Properties view for more information.
****
thoughts?
Jason, I don’t have any guesses here as to what may be causing this.
ok Jeff, thanks. I’m going to open a case w/ Microsoft, will report back my findings. Somehow, I think Exchange needs to tell SFB it’s not currently available for UM, the specific server, I’m thinking maybe there’s a step missing when putting server into maintenance mode
Hi Jeff,
Great article as always.
We in the midst of migration from On-prem Exch to O365 and have hit an issue where i cannot delete a previously created UM policy. Error message says “There are UM users who are associated by their UM mailbox policy with the dial plan.” but all the users have been migrated to the new UM Policy.
Any ideas what is the issue and how to proceed??
Many thanks
You may have a system mailbox linked to that policy which could prevent removal. You should be able to check with this cmdlet: Get-Mailbox -Arbitration | fl UserPrincipalName, UMEnabled
From a skype client if I don’t use the Attendant Contacts objects to call the outlook voice access number the call just fails. IE, I am manually typing in the E.164 number or the extension then calling. Is this the expected behavior?
Thanks
Sean
Hey Jeff,
First time\long time 🙂
It’s supposedly possible to utilize Exchange 2010 for UM with a S4B Online\Cloud PBX implementation, but I can find 0 documentation on how to do it. All the OAuth docs are for Exchange 2013 and above. Any guidance?
Hi,
Great post Jeff, and Thank you it helps me a lot. Our Exchange 2016 CU4 with UCMA 5.0 UM integration with Skype For Business 2015 wont work. The only difference I can sse with your instructions is I cannot set an FQDN to our UM Service. The identity of our UM Service is automatically generated and is set with the name of the computer (MyServer) not with the server fqdn (MyServer.Mydomain.com).
Desperately, I am installing an Exchange 2016 CU 5 with UCMA 4.0 and at any moment in the installation you can choose the identity of the UMService. However, the identity is Myserver (not an FQDN). Do you know where I am missing the point?
Regards,
Nicolas
Hi Jeff!
Thanks for the great article.
We installed Exchange 2016 in the past days and are working on the Skype/Exchange integration.
At the very beginning you say that UM Integration should be implented before OWA instant messaging as the UM setup might break OWA IM if already enabled.
The thing is that we already activated IM for OWA and some other things like the unified contact store before implementing UM.
Is there any best practise on who to enable Exchange UM nevertheless? Any advice?
Best wishes
Birk
You may have to go back and fix the webconfig file as in the past changes to that file could be overwritten by other Exchange configuration or upgrade (e.g. Cumulative Update) processes. I have not looked at this in some time so I suggest checking online for updated guidance.
Thanks for the article. I am struggling to create a power-shell script to tweak “Hours of Operation” on an existing Auto Attendant for skype online. Also need a script to insert a holiday greeting and route the call to already configured settings for after hours menu. Apologize if this is not the right forum to request this.
Thanks,
Sunil
Nice explanation about Skype integration with Exchange server. Keep the good work up.
Regarding certificates. I’m migrating from Exch 2010 to 2016. We had two UM servers in the dialplan for S4B in 2010 and now have 4 UM servers in 2016. Does each of the 4 new servers need to be in the SAN of the certs?
At the moment, only one of the 4 2016 UM servers accept calls but I dont see any cert errors being logged. Even when disabling services on that one 2016 UM server, the other servers do not accept the calls. OCS logging shows each of 2016 UM servers responding with a 302 redirect back to the working 2016 UM server.
Any thoughts on what can cause this behavior?
[…] you need a brush up on Exchange UM, Jeff Schertz has a great article over here on […]
Hi Jeff, great article, I ran into an issue, everything works but for only 5 minutes, I mean, When someone uses the auto attendant to contact someone in the directory they get transferred fine, but the call always get dropped after 5 minutes, any ideas if there’s a secret timer somewhere ?