Microsoft

Blog Categories

Subscribe to RSS feed

Archives

Keenan Crockett

Lync Team Lead & Senior Solutions Architect at Perficient | Microsoft Certified Master: Lync Server 2010

LinkedIn LinkedIn Public Profile
Twitter keenancrockett

Posts by this author: RSS

The Eleventh Day of Lync’mas: Unified Communications Resources

This is part eleven of a twelve post series, to see an index of all twelve posts click here.

On the eleventh day of Lync’mas my UC Team gave to me:  Eleven Unified Communications resources (web sites, blogs, and social media references).

I could list over 100+ links to my favorite Lync websites and blogs, but following the Lync’mas theme, I’ll try to narrow it down to eleven.  What are we waiting for, lets get started.

1. Lync 2013 Conference

  • Microsoft is hosting the first ever Lync conference Feb 19-21st in San Diego, CA.  If you haven’t signed up yet, there is still time.  Perficient is the evening sponsor for the conference, so please find us if you’re planning on attending!

2. NextHop

  • A great source for in-depth Lync articles by the premier support engineers and MVPs.

(more…)

The Fourth Day of Lync’mas: Lync and Paging Best Practices

This is part four of a twelve post series, to see an index of all twelve posts click here.

On the fourth day of Lync’mas my UC Team gave to me:  Lync Enterprise Voice and Overhead Paging Best Practices.

Before we deep dive into the technical details, you might be wondering how does overhead paging relate to the fourth day of Lync’mas?  When planning Enterprise Voice migrations, we typically work with our customers to integrate Lync certified gateways with their analog devices, including overhead paging systems.  During migrations, it’s important to understand the paging system requirements and how to make the functionality work seamlessly with the best UC solution on the market.   Therefore, the fourth day Lync’mas focuses on FXS/FXO interfaces and loop/ground start signaling… 

(more…)

Lync, XMPP and Google Apps Domain Talk Service Validation Errors

In my original XMPP post, I discussed how to troubleshoot TLS errors relating to Lync and the Microsoft OCS 2007 R2 XMPP gateway. If you believe you’re having TLS related issues, please refer to my previous post. This blog will focus on Lync troubleshooting techniques and Google XMPP responses when establishing federation between the two environments. 

Background

A Lync 2010 architecture was deployed with an XMPP server for instant messaging federation to Google (gmail.com and other Google App domains).  Once the XMPP service was deployed, my customer started receiving the infamous “presence unknown” for Google contacts.  For the purposes of this blog, let’s say the Lync SIP domain (chi.contosouniversity.edu) was used by faculty and the Google Apps domain (gmail.com & contosouniversity.edu) was used by the student population.  Side note… Let’s be real, everyone should be using Lync at this point… Anyways, moving on.

The environment was built to spec, but when Lync users tried to add Google users (gmail.com or contosouniversity.edu) they would simply receive “presence unknown.”  If you didn’t catch it previously, the Lync SIP domain (chi.contosouniversity.edu) is a sub-domain of contosouniversity.edu.  The root domain (contosouniversity.edu) was enabled for Google Apps Talk Service. 

Long story short, the presence issue was caused by a misconfiguration in the Google Apps portal prior to the Lync deployment.  The sub-domain (chi.contosouniversity.edu) was mistakenly enabled for the Google Apps Talk Service.  Unfortunately at the time, I did not have access to the Google Apps Portal.  If you fall into the same boat, below are the troubleshooting techniques that can be used to pinpoint the misconfiguration.

The architecture looks similar to:

image

 

Troubleshooting Overview

To begin troubleshooting, we’ll first start tracing on the XMPP gateway.

  • Log onto the XMPP server
  • Navigate to C:\Program Files\Microsoft Office Communications Server 2007 R2\XMPP Gateway\Tracing
  • Double-click Snooper

clip_image002[4]

  • Once the Office Communications Server 2007 R2 Logging Tool appears, select the following options:
    • OCSXMPPGateway
      • Level – All
      • Flags – All Flags
    • S4
      • Level – All
      • Flags – All Flags
  • Finally, click the Start Logging button
  • Attempt to send an IM from a Lync user to a Gmail user
    • In the example trace provided below, the Lync user is joe@chi.contosouniversity.edu and the Google Apps user is sarah@contosouniversity.edu

clip_image004[4]

  • After the instant message fails, click Stop Logging
  • Click View Log Files
    • If you mistakenly click Analyze Log Files, the snooper trace will be blank as shown in the figure below

clip_image006[4]

Once the log file appears, sift through the log and the snippet should appear similar to the one below. 

TL_VERBOSE(TF_COMPONENT) [0]04E0.051C::04/09/2012-18:17:26.284.00000242 (S4,SipMessage.set_Connection:58.idx(211))( 00000000032137E2 )connection set <null>-><SipTlsConnection_110ED42>

TL_INFO(TF_COMPONENT) [0]04E0.051C::04/09/2012-18:17:26.284.00000243 (OCSXMPPGateway,SipStackInterface.BuildErrorResponse:65.idx(2151))( 0000000000ED7661 )<– Sending Error 481-Call Leg/Transaction Does Not Exist, from=joe@chi.contosouniversity.edu, to=sarah@contosouniversity.edu

TL_INFO(TF_COMPONENT) [0]04E0.051C::04/09/2012-18:17:26.284.00000244 (OCSXMPPGateway,SipStackInterface.BuildErrorResponse:65.idx(2222))( 0000000000ED7661 )Invalid Method name – ACK from joe@chi.contosouniversity.edu to sarah@contosouniversity.edu

