UM SCOM alert in Exchange 2013
For these types of SCOM Alert, the very first action we have to take is launching Event viewer or Powershell. Here I am using Powershell to dig deep into the event logs. If you know which event log provider is responsible for logging UM events, then it’s very easy to use Powershell to get all UM related events.
Hint: ‘MSExchange Unified Messaging’
I am using Get-WinEvent cmdlet instead of its predecessor Get-EventLog (for easy filtering).
The above cmdlet retrieves the most recent 30 events belonging to MSExchange Unified Messaging services.
So the next step is to search for twin sister events 1692, 1438. If twin sisters are there, Game Over!
Just try to get more details about Event ID 1692 & 1438. Event 1692 is very calm, she won’t give you much detail, but 1438 is chatterbox, even she will tell you what exactly needs to do to fix this alert.
Normally there are some limitations that holds you back when you are examining nuts and bolts on events in Powershell like you can’t read full message given by events, messages generated by UM events are bit lengthy when compared to other Events, so we can use formatting options like Out-String along with ‘Width’ parameter.
“The Microsoft Exchange Unified Messaging service on the Mailbox server has been configured to automatically use the Lync Server A/V Edge resources associated with ‘SFBEdgePool.domain.com:5061'. Inbound and outbound calls involving remote users (located outside the enterprise) might be failing using the current Lync Server A/V Edge resources. To correct the issue, set the SIPAccessService property using the Set-UMService cmdlet. The Microsoft Exchange Unified Messaging service will start using the Lync Server A/V Edge resources corresponding to the new value.”
So it’s clear that something needs to be tweaked from Exchange UM configuration . Normally these types of SCOM alert triggers on post migration situations mostly from Lync server 2013 to SFB 2015, what exactly triggers this SCOM alert is when Exchange server UM services were trying to communicate with legacy Lync Edge server pool.
How to make Exchange aware of that new configuration change? By running some cmdlets we can confirm that Exchange doesn’t have updated information.
The above cmdlet will give output like this
Name Status SIPAccessService
---- ------ ----------------
Here ‘Name’ column is nothing but your Exchange server (technically mailbox server), Status ‘enabled’ means it has been enabled for Unified messaging. But the most anticipated column ‘SIPAccessService’ is empty. If it is empty then, we can say exchange is unaware of new configurations. We could directly assign new Lync/SFB Edge server configuration to all our UM enabled Exchange servers.
But the question here is why Exchange needs Lync/SFB edge server pool address assigned?? Because users from outside network must use the closest Edge server pool for seamless RTP (Real time Transport Protocol) media traffic.
Once SDP negotiation is complete, RTP is used to send voice data back and forth between UM server and PBX or other UM server. RTP is merely a format for carrying audio and video data between endpoits, using dynamically assigned set of TCP and UDP ports.
The following cmdlet is used to assign SIPAccessService to UMServices.
It’s good to restart UM Servers after assigning SIPAcessService.
Set-UMService will accept the following parameters,
- Dialplans – it specifies all dial plan that UM services handles incoming calls for
- IPAddressFamily – it specifies whether UM IP Gateway will use IPV4 or IPV6 or both
-MaxCallsAllowed – Max no.of concurrent calls allowed that UM services allows, default: 100
- UMStartupMode – it specifies star up mode for UM services. [TCP, TLS, Dual]
- SIPAccessService* - it specifies FQDN and TCP port number for the nearest Lync/SFB server for the inbound and outbound calls from remote users located outside the network.