Thursday, January 22, 2015

Lync Mobile Client does not normalize dialed number

There is an issue cause confusion with the Lync Mobile Client behavior.
 
Let me give you a scenario:
Assume a user is located in Munich:
+49    Country Code Germany
89     Area Code Munich
314253 (main number)
554    (extension)
Full number : +4989314253544
 
Munich Lync phone number: tel:.+4989314253544;ext=1544
(the 1 stands for Munich)

New York Lync phone number: tel:.+16312455554;ext=2544
(the 2 stands for New York)

 
This number belongs to an internal Lync user and you have the normalization rules for this Munich location profile set as:
normalizing to 3-digit ->       +4989314253$1
normalizing to 4-digit ->       cut 1 - +4989314253$1
normalizing to 4-digit ->       cut 2 - +16312455$1
normalizing to 9-digit ->       +4989$1
normalizing to 0+11-digit ->    cut 0 - +49$1
normalizing to 0049+11-digit -> cut 00 - +$1
normalizing to 001+10-digit ->  cut 00 - +$1
 
This number belongs to an internal Lync user and you have the normalization rules for this New York location profile set as:
normalizing to 3-digit ->       +16312455$1
normalizing to 4-digit ->       cut 1 - +4989314253$1
normalizing to 4-digit ->       cut 2 - +16312455$1
normalizing to 7-digit ->       +1631$1
normalizing to 0049+11-digit -> cut 00 - +$1
normalizing to 001+10-digit ->  cut 00 - +$1
 
It normalize the expected E.164 format matching the internal users Lync Phone Number
 
If you dial as use have a location profile of Munich location to, you now can dial the following:
 
544             Mobile Client show: 544
1544            Mobile Client show: 1544
314253544       Mobile Client show: 314253544       
089314253544    Mobile Client show: 089314253544      
+4989314253544  Mobile Client show: +4989314253544 
004989314253544 Mobile Client show: 004989314253544       
All Calls are successful !
 
If you dial as use have a location profile of New York location to, you now can dial the following:
 
544             Mobile Client show: 544 (not match and normalize to New York)
1544            Mobile Client show: 1544 (CALL SUCCESSFUL and normalize to Munich)
314253544       Mobile Client show: 314253544 (no match)       
089314253544    Mobile Client show: 089314253544 (no match)     
+4989314253544  Mobile Client show: +4989314253544  (CALL SUCCESSFUL)
004989314253544 Mobile Client show: 004989314253544 (CALL SUCCESSFUL)
 
 
As you see the Lync mobile client do not show the normalization.
It keeps the number you dialed, similar as the behavior dialing from your mobile itself.

Why the call can reach the user?
Lync can process the given normalization rules on the Server, (in-band provisioning) and also knows the location profile the calling user has assigned, which than include the DialPlan with the Normalization Rules.

Therefore its a normal behavior.

Solution:
If the call do not work as described in the simple example aforementioned, your location profile and normalization rules are incorrect. You need modifying your dial plans.


Wednesday, January 21, 2015

Cannot send IM from Outlook Web Apps

There are three possible reasons why you can't send IM from Outlook Web Apps (OWA).
I assume first, the integration was done according to the recommendations given. Meaning you have also tested that internal IM from OWA was possible to send and receive.

If you encounter the following behavior:
- Presence can be queried, but I’M cannot be initiated.
- If you receive an external IM, you are able to answer the external contact.
- You cannot receive or send external IM from OWA
 
While you are using the OCSLogger on the Lync Edge Server, you might see the following SIP 403 Forbidden message:
 
Text: SUBSCRIBE request for get rich presence was rejected by the Access Edge Server
Result-Code: 0xc3e93d80 SIPPROXY_E_EPROUTING_MSG_INT_GET_RICH_PRESENCE_FILTERED

You also see the internal Exchange Server with ipconfig -displaydns as:
_sipfederationtls._tcp.sip-domain.com


Solution:
1. Your external policy do not allow access to federated partner or public IM systems. Therefore you need to change those policies, or assign the correct policy to the affected users

2. You have the correct policy, but you sill can't reach out to external contact, the SIP address might be incorrect, or the federated partner is not allowed to communicated externally

3. Most likely, if the policy settings are correct the third possibility occurs. For external IM communication you must have a CONTACT OBJECT in Exchange. IM can only be initiated via a contact object and this is different from your Lync Client, where you are able to type a address in the address bar.
In OWA you can add a contact including the CHAT address, but here you have to add the chat address in the following format:
SIP:user@sip-domain.com
OWA can only initiate a IM if the SIP Prefix is present, else the error message shown above will be logged. This is an issue by design of Exchange utilizing the UCMA API.
Additionally, you also have to apply the Lync Cumulative Updates to the UCMA installed on each Exchange CAS Server. This is mostly forgotten by the Exchange admins.
 
 

This article says, if you wish to communicate with external buddies, you have to add a Outlook Contact and MUST include SIP: prefix.
https://support.microsoft.com/kb/2977259