TL_WARN(TF_COMPONENT) [0]04E0.051C::04/09/2012-18:17:26.284.00000246 (OCSXMPPGateway,SipStackInterface.sipCoreManager_RequestReceived:65.idx(130))( 0000000000ED7661 )Request cannot be processed and therefore sending a 481 response

TL_VERBOSE(TF_COMPONENT) [0]04E0.051C::04/09/2012-18:17:26.284.00000247 (S4,SingleThreadedDispatcherQueue.DispatcherCallback:33.idx(236))( 0000000000F47E10 ) <unknown> queue workitem callback Microsoft.Rtc.Internal.Sip.DispatchEventWorkitem took 0 mseconds

TL_VERBOSE(TF_COMPONENT) [0]04E0.051C::04/09/2012-18:17:26.284.00000248 (S4,SingleThreadedDispatcherQueue.DispatcherCallback:33.idx(274))( 0000000000F47E10 )Finished Workitem Microsoft.Rtc.Internal.Sip.DispatchEventWorkitem

TL_VERBOSE(TF_COMPONENT) [0]04E0.051C::04/09/2012-18:17:26.284.00000249 (S4,SingleThreadedDispatcherQueue.DispatcherCallback:33.idx(306))( 0000000000F47E10 )Finished

TL_WARN(TF_COMPONENT) [0]04E0.0758::04/09/2012-18:17:29.112.0000024b (OCSXMPPGateway,StreamConnection.onConnectionTimer_Elapsed:0.idx(331))( 0000000001C8F391 )Connection failed to contosouniversity.edu on port 5269 on Connection timer elapsed so removing Outgoing Queue and Outgoing Connection

TL_INFO(TF_COMPONENT) [0]04E0.0758::04/09/2012-18:17:29.112.0000024f (OCSXMPPGateway,StreamManager.DeleteOutgoingDispatcher:0.idx(1811))Deleting outgoing Queue for contosouniversity.edu

TL_INFO(TF_COMPONENT) [0]04E0.0758::04/09/2012-18:17:29.112.00000251 (OCSXMPPGateway,StreamManager.DeleteOutgoingConnection:0.idx(1561))Deleting outgoing connection to contosouniversity.edu

TL_WARN(TF_COMPONENT) [0]04E0.09A0::04/09/2012-18:17:29.112.00000253 (OCSXMPPGateway,StreamManager.CreateOutgoingConnection:0.idx(1399))Stopped waiting for connection

TL_INFO(TF_COMPONENT) [0]04E0.09A0::04/09/2012-18:17:29.112.00000254 (OCSXMPPGateway,OutgoingDispatcher.Dispatch:60.idx(124))( 0000000002B89EAA )Connection not found. Creating connection to contosouniversity.edu

 

Sifting through the trace, one can quickly tell that the captured trace is not extremely helpful in telling us what exactly caused the communication to fail. While we see a 481-Call Leg/Transaction Does Not Exist and Connection failed to contosouniversity.edu (or gmail.com, etc.) on port 5269 on Connection timer elapsed so removing Outgoing Queue and Outgoing Connection error, one might assume there is a communication issue between the Lync Edge server(s) and XMPP gateway or between the XMPP gateway and Gmail… Well, not so fast.

To ensure firewall rules are open, I first recommend establishing an external telnet session to the external IP address assigned to the XMPP gateway on port 5269. This connection should be successful. Next, I recommend establishing a telnet session from the XMPP gateway to the following Google XMPP servers on port 5269. Again, the majority of these connections should be successful.

  • xmpp-server.l.google.com
  • alt1.xmpp-server.l.google.com
  • alt2.xmpp-server.l.google.com
  • alt3.xmpp-server.l.google.com
  • alt4.xmpp-server.l.google.com

If all telnet sessions are successful and you’re still questioning why IMs are failing, switch gears and open Network Monitor on the XMPP gateway.  If you were like me previously, you probably do not have the NtSimpleSearch Expert installed.  You can quickly tell by clicking the Experts tab near the top menu.  If all you see is Download Experts, you have your answer.

clip_image006

To make this process easier, navigate to the MSDN NMSimpleSearch website to download the expert.  Once the NMSimpleSearch Expert has been installed, it should appear under the Experts window.

clip_image007

Forget the NMSimpleSearch Expert for a moment and start a new network capture. Send another IM from a Lync user to a Gmail user.  Once the trace is stopped, the cause to our 481-Call Leg/Transaction Does Not Exist error will actually be returned from Google’s XMPP servers.  To find the answer, you can 1) manually read through each packet inspecting the Hex details for the following XML information…

<stream:error><undefined-condition xmlns=”urn:ietf:params:xml:ns:xmpp:-streams”/><str:text xmlns:str=”urn:ietf:params:xml:ns:xmpp-streams”>chi.contosouniversity.com is a Google Apps Domain with Talk Service enabled.</str:text></stream:error></stream:stream>

… or 2) use the NtSimpleSearch Expert to locate error. 

Assuming you want to save yourself the headache, I’ll proceed with option 2. 

  • To use NtSimpleSearch, first save the network trace.
    • When saving the file, ensure All captured frames is selected

clip_image004

  • Once the trace has been saved, close and reopen Network Monitor
  • Open the previously saved network capture
  • Select Experts | NtSimpleSearch
  • Once the NmSimpleSearch dialog box appears, enter Google Apps in the search field

If we’re troubleshooting the same issue, at least one instance should be found.

image

Lo and behold, Google is telling the Microsoft XMPP gateway that the domain (chi.contosouniversity.edu) is a Google Apps Domain with Talk Service enabled. 

