Tuesday, September 2, 2014

Lync 2013 Monitoring Time Zone -CDR and QOE databases have a different timezone than SQL Server

After installing the Monitoring Reports we encountered a strange issue stating that the SQL Reporting Services (SSRS) is inconsistent with the time zone for the CDR and QOE databases with a set of instructions to re mediate the issue.

Figure 1 illustrates the warning message and Figure 2 illustrates the error message when executing the stored procedures to correct the issue.


                                         Figure 1

Msg 547, Level 16, State 0, Procedure RtcClearTimeZoneInfo, Line 6

The DELETE statement conflicted with the REFERENCE constraint “FK_DaylightSavingYears_1″. The conflict occurred in database “QoEMetrics”, table “dbo.DaylightSavingYears”, column ‘TimeZone’.

The statement has been terminated.

(1 row(s) affected)

                                         Figure 2

After searching the Internet I came across a Duncan's blog http://eureka.greenhead.com/lync-monitoring-time-zone/ that reported the same issue with a fix from Microsoft support. Below are the details on correcting the issue:

There are two issues which prevent the successful execution of the stored procedure  'dbo.RtcClearTimeZoneInfo' in Lync 2013 which include:

1. A foreign key constraint between the DaylightSavingYears table and the TimeZones table which         prevents the TimeZones table from being cleared first.

2. There is now a trigger associated with the TimeZoneConfiguration table which requires there              always be exactly one row in the table.


To work around this issue the following SQL query at the root of the SQL instance.  It will execute the operation on both the LcsCDR and QoEMetrics tables.

declare @Status int
set @Status = 0
    DELETE from DaylightSavingYears WITH (TABLOCKX)
    if (@@error <> 0) begin
    if (@@error <> 0) begin
 ALTER TABLE TimeZoneConfiguration DISABLE TRIGGER "TimeZoneConfigurationTrigger";
    DELETE from TimeZoneConfiguration WITH (TABLOCKX)
    if (@@error <> 0) begin
 ALTER TABLE TimeZoneConfiguration ENABLE TRIGGER "TimeZoneConfigurationTrigger";
exec @Status = RtcTruncateSummaryTables
SELECT @Status

USE [QoEMetrics]
declare @Status int
set @Status = 0
    DELETE from DaylightSavingYears WITH (TABLOCKX)
    if (@@error <> 0) begin
    if (@@error <> 0) begin
 ALTER TABLE TimeZoneConfiguration DISABLE TRIGGER "TimeZoneConfigurationTrigger";
    DELETE from TimeZoneConfiguration WITH (TABLOCKX)
    if (@@error <> 0) begin
 ALTER TABLE TimeZoneConfiguration ENABLE TRIGGER "TimeZoneConfigurationTrigger";
exec @Status = RtcTruncateSummaryTables
SELECT @Status

The script combines the procs from both the LcsCDR and QoEMetrics in a single procedure. After running the script, you will still need to generate the summary tables with 

dbo.RtcGenerateSummaryTables in each of the databases.

Monday, May 26, 2014

Microsoft Lync Voice gateway failover - SipResponseCodeTranslationRules

In Lync environments that utilize multiple gateways for path failure it is important to understand the differences between a voice gateway hard and soft failure.  Lync does a great job with a hard failure and will mark that gateway down and proceed to try the next gateway/trunk that has been selected in the users Voice Policy.

There are two different types of Voice gateway failures in the Lync world. They include:

1. Hard down with the voice gateway being unreachable and marked down by Lync
2. Soft down with the voice gateway is reachable but the Carrier is having an issue.

The concentration will be focused on handling a soft down failure. Our example is based on a pair of Audiocodes Mediant 2600 SBC's that have independent circuits terminating to each gateway to provide high availability and failover. In the event of a soft failure the Audiocodes gateway responds with a 408 Request timeout which is defined as "couldn't find the user or determine the location of the user in time".  Because this is a client side response Lync will not failover to another gateway.  In order to get Lync to try the next gateway the response code must be a 5XX Server response failure.

So we need a way to tell Lync Server when it receives a 408 client response failure to try another gateway.  By using SipResponseCodeTranslationRulesList on the Lync Trunk we can translate both Sip and ISDN response codes to different Sip Response codes. In this case we will create a rule to map the client response code failure of 408 to a server side response code failure of 503 Service unavailable. Lync recognizes this as a gateway down issue and will try next PSTN usage record that is associated with the route and gateway/trunk as defined in the users Voice Policy.

Below is the command we used on the Global Trunk Configuration to convert 408 response code into a 503 response code.

New-CsSipResponseCodeTranslationRule -Parent Global -Name "Rule-408-to-503" -ReceivedResponseCode 408 -TranslatedResponseCode 503


 Viola! Lync will now try secondary route to alternate SBC gateway