Thursday, January 15, 2015

Skype for Business and Lync Monitoring for Enterprise Voice

Monitoring, a component in Lync which is most important.
Not only collecting information about the servers and their services. Since here are users directly involved with their end devices, like phones, headset or computers. In between of those components sits the network and routing devices. Not enough here, mostly Lync or Skype for Business work in an environment where other voice solutions, e.g. PBX's or SIP Systems are running in parallel. During a migration for example, if you move users towards Enterprise Voice, the PBX and e.g. SIP Trunk Providers are in the loop for quite some time.

This makes monitoring of the entire Voice solution essential.

Lets see hat Lync and Skype for Business offers:
Microsoft has introduced a two databases, the CDR and QoE database. Those are databases where Call Details are recorded and the entire environment quality data, like Server and service health, as well as the quality relevant information about call, either a P2P or Enterprise Voice call, and data about conferences.
With predefined SQL Reports you can query those data. And they are essential not only for troubleshooting, they are essential monitoring trends as well.
You have a dashboard providing an generic overview and the individual reports allowing you having a deep inside view of each call and component.

But here the main question comes into place: If I'm in the midst of an migration, or even having two UC solution in place, where can I see and monitor the entire environment of my company.

The answer is you cannot do this with the Microsoft Monitoring components. You need either multiple different systems, where you will encounter difficulties bringing those information together.

Saying a Skype for Business user is calling a user still not migrated from an AVAYA PBX. Both system are connected via SIP Trunk or via the SBC.
Now you cannot monitor this call.
The only solution is you take the Microsoft site and the Avaya site combine possible reports and try your best.

Now what I personally recommend to customers addressing this problem:

It is IR, PROGNOSIS.

This is the only solution able to utilize every source in your environment, the Microsoft Reporting databases, the SDN APIs, and the most PBX and UC vendors. Consolidating all information into a single system and provide you the entire, overall view.

Lets have a look into it:

 
With Prognosis I can address all components in Lync and Skype for Business, including the SDN API too. Therefore I also collect the CDR and QoE database information.
 
 
But that's not enough, in an UC environment, we learned that the user experience is quite important. This the user has a sensitive organ, the ear. Therefore he has subjective sense to a call he made. It is helpful, if we can identify those calls too. We know that the Skype for Consumes offer those function. With Prognosis, we can integrate this feature also into Lync 2010 and Lync 2013.
 
 
 
From here we can validate the call in more simpler way than we could do with the integrated reporting in Lync/ Skype for Business. 
 
 
As mentioned earlier, having a view over all involved components, we call this feature in Prognosis Voice Quality 360. The call can be monitored from end-to-end over all solution, e.g. from Lync to Avaya, or from CCM to Skype for Business.

 
As the path is important we also need trace those call with e.g. SBC. here is an example tracing a call from Cisco Call Manager to Lync, End-to-End. Have the SBC from AMCE in place. This can help us to clearly identify where we would have the problem located, e.g. a lower MOS Score. From this point onwards we simple click down to the component identified.

 
Conference are another issue. How often I was asked to identify a "bad" call in a conference, even with more than 100 participants. Wow difficult task and a lot of work.
With Prognosis, it made my life easy, as I could see the call was bad on the sending path.

 
Summary:
if you are the Administrator in company, you should be able tracing your environment entirely and have the right tool to support your work, so you can approach the correct troubleshooting way directly.
Additionally, we can deliver those information also to our support partners which than save a lot of time doing their parts.

Monday, January 12, 2015

Troubleshooting Guide Skype for Business and Lync

The free eBook is about troubleshooting Skype for Business and Lync.

A complex solution in unified communication marking people's life more simpler, connecting to óther at any point of time, staying in contact with fellow friends and family members. Developing a set of skills, supporting and analyzing issues in this environment is an advanced task. I describe the troubleshooting work flow from general understanding of Skype for Business and Lync Server and Services.

In the Troublehsooting Guide the following areas are covered:
- General Approach to troubleshooting
- Logging, Tracing and CLS
- TCP and SIP Protocol
- SIP Session Establishment
- Lync/ Skype for Business Call Setup (entire process)
- Troubleshooting IM
- Troubleshooting Call with A/V
- Diagnostic Headers
- Monitoring
- Troubleshooting Voice
- Troubleshooting Conferencing
- Troubleshooting Web Services
- Troubleshooting Edge (external/ remote)
- Health Monitoing
- Troubleshooting Exchange Intergation
(Autodiscover, Exchange Web Service EWS, IM Integration in OWA, Unified Contact Store UCS, Unified Messaging)
- Troubleshooting Mobility Services
- Troubleshooting Mobile Clients
- Troubleshooting Office Web App Server (OWA)


Troubleshooting Enterprise Voice will be released during a future update of this document (Version 2.0)


Troubleshooting Guide is ready for download:

Please have a look and enjoy.