There you have it!  Simply disable the Talk Service for the appropriate domain(s) in the Google Apps portal and instant messages should start working.

image

Comments Welcomed.

Lync Mobility – Understanding SIP Sign-in Address vs. User Principle Name (UPN)

With the recent release of the Lync Mobile client for Windows Phone 7, Android, and iPhone, I’ve seen numerous companies thrilled about the opportunity to extend Lync further within the enterprise! For companies interested in deploying Lync Mobility, the Lync Server Cumulative Update 4 is required. For deployment steps, I highly recommend reading the Microsoft Lync Server 2010 Mobility Guide and Jeff Schertz’s blog.

After working with various customers to deploy the new Mobility service, occasionally I get asked “Why do I have to enter my username to sign into my Lync mobile client?”

I’ve read articles that mentioned if the SIP address username differs from the AD username, than the user would have to manually populate the User Name field to authenticate successfully. For example:

  • SIP Sign-in Address: jdoe@contoso.com
  • AD Username: john.doe

The mismatch between SIP sign-in address and AD username made sense to me, but for my customers their usernames matched. For example, the SIP address username matched their AD username:

  • SIP Sign-in Address: jdoe@contoso.com
  • AD Username: jdoe

Fast forwarding, Microsoft has published a mobility troubleshooting guide (KB2636318) which outlines various troubleshooting techniques. The article makes reference to the SIP sign-in address vs. UPN, but does not go into great detail. Below are two scenarios that highlight the difference between SIP sign-in address vs. User Principle Name (UPN) and the expected Lync mobile client behavior.

Scenario 1: Matching SIP Sign-in Address & User Principle Name (UPN)

  • To validate the UPN of a user, first launch ADSI Edit
    • Connect to the Default Naming Context
    • Expand the domain structure and locate the user account object
    • Right-click the user account object and click Properties
    • Scroll down to the field named userPrincipalName
  • In the screenshot below, the UPN (kcrockett@pbtest.com) is provisioned in the same format as my SIP domain (kcrockett@pbtest.com)

  • Switch over to the Lync Mobile client and populate the Sign-In Address and Password field
    • In this scenario, the User Name field is left blank
  • Once the information has been entered, click the Sign In button

  • As indicated in the screenshot below, the Lync Mobile client automatically signs in. Hurray!!!

Scenario 2: Mismatch between the SIP Sign-in Address & User Principle Name (UPN)

  • To validate the UPN of a user, first launch ADSI Edit
    • Connect to the Default Naming Context
    • Expand the domain structure and locate the user account object
    • Right-click the user account object and click Properties
    • Scroll down to the field named userPrincipalName
  • In the screenshot below, the UPN (kcrockett@pbtest.local) is provisioned in a different format as my SIP domain (kcrockett@pbtest.com)

  • Switch over to the Lync Mobile client and populate the Sign-In Address and Password field once again
    • To demonstrate, the User Name field is left blank
  • Once the information has been entered, click the Sign In button

  • Unfortunately, since I left the User Name field blank, I received the warning “Can’t sign in. Please check your account information and try again.
  • In the Lync Mobile client tracing log, the following error should also be reported:
    • 401 – Unauthorized: Access is denied due to invalid credentials. You do not have permission to view this directory or page using the credentials that you supplied.

  • Switch back to the Lync Mobile client and repopulate the Sign-In Address and Password field, if necessary
  • Populate the Username field using the format domainusername (e.g. pbtestkcrockett)
  • Once the information has been entered, click the Sign In button

  • As indicated in the screenshot below, the Lync Mobile client signs in. Success!

Comments welcomed!

PRACK Causes No Ringback between CUCM and Lync

I recently had the pleasure of working with one of our customers to implement Lync Server 2010 Enterprise Voice with Cisco Unified Communications Manager (CUCM) 7.1.3. The integration between the two systems went pretty smoothly. During our testing phase though, we uncovered an issue with ringback. When a PSTN user or a Cisco IP Phone user would dial a Lync endpoint, the PSTN user and/or Cisco user would hear silence (no ringback) until the call was answered by the Lync user or diverted to Exchange Unified Messaging. Even stranger, we had a lab environment with the same CUCM version and Lync patch version which was working fine. After capturing a handful of call traces between the two platforms, we noticed:

  • CUCM was inserting a PRACK in the call setup signaling for every call to Lync
  • There were multiple 183 session progress messages between CUCM & Lync
    • Cisco has a documented ringback bug (CSCtf87428) that was discovered in CUCM 7.1.3.
    • According to the Cisco Bug Toolkit CSCtf87428, “OCS connected to CUCM via SIP and call coming in via H323 GW we get multiple “183 Session progress” from the OCS without any SDP information. At this point CUCM is sending “Progress” to the gateway with PI = 8, so the GW stops playing the ringback. As there is no SDP information received from OCS side the calling party gets silence.”
    • According to the Cisco Bug Toolkit CSCtf87428, CSCtf87428 is resolved in 7.1(5.11006.2). Unfortunately, we were not in a position to upgrade the Cisco cluster and ringback was
      working in the lab. We therefore opted to not upgrade CUCM and to investigate the issue further.

As outlined in the SIP RFC 3261, I expected to see something similar to the following:

  • Invite
  • 100 Trying
  • 183 Session Progress
  • 180 Ringing
  • 200 OK
  • RTP (Audio)

After working with the client to compare settings between the lab and production CUCM environments, we uncovered an interesting setting. Under the CUCM Service Parameters for the Cisco CallManager service, there is a field called SIP Rel1XX Enabled. Below is a screenshot of the configuration that had been set. SIP Rel1XX Enabled had been set to Send PRACK for all 1xx Messages.