Sunday, September 8, 2013

Exchange UM AA does not recognize spoken names (Galgrammargenerator.exe)

I was recently integrating a pair of Exchange 2010 UM servers to a Avaya CM 6.21 via Session Manager and ran across an interesting issue. After enabling several mailboxes for Exchange UM the users were not available in the Directory when speaking the subscribers name.  Though I could reach them using the touchtone menu by specifying the extension numbers.

I've seen this issue before and thought to myself - this is a just a case of the grammar files not updating.  I ran the following command to update the grammar files that contain the users recorded name or system generated name:

Galgrammargenerator.exe -d 'ACME UM Dial Plan' -o c:\temp\galgrammarresults01.txt and got the following output:

Generating Grammar: Grammar for all UM-enabled users in dial plan 'ACME UM Dial Plan'
Filter: ((((HiddenFromAddressListsEnabled -eq 'False') -and (((RecipientType -eq 'MailContact') -or (RecipientType -eq 'UserMailbox') -or (RecipientType -eq 'MailUser') -or (Phone -ne $null))) -and (((DisplayName -ne $null) -or (FirstName -ne $null) -or (LastName -ne $null))))) -and (EmailAddresses -like '*phone-context=ACME UM Dial Plan.acme.com') -and (EmailAddresses -like 'EUM:*'))
Downloading Entries: 09/03/2013 11:51:44
Downloading Entries Complete: 09/03/2013 11:51:44
The user "Henry E. Jensen III" with the e-mail address "hjensen@acme.com" was not added to the speech grammar because the speech recognition service has determined that it can be said in at least 10 ways. The maximum allowed is 1.
The user "Greg D. Rapp" with the e-mail address "grapp@acme.com" was not added to the speech grammar because the speech recognition service has determined that it can be said in at least 10 ways. The maximum allowed is 1.
Compiling grammar file E:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\grammars\en-US\59e94d9d-355c-4e1e-a4c6-b45dcc013998.grxml -> C:\Users\hejadmin\AppData\Local\Temp\ad8e619f-1cf4-4941-95e1-a4ea5f2bbd4d.cfg

Wowzers 10 different ways to say a name and only one allowed. After digging through the following Blog http://blogs.technet.com/b/exchange/archive/2006/10/30/3395749.aspx it is the display name where the users given name is generated from and then inserted into the speech grammar.
In this case the Display Names had periods, and designations like III that the speech grammars did not like. 

There are two solutions:
1)  Modify the display name attributes.
2)  Populate the PhoneticDisplayName attribute

I opted for the second option and executed the following command:
set-csuser -identity hjensen@acme.com -PhoneticDisplayName 'Henry Jensen'

Next I ran Galgrammargenerator.exe again and after a couple of minutes the user was added to the directory allowing a caller to search for the user name using voice commands.


-Paul Gurman-

Monday, August 19, 2013

Southern California Lync users Group

You are Invited!

NACR and Microsoft are proud to announce the Southern California Lync User Group – bringing together a wide range of professionals from companies including AudioCodes, AcmePacket, Polycom, Avaya, Radvision, Plantronics and Interactive Intelligence.

Organized by Paul Gurman, a Lync MCM from NACR, and Lee Reese, a Microsoft Lync Voice TSP for the Southwest, the group is dedicated to demonstrating the value of Unified Communications (UC) and exploring how the Microsoft stack can:

  • Increase ROI
  • Provide a cost-effective replacement strategy for aging phone switches
  • Integrate with contact center and line-of-business applications

 Join us and network with the experts

Our first event will feature AudioCodes presenting on Session Management with Lync and solutions for Auto Attendants at the Branch office, analog device handling and Voice Recording.

Refreshments will be provided by AudioCodes, and cool giveaways will be awarded by Plantronics.

RSVP by September 12th at the link to the below.  Seating is limited.

Friday, May 31, 2013

Integrating Microsoft® Lync™ with Your Avaya Environment Webinar


Join NACR for a Free Webinar:
Integrating Microsoft® Lync™ with Your Avaya Environment

The best of both worlds is within your reach!
You might already own the rights to Microsoft® Lync™ , a leading tool for IM and presence. You know you have Avaya.
Now learn how easy it is to integrate Lync into your existing Avaya environment — combining best-of-breed voice and data capabilities to improve your business productivity and bottom line.
Learn how to bring the two together.
This free webinar will help you understand the value of Lync and how to use it with your Avaya voice solution — providing an overview of the total solution including:
• Features and functionality
• High-level architecture
• Avaya and Lync licensing
• The integration options/scenarios
Let NACR help.
You’ll also hear how NACR can help you take advantage of it all — with our unique expertise in both voice and data, and our best-of-breed approach to unifying Avaya and Lync in a seamlessly converged infrastructure.

Event Details:
Wednesday, June 12, 2013
3:00 pm ET/2:00 pm CT

NACR is a leader in helping businesses like yours leverage technology to improve communication, collaboration, and customer interactions. Our credentials include:
  • Avaya Platinum Business Partner
  • Microsoft Gold Communications Partner
  • In-house Microsoft Certified Master (MCM)
  • Microsoft Lync Certified Support Partner
To register for the free webinar, simply click on the RSVP link above.
Questions? Talk to your NACR NAM or visit: www.nacr.com
NACR | 3344 Highway 149 |  Eagan, MN 55121| nacr.com

Saturday, May 4, 2013

Certificate Trust issue with Firefox but not IE

Came a cross an interesting issue in that when browsing to the Lync Dial web page we were getting the certificate was not trusted.  This did not occur with Internet explorer.

Naturally, I opened up the MMC console and added the certificate snap in to confirm that the Root CA for the Domain joined computer was installed in the trusted Root Certificate store.

Because Firefox was complaining about the Intermediate Certificate not being trusted I checked to see if Firefox is reading it from the Computers Cert store or it's own.  It appears Firefox builds it's own Trust list and was not reading the RootCA from the Trusted Root Certificate Store. Notice no SeaRoot Cert.

So I exported the Certificate from the local Machines Root Certificate Store and imported it into Firefox

Now we can see the Root CA and Firefox opens up the Dialin Webpage with out a certificate warning or prompt just like IE.


Paul Gurman

Monday, April 22, 2013

Frankenstein Lync integration with an Avaya via Cisco Cube and H.323

I recently had an opportunity to run a Lync 2013 Production Pilot integrating Lync 2013 Standard Edition server with an Avaya S8700 Communications Manager 3.1.2

At first glance you would say no problem just do a PRI integration using an Audiocodes gateway but because of Port capacity issues and costs the customer chose to use an H.323 integration leveraging a CLAN card. 

Audiocodes does not support the Avaya version of H.323 but Cisco ISR/CUBE does support Avaya's version of H.323.  Cisco Cube is on the Lync OIP list as well so you would think everything would go smoothly.  We managed to get calls back and forth between the two systems but there are several caveats.  The remaining part of this blog outlines the issues and why doing h.323 to SIP conversion is not my recommended approach.

1. DTMF - Everyone needs DTMF's and it is supported from Avaya through the Cisco ISR when    landing on the Lync Dial in Conferencing Bridge or choosing options when leaving a voicemail in Exchange UM. The issue is with the delay is takes from the CUBE to send the digits to the Lync     server.  Because Avaya version 3.1.2 appears not to be able to send a timer value within the H.245 out of band signaling for DTMF the Cisco CUBE defaults it 4000ms.  Changing DTMF to alphanumeric only provides a marginal improvement.  This is expected behavior according to Cisco TAC but the delay is not ideal for end users

2.  Caller ID -  Caller ID from the Avaya station side does not get passed.  From wireshark traces we don't see name of extension number in the from field in the H.245 signaling. Lync rewrites blank from fields with anonymous otherwise users would be confused by seeing the IP address of the  gateway.

3. Call Transfers - When an Avaya user calls a Lync user and the Lync user transfers the call back out to an Avaya end point or the PSTN the call drops after 30 seconds.  The issue is that the Avaya sends a FIN message and closes the TCP socket essentially severing the signaling and hair pinning of media through the Cisco CUBE.  The original calling party still shows the call is connected because once the FIN is sent the Cisco CUBE has no way of providing disconnect supervision as the TCP Port no longer is active.

Caller ID - Wireshark Capture:

Call Transfer Capture:

Call leg numbering:


Frame 4: Setup Request from Avaya to CUBE to establish TCP connection for H.225 signaling. This shows source Port 1720 and destination port 64970

Frame 16407: This is the TCP FIN message received from Avaya. The ports indicates that it’s the same TCP connection as the original H225 connection above. Upon receiving the FIN message, CUBE determines that this call leg’s call signaling is broken, so he proceeds to send SIP BYE to Lync for the 2nd call leg, and the disconnect propagates throughout the rest of the call.

BYE sent to Lync:

However, due to the H225 TCP connection between CUBE and Avaya is the first to tear down, CUBE and Avaya can no longer exchange H225 messages to disconnect the call, which is why we never see Release Complete sent from CUBE to Avaya for the first call leg.

Then about 6 seconds after the initial disconnect, Avaya sent CUBE a release complete for the first call leg, but using a different TCP connection (1720->14108)  which is the one used for call leg 4. CUBE is not listening on this port for the first call leg so it did not recognize the release complete message.