As indicated in the right-hand column of the screenshot, the default setting for SIP Rel1XX Enabled is disabled. We scratched our heads… This setting had obviously been manually changed, but by whom and for what reason. After circling back with other team members, we had uncovered that this had been enabled as part of a previous initiative. Long story short, the setting was deemed not critical and we received approval to change the setting back to the default value of disabled. Below is a screenshot of the updated configuration.

After SIP Rel1XX Enabled had been set back to the default value, we captured a few more call traces between the two platforms. As shown in the screenshot, the call setup signaling looked better and more importantly ringback worked!

Comments welcomed.

Distinguishing Between Voice Routes Configured for Load Balancing vs. Voice Policies Configured for Failover and Least Cost Routing in Lync Server 2010

Overview

Lync Server 2010 is extremely granular when it comes to routing voice calls. Lync administrators can configure a voice call to load balance between multiple PSTN gateways within a single site or failover to a PSTN gateway in a second site in the event the primary PSTN gateway fails. After numerous discussions with colleagues and clients, I thought I’d share my thoughts on the difference between the two configurations.

Table 1 below provides a voice routing overview. There are two sites (HQ and Branch). The HQ site is in Chicago with a 312 area code and the Branch site is in Indiana with a 260 area code.

Table 1 – Voice Routing Overview

Figure 1 below provides an example topology between the HQ and Branch sites.

 

Figure 1 – Topology Overview

Voice Routes Configured for Load Balancing

Table 2 below outlines various configuration scenarios related to load balancing outbound calls between PSTN gateways.

Table 2 – Voice Route Load Balancing

Figure 2 below displays a correctly configured Voice Route with a single gateway. As outlined in scenario 1 and 4 above, Lync will not load balance voice traffic between voice gateways if only a single gateway is defined in the voice route.

Figure 2 – Single PSTN Gateway

Figure 3 below displays an incorrectly configured Voice Route with two gateways spread across the two different sites. As outlined in scenario 3 and scenario 6 above, Lync will load balance voice traffic between the PSTN gateways defined in the voice route. In this scenario however, voice traffic will round robin between the Branch and HQ site which would cause unexpected results (caller-id issues, bandwidth consumption, call quality issues, etc.).

Figure 3 – Incorrectly Configured PSTN Gateway Load Balancing

Figure 4 below displays a correctly configured Voice Route with two gateways in the same site. As outlined in scenario 2 and scenario 5 above, Lync will load balance voice traffic between the PSTN gateways defined in the voice route. In this scenario though, voice traffic will correctly round robin between the PSTN gateways in the HQ site.

Figure 4 – Correctly Configured PSTN Gateway Load Balancing

Figure 5 below provides an example topology distinguishing voice load balancing between the HQ and Branch sites.

Figure 5 – Voice Load Balancing Per Site

Voice Policies Configured for Failover and Least Cost Routing

Now that we’ve reviewed how Lync Server 2010 load balances outbound voice traffic to various PSTN gateways, let’s review how to correctly configure voice policies to handle gateway failure and least cost routing. Table 3 below displays a 1:1 relationship between a voice route and PSTN gateway – meaning Lync will attempt to route a specific call type (e.g. local calls) out a single PSTN gateway (HQ-SBA.kcdemo.local).

Table 3 – Voice Route & PSTN Gateway Assignment

Table 4 below outlines various configuration scenarios related to gateway failover and least cost routing.

Table 4 – Voice Policy Failover & Least Cost Routing

HQ Site Example

Figure 6 below displays a basic voice policy (HQ-Unrestricted) that does not have a failover or least cost usage configured. In this example, UserA has been assigned the HQ-Unrestricted voice policy. All outbound calls made by UserA will route out the local HQ PSTN gateway (HQ-SBA.kcdemo.local).

Figure 6 – HQ Voice Policy with no Failover or Least Cost Route

Figure 7 below displays an advanced voice policy (HQ-Unrestricted) that has multiple failover and least cost usages configured. In this example, UserB has been assigned the HQ-Unrestricted voice policy. In this scenario, UserB will experience the following:

  • All local calls (312 area code) will route out UserB’s local PSTN gateway (HQ-SBA.kcdemo.local)
  • Indiana calls (260 area code) will route out the branch gateway (Branch-SBA.kcdemo.local)
  • All long distance calls will route out UserB’s local PSTN gateway (HQ-SBA.kcdemo.local)
    • If the local PSTN gateway (HQ-SBA.kcdemo.local) were to fail, all outbound long distance calls would failover to the branch gateway (Branch-SBA.kcdemo.local)
  • All international calls will route out UserB’s local PSTN gateway (HQ-SBA.kcdemo.local)
    • If the local PSTN gateway (HQ-SBA.kcdemo.local) were to fail, all outbound international calls would failover to the branch gateway (Branch-SBA.kcdemo.local)

Figure 7 – HQ Voice Policy Configured for Least Cost Routing & Failover

Figure 8 below provides an example topology distinguishing how the HQ-Unrestricted voice policy will handle primary, failover, and least cost PSTN usages between the HQ and Branch sites.

Figure 8 – Topology for HQ Voice Policy Configured for Least Cost Routing & Failover

Branch Site Example

Figure 9 below displays a basic voice policy (Branch-Unrestricted) that does not have a failover or least cost usage configured. In this example, UserC has been assigned the Branch-Unrestricted voice policy. All outbound calls made by UserC will route out the local Branch PSTN gateway (Branch-SBA.kcdemo.local).

Figure 9 – Branch Voice Policy with no Failover

Figure 10 below displays an advanced voice policy (Branch-Unrestricted) that has multiple failover and least cost usages configured. In this example, UserD has been assigned the Branch-Unrestricted voice policy. In this scenario, UserD will experience the following:

  • All local calls (260 area code) will route out UserD’s local PSTN gateway (Branch-SBA.kcdemo.local)
  • Chicago calls (312 area code) will route out the HQ gateway (HQ-SBA.kcdemo.local)
  • All long distance calls will route out UserD’s local PSTN gateway (Branch-SBA.kcdemo.local)
    • If the local PSTN gateway (Branch-SBA.kcdemo.local) were to fail, all outbound long distance calls would failover to the HQ gateway (HQ-SBA.kcdemo.local)
  • All international calls will route out UserD’s local PSTN gateway (Branch-SBA.kcdemo.local)
    • If the local PSTN gateway (Branch-SBA.kcdemo.local) were to fail, all outbound international calls would failover to the HQ gateway (HQ-SBA.kcdemo.local)

Figure 10 – Branch Voice Policy Configured for Least Cost Routing & Failover

Figure 11 below provides an example topology distinguishing how the Branch-Unrestricted voice policy will handle primary, failover, and least cost PSTN usages between the Branch and HQ sites.

 

Figure 11 – Topology for Branch Voice Policy Configured for Least Cost Routing & Failover

Miscellaneous Information

Failed Gateway

The following are Event Viewer errors that will appear when the Lync Mediation service cannot communicate to a primary PSTN gateway.

Log Name: Lync Server 
Source: LS Mediation Server 
Date: 5/31/2011 5:43:27 PM 
Event ID: 25051 
Task Category: (1030) 
Level: Error 
Keywords: Classic 
User: N/A 
Computer: Branch-SBA.kcdemo.local 
Description: 
There was no response from a gateway to an OPTIONS request sent by the Mediation Server. 
The Gateway peer, Branch-SBA.kcdemo.local, is not responding to an OPTIONS request sent by the Mediation Server service 
Cause: The Mediation Server service cannot communicate with the Gateway Peer Service over SIP due to network connectivity issues. 
Resolution: 
Please ensure network connectivity and availability of the Gateway Peer for the Mediation Server service to be able to function correctly. 
Event Xml: 
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
 <System> 
 <Provider Name="LS Mediation Server" /> 
 <EventID Qualifiers="50182">25051</EventID> 
 <Level>2</Level> 
 <Task>1030</Task> 
 <Keywords>0x80000000000000</Keywords> 
 <TimeCreated SystemTime="2011-05-31T22:43:27.000000000Z" /> 
 <EventRecordID>3798</EventRecordID> 
 <Channel>Lync Server</Channel> 
 <Computer>Branch-SBA.kcdemo.local</Computer> 
 <Security /> 
 </System> 
 <EventData> 
 <Data>Branch-SBA.kcdemo.local</Data> 
 </EventData> 
</Event>
Log Name: Lync Server 
Source: LS Mediation Server 
Date: 5/31/2011 5:43:28 PM 
Event ID: 25036 
Task Category: (1030) 
Level: Error 
Keywords: Classic 
User: N/A 
Computer: Branch-SBA.kcdemo.local 
Description: 
Mediation Server cannot reach the Gateway. Additional failures will not be logged. 
Cannot reach Gateway: Branch-SBA.kcdemo.local 
Cause: Gateway IP address is invalid or gateway is not functioning correctly. 
Resolution: 
Check the Gateway address and Gateway status. 
Event Xml: 
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
 <System> 
 <Provider Name="LS Mediation Server" /> 
 <EventID Qualifiers="50182">25036</EventID> 
 <Level>2</Level> 
 <Task>1030</Task> 
 <Keywords>0x80000000000000</Keywords> 
 <TimeCreated SystemTime="2011-05-31T22:43:28.000000000Z" /> 
 <EventRecordID>3799</EventRecordID> 
 <Channel>Lync Server</Channel> 
 <Computer>Branch-SBA.kcdemo.local</Computer> 
 <Security /> 
 </System> 
 <EventData> 
 <Data>Branch-SBA.kcdemo.local</Data> 
 </EventData> 
</Event>
Log Name: Lync Server 
Source: LS Outbound Routing 
Date: 5/31/2011 5:43:58 PM 
Event ID: 46009 
Task Category: (1038) 
Level: Error 
Keywords: Classic 
User: N/A 
Computer: Branch-SBA.kcdemo.local 
Description: 
An attempt to route to a gateway failed. 
Could not route to Gateway Branch-SBA.kcdemo.local, the attempt failed with response code: 504 Cannot connect to gateway. Socket error: ConnectionRefused (CallID: 961ebe754b964b55bf9aa3085202ce43). 
Failure occurrences: 1, since 5/31/2011 5:43:28 PM. 
Cause: A gateway failed to respond to a request within allotted time or was unable to route the request due to some error. 
Resolution: 
Check whether the specified gateway is up and is properly configured. 
Event Xml: 
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
 <System> 
 <Provider Name="LS Outbound Routing" /> 
 <EventID Qualifiers="50190">46009</EventID> 
 <Level>2</Level> 
 <Task>1038</Task> 
 <Keywords>0x80000000000000</Keywords> 
 <TimeCreated SystemTime="2011-05-31T22:43:58.000000000Z" /> 
 <EventRecordID>3800</EventRecordID> 
 <Channel>Lync Server</Channel> 
 <Computer>Branch-SBA.kcdemo.local</Computer> 
 <Security /> 
 </System> 
 <EventData> 
 <Data>Branch-SBA.kcdemo.local</Data> 
 <Data>504 Cannot connect to gateway. Socket error: ConnectionRefused</Data> 
 <Data>961ebe754b964b55bf9aa3085202ce43</Data> 
 <Data>1</Data> 
 <Data>5/31/2011 5:43:28 PM</Data> 
 </EventData> 
</Event>

Recovered Gateway

The following are Event Viewer messages that appear when the Lync Mediation service recovers from a primary PSTN gateway outage.

Figure 12 – Event Viewer Log

Log Name: Lync Server Source: LS Outbound Routing

Date: 5/31/2011 5:44:33 PM

Event ID: 46027

Task Category: (1038)

Level: Information

Keywords: Classic

User: N/A

Computer: Branch-SBA.kcdemo.local

Description:

A PBX gateway is now responding to requests after some failures.

Gateway name: Branch-SBA.kcdemo.local, Number of failures seen 1

Event Xml:

<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>

<System>

<Provider Name=”LS Outbound Routing” />

<EventID Qualifiers=”17422″>46027</EventID>

<Level>4</Level>

<Task>1038</Task>

<Keywords>0×80000000000000</Keywords>

<TimeCreated SystemTime=”2011-05-31T22:44:33.000000000Z” />

<EventRecordID>3801</EventRecordID>

<Channel>Lync Server</Channel>

<Computer>Branch-SBA.kcdemo.local</Computer>

<Security />

</System>

<EventData>

<Data>Branch-SBA.kcdemo.local</Data>

<Data>1</Data>

</EventData>

</Event>

Log Name: Lync Server 
Source: LS Mediation Server 
Date: 5/31/2011 5:44:34 PM 
Event ID: 25038 
Task Category: (1030) 
Level: Information 
Keywords: Classic 
User: N/A 
Computer: Branch-SBA.kcdemo.local 
Description: 
Mediation Server is able to reach the Gateway Branch-SBA.kcdemo.local 
Event Xml: 
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
 <System> 
 <Provider Name="LS Mediation Server" /> 
 <EventID Qualifiers="17414">25038</EventID> 
 <Level>4</Level> 
 <Task>1030</Task> 
 <Keywords>0x80000000000000</Keywords> 
 <TimeCreated SystemTime="2011-05-31T22:44:34.000000000Z" /> 
 <EventRecordID>3802</EventRecordID> 
 <Channel>Lync Server</Channel> 
 <Computer>Branch-SBA.kcdemo.local</Computer> 
 <Security /> 
 </System> 
 <EventData> 
 <Data>Branch-SBA.kcdemo.local</Data> 
 </EventData> 
</Event>

What?!?! How to Correct Audio Playing Through Speakers Instead of a Lync Certified Headset

One of the items I love about Microsoft Lync is the fact that I can plug my Lync certified headset (Plantronics Blackwire C420) into my laptop and instantly begin using it to make and receive telephone calls. This morning, I plugged my headset in to join a Lync Online Meeting and the audio started playing through my laptop speakers. As much as my colleagues love listening to me ramble, I thought I should try to resolve the issue…

If you by chance run into a similar experience, below are a few steps that should help resolve the headset speaker issue:

  • Open the Lync client
  • Near the lower left-hand corner of the Lync client, ensure the headset icon appears
    • If the headset icon isn’t selected, the headset may simply need to be set as the primary device. In my case, the Plantronics headset was already the primary device.
  • Click the headset icon and select Audio Device Settings

  • If a Lync certified headset is used, the device name should automatically appear as the primary audio device. Again, in my case the Plantronics headset was already the primary device.

  • Everything looks correct in the Lync client… Time to look at the main OS Sound settings
  • Navigate to Start | Control Panel | Sound
    • You may have to select small icons near the upper right-hand corner

  • Under the Playback tab, locate the Lync certified headset speaker
  • In my case, the headset lost it’s association to be the default speaker for audio
  • To correct the issue, simply click the Set Default button
  • Click OK

  • To test the setting, unplug the Lync certified headset and ensure the setting switches back to the Speakers/Headphones

  • Now, plug the Lync certified headset back in and ensure the setting switches to the Lync certified headset

  • Before making an Enterprise Voice call, let’s use the new Audio Test Service introduced in Lync Server 2010 to A) make sure we can hear the audio with the headset and B) check the quality of our voice
  • Open the Lync client
  • Near the lower left-hand corner of the Lync client, ensure the Lync certified headset appears
  • Click the headset icon and select Check Call Quality

  • Alternatively, click the telephone icon and then click the Check button

  • The Audio Test Service should start. Simply listen to the nice lady and you should be good to go!

Comments Welcomed!

How to Quickly Find a Duplicate Telephone Number Assignment

Have you ever tried enabling a user for Enterprise Voice or Exchange Unified Messaging and received an error stating the action could not be completed due to a duplicate record? I’ve surprisingly ran into this issue more than once recently. Whether a telephone number was used for testing purposes and simply forgotten about or caused by inaccurate documentation, below are a few tips to quickly identify a duplicate telephone number in Lync Server 2010 and Exchange 2010 Unified Messaging.

Lync Server 2010

Lync Management Shell

To use the Lync Server Management Shell, follow the steps below:

  • Navigate to Start | All Programs | Microsoft Lync Server 2010 | Lync Server Management Shell
  • Once the shell loads, enter the command below (replacing LineURI and PrivateLine with the duplicate telephone number in question):

Get-CsUser | where {$_.LineURI -eq “tel:+13121115555″ -or $_.PrivateLine -eq “tel:+13121115555″} | format-table -property displayname,LineURI,privateline

The output should appear similar to the screenshot below:

Lync Server Control Panel

To use the Lync Server Control Panel, follow the steps below:

  • Navigate to Start | All Programs | Microsoft Lync Server 2010 | Lync Server Control Panel
  • Once the control panel loads, select the Users option
  • Click +Add Filter
  • Select Line URI from the dropdown list
  • Select Equal To from the dropdown list
  • Enter the duplicate telephone number in E.164 format (e.g. tel:+13121115555)
  • Click Find

The output should appear similar to the screenshot below:

 

Exchange 2010

Exchange 2010 Management Shell

To use the Exchange 2010 Management Shell, follow the steps below:

  • Navigate to Start | All Programs | Microsoft Exchange Server 2010 | Exchange 2010 Management Shell
  • Once the shell loads, enter the command below (replacing XXXX with the extension in question):

get-ummailbox | where {$_.Extensions -eq “XXXX”} | format-table -property displayname,Extensions,PhoneNumber

The output should appear similar to the screenshot below:

Exchange 2010 Management Console

To use the Exchange 2010 Management Console, follow the steps below:

  • Navigate to Start | All Programs | Microsoft Exchange Server 2010 | Exchange 2010 Management Console
  • Once the console loads, navigate to Recipient Configuration | Mailbox
  • Click Create Filter
  • Select E-Mail Addresses
  • Select Contains
  • Enter the duplicate extension and click Apply Filter

The output should appear similar to the screenshot below:

Comments Welcomed!

Survivable Branch Appliance Installation and Cannot Open Database “xds” Requested by the Login

Recently, I had the pleasure of deploying a new Lync Survivable Branch Appliance (SBA) at a customer site. If you’re unfamiliar with SBA functionality, a SBA’s primary function is to provide voice resiliency in office locations where direct internet connectivity to the main data center/central site is lost. I won’t go on and on about the SBA feature set, so additional information can be found here.

Each SBA manufacturer (AudioCodes, Dialogic, HP, and NET) has their own flavor of initial installation steps to get the SBA at an operational state. The one configuration point that this blog will call out is the Configure Domain step. Typically, the manufacturer guides call for manually creating a new computer object in Active Directory and then later joining the SBA to the domain via the SBA configuration webpage (http://x.x.x.x/sbastartup). A screenshot of this option is below:

Taking a closer look, the actual SBA code runs on top of a Windows 2008 R2 instance. A few administrators out there might decide to simply join the SBA to the domain through normal computer membership as seen below:

If the SBA is joined to the domain through the computer membership option, the green checkbox next to Configure Domain in the SBA configuration webpage will not appear (as seen above). The lack of the checkbox does not necessarily represent an issue and the SBA configuration can continue as normal. After the Configure Domain task, the administrator must install the Lync software and synchronize the Lync configuration files. The Install Lync Software option should complete as normal as shown below:

As soon as the Synchronize Lync Configuration Files option is selected, the task will most likely fail with the following error in the Event Log:

sync: Import-CsConfiguration : Cannot open database “xds” requested by the login. The login failed.

Login failed for user ‘KCDEMOlyncsbaadminaccount’.

At line:1 char:228

+ Import-Module -name ‘C:Program FilesCommon FilesMicrosoft Lync Server 2010ModulesLyncLync’; $global:__CsImpersonationMode = [Microsoft.Rtc.Management.ImpersonationMode]‘SurvivableBranchAppliance’; Import-CSConfiguration <<<< -Verbose -LocalStore -FileName ‘C:WindowstempsbaRepData1250401836.zip’ ; exit

;

+ CategoryInfo : NotSpecified: (:) [Import-CsConfiguration], SqlConnectionException

+ FullyQualifiedErrorId : Microsoft.Rtc.Common.Data.SqlConnectionException ,Microsoft.Rtc.Management.Xds.ImportConfigurationCmdlet

As described above, if the SBA was joined to the domain through the computer membership option then the login error above is directly related to the RTCUniversalSBATechnicians security group missing from the Local Administrators group on the SBA. To resolve the issue, follow the steps below:

  • Click the Windows Start button
  • Right-click My Computer and select Manage
  • Expand Local Users and Groups and select Groups
  • Once the security groups appear, double-click Administrators
  • Click the Add button
  • Enter the RTCUniversalSBATechnicians and click Check Names
    • Ensure that the Lync SBA technician account has been added to the RTCUniversalSBATechnicians security group in Active Directory

  • Click OK twice
  • Log out of the SBA configuration interface (http://x.x.x.x/sbastartup)
  • Log back into the SBA configuration interface (http://x.x.x.x/sbastartup) using the same SBA technician account

After logging back into the SBA configuration interface, the Synchronize Lync Configuration Files step should complete successfully!

Comments Welcomed.

Troubleshooting Lync Edge, XMPP Gateway, and TLS Negotiation Errors

There is plenty of documentation out there on how to install the XMPP gateway with OCS or Lync (references provided at the bottom of this post). This blog will not focus on the installation of the XMPP Gateway, but rather what to do if you receive TLS errors on the Lync Edge server when communicating to the XMPP gateway.

If TLS issues pop up on the Lync Edge server, odd behavior could be experienced with Gmail such as complete instant messaging failure, one-way instant messages, and/or unknown presence.

If you open the Event Viewer on the Lync Edge server, you may notice connection failures similar to the error below.

A significant number of connection failures have occurred with remote server lyncxmpp.internaldomain.com IP 172.X.X.X. There have been 94 failures in the last 383 minutes. There have been a total of 1750 failures.

The specific failure types and their counts are identified below.

Instance count – Failure Type

14 0x8007274D(WSAECONNREFUSED)

1735 0×80072746(WSAECONNRESET)

1 0x8007274C(WSAETIMEDOUT)

This can be due to credential issues, DNS, firewalls or proxies. The specific failure types above should identify the problem.

If you start a logging trace on the Lync Edge server, you may notice a series of failures similar to the errors below.

TL_ERROR(TF_CONNECTION) [1]1190.1478::01/13/2011-15:50:15.384.0006baa0 (SIPStack,SIPAdminLog::TraceConnectionRecord:SIPAdminLog.cpp(160))$$begin_record

LogType: connection

Severity: error

Text: Receive operation on the connection failed

Local-IP: 172.X.X.100:61378

Peer-IP: 172.X.X.110:5061

Peer-FQDN: lyncxmpp. internaldomain.com

Peer-Name: lyncxmpp.internaldomain.com

Connection-ID: 0x1AC102

Transport: M-TLS

Result-Code: 0×80072746 WSAECONNRESET

Data: fqdn=”lyncxmpp.internaldomain.com”;peer-type=”FederatedPartner”;winsock-code=”10054″

$$end_record

TL_ERROR(TF_DIAG) [1]1190.1478::01/13/2011-15:50:15.385.0006bad2 (SIPStack,SIPAdminLog::TraceDiagRecord:SIPAdminLog.cpp(143))$$begin_record

LogType: diagnostic

Severity: error

Text: Message was not sent because the connection was closed

SIP-Start-Line: NOTIFY sip:LYNCXMPP.internaldomain.com:5061 SIP/2.0

SIP-Call-ID: 059f6d06c4e84676ac28bfce083f779b

SIP-CSeq: 6 NOTIFY

Peer: lyncxmpp.internaldomain.com:5061

$$end_record

TL_INFO(TF_DIAG) [1]1190.1478::01/13/2011-15:50:15.385.0006bd42 (SIPStack,SIPAdminLog::TraceDiagRecord:SIPAdminLog.cpp(147))$$begin_record

LogType: diagnostic

Severity: information

Text: Response successfully routed

SIP-Start-Line: SIP/2.0 504 Server time-out

SIP-Call-ID: 059f6d06c4e84676ac28bfce083f779b

SIP-CSeq: 6 NOTIFY

Peer: lyncpool01.internaldomain.com:60148

Data: destination=”lyncpool01.internaldomain.com”

$$end_record

TL_INFO(TF_PROTOCOL) [1]1190.1478::01/13/2011-15:50:15.385.0006bd87 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(125))$$begin_record

Trace-Correlation-Id: 69086622

Instance-Id: 00049CDB

Direction: outgoing;source=”local”;destination=”internal edge”

Peer: lyncpool01.internaldomain.com:60148

Message-Type: response

Start-Line: SIP/2.0 504 Server time-out

From: <sip:user1@internaldomain.com>;tag=714DBB6A

To: <sip:jdoe@gmail.com>;tag=ef5ee6c3d6

CSeq: 6 NOTIFY

Call-ID: 059f6d06c4e84676ac28bfce083f779b

Via: SIP/2.0/TLS 10.50.1.18:60148;branch=z9hG4bKEC9CA19E.667CA4AB371EBB65;branched=FALSE;ms-received-port=60148;ms-received-cid=1A2A00

ms-diagnostics: 1047;reason=”Failed to complete TLS negotiation with a federated peer server”;WinsockFailureCode=”10054(WSAECONNRESET)”;WinsockFailureDescription=”The peer forced closure of the connection”;Peer=”lyncxmpp.internaldomain.com”;Port=”5061″;source=”sip.internaldomain.com”

Server: RTC/4.0

Content-Length: 0

ms-edge-proxy-message-trust: ms-source-type=EdgeProxyGenerated;ms-ep-fqdn=lyncedge.internaldomain.com;ms-source-verified-user=verified

Message-Body:

$$end_record

TL_WARN(TF_DIAG) [1]1190.1478::01/13/2011-15:50:15.385.0006bdd6 (SIPStack,SIPAdminLog::TraceDiagRecord:SIPAdminLog.cpp(145))$$begin_record

LogType: diagnostic

Severity: warning

Text: Routing error occurred; check Result-Code field for more information

Result-Code: 0xc3e93c7f SIPPROXY_E_ROUTING_MSG_SEND_CLOSED

SIP-Start-Line: NOTIFY sip:LYNCXMPP.internaldomain.com:5061 SIP/2.0

SIP-Call-ID: 059f6d06c4e84676ac28bfce083f779b

SIP-CSeq: 6 NOTIFY

Peer: lyncxmpp.internaldomain.com:5061

$$end_record

If similar TLS errors appear on your Edge server, ask yourself “Is my XMPP gateway installed on a Windows 2008 or Windows 2008 R2 server.” If XMPP is installed on Windows 2008 R2, various compatibility patches will need to be applied. The XMPP application is an OCS 2007 R2 server role and all OCS 2007 R2 services need various Microsoft patches in order to function correctly on Windows 2008 R2.

The following is the list of updates that should resolve the TLS errors between the XMPP and Lync Edge server:

Once the TLS errors are resolved, if presence unknown still appears and/or inbound instant messages continue to fail, you may want to reference the following links:

Finally, if you’re not familiar with the XMPP Gateway installation process, I’ve provided a few links below:

Comments Welcomed!