Getting Lync User Connection Information

I posted in the past about how to identify where users are connecting to in Lync. I have used this script several times this week to find out what version users were using and what computer they were using. The troubleshooting process is a great deal easier when you don’t have to depend on users to give you the information.

I spent some time adding to the previous script and added an nslookup to get the client computer name along with the IP, and then I added some historical logon information.

Between the two pieces of the script, I ended up using the local SQL on Front-End servers and then the LcsCDR database. It was actually a fun couple of hours of testing and playing.

You can download the latest script here, or you can read it and take what you want as shown below, and then modify it as needed to fit your environment. At the very bottom of this post is an example of the output.

# User Name to Search
$User = “”
# SQL Server for historical connection information
$SqlServer = “SqlServerName\InstanceName”

Write-Host ” “
Write-Host “Retrieving Current Lync Client Connections for $User” -foregroundcolor red
#Find the Front-End server that is supposed to be used by the user
$FirstPriority = Get-CsUserPoolInfo $User | Select –ExpandProperty PrimaryPoolMachinesInPreferredOrder | Select fqdn -First 1
# The SQL server in this next variable is for the SQL express on the Front-End
$ServerName = $FirstPriority.fqdn

# This query is for the SQL Express to get current connection information
$SQLQuery = “
    From RegistrarEndpoint
    WHERE SipHeaderFrom LIKE ‘%$User%'”
$Connection = New-Object
$Connection.connectionString=”Data Source=$ServerName\RTCLOCAL;Initial Catalog=RTCDyn;Integrated Security=SSPI”
$Command = $Connection.CreateCommand()
$Command.Commandtext = $SqlQuery
$DataAdapter = New-Object System.Data.SqlClient.SqlDataAdapter $Command
$Dataset = New-Object System.Data.Dataset
# $Dataset.Tables[0] | Export-CSV UserIP.csv -notype
$Connection = $null

$Results1 = $dataset.tables[0].rows

ForEach ($r in $Results1){

    If ($r.IsServerSource -ne “False”){
        $ClientApp = $r.ClientApp
        $ContactInfo = $r.ContactInfo
        $SipHeaderFrom = $r.SipHeaderFrom
        $EncodingType = “System.Text.ASCIIEncoding”
        $Encode = new-object $EncodingType
        $ClientApp = $Encode.GetString($ClientApp)
        $ContactInfo = $encode.getstring($ContactInfo)
        $SipHeaderFrom = $encode.getstring($SipHeaderFrom)
        # Strip garbage from $ContactInfo to get IP
            $CI = $ContactInfo.split(‘;’)
            $CI2 = $CI[0]
            $CI3 = $CI2.split(‘:’)
            $ClientIp = $CI3[1]
        #Strip garbage from $Sip User to get SIP address in SMTP format
            $Sip = $SipHeaderFrom.split(‘:’)
            $Sip2 = $Sip[1]
            $Sip3 = $Sip2.split(‘>’)
            $SipAddress = $Sip3[0]
        #Find computer name
            $Name = nslookup $ClientIp
            ForEach ($n in $Name){
                If($n -ilike “name*”){
                    $Name = $n.split(‘ ‘)
                    $Name2 = $Name[4]
                    $Name3 = $Name2.split(‘.’)
                    $CompName = $Name3[0]
        Write-host “UserURI         : $SipAddress”
        Write-host “IPAddress       : $ClientIp”
        Write-Host “ComputerName    : $CompName”
        Write-host “Version         : $ClientApp” 

    Write-Host ” “

Write-Host ” “
Write-Host “Retrieving Recent Lync Client Connections for $User” -foregroundcolor red

# The second query is used to get recent connection information, changing to TOP 10 or more will retrieve more results
$SQLQuery = “
    s.ServerFQDN as Server,
    p.PoolFQDN as Pool
FROM Registration as r
    JOIN Users as u on r.UserId = u.UserId
    JOIN ClientVersions as v on r.ClientVersionId = v.VersionId
    JOIN Servers as s on r.RegistrarId = s.ServerId
    JOIN Pools as p on r.PoolId = p.PoolId
WHERE u.UserUri = ‘$User’
ORDER BY r.RegisterTime DESC”

$Connection = new-object
$Connection.connectionString=”Data Source=$SqlServer;Initial Catalog=LcsCDR;Integrated Security=SSPI”
$Command = $Connection.CreateCommand()
$Command.Commandtext = $SqlQuery
$DataAdapter = New-Object System.Data.SqlClient.SqlDataAdapter $Command
$Dataset = New-Object System.Data.Dataset
# $Dataset.Tables[0] | Export-CSV TempList.csv -notype
$Connection = $null

$Results2 = $Dataset.Tables[0].rows


I played with the output a bit to make it all align. Basically, what you get is the first section of the output shows the two locations where I was currently logged in at the time I ran the script. The second part shows the last five logons. The number can easily be changed in the script by modifying the TOP 5 part of the SELECT statement.

Retrieving Current Lync Client Connections for
UserURI         :
IPAddress       :
ComputerName    : Desktop1
Version         : UCCAPI/15.0.4675.1000 OC/15.0.4675.1000 (Microsoft Lync)

UserURI         :
IPAddress       :
ComputerName    : Desktop2
Version         : UCCAPI/15.0.4675.1000 OC/15.0.4675.1000 (Microsoft Lync)

Retrieving Recent Lync Client Connections for

UserUri        :
RegisterTime   : 2/24/2015 6:12:58 PM
DeRegisterTime : 2/24/2015 6:13:30 PM
Version        : UCCAPI/4.0.7577.4409 GCAT/4.0.7577.4398
Server         :
Pool           :

UserUri        :
RegisterTime   : 2/24/2015 6:05:35 PM
DeRegisterTime : 2/24/2015 6:06:08 PM
Version        : UCCAPI/4.0.7577.4409 GCAT/4.0.7577.4398
Server         :
Pool           :

UserUri        :
RegisterTime   : 2/24/2015 6:05:14 PM
DeRegisterTime : 2/24/2015 6:14:40 PM
Version        : UCCAPI/4.0.7577.4409 GCC/4.0.7577.4398
Server         :
Pool           :

UserUri        :
RegisterTime   : 2/24/2015 2:19:49 AM
DeRegisterTime : 2/24/2015 2:28:02 AM
Version        : UCCAPI/4.0.7577.0 GCAT/4.0.7577.0
Server         :
Pool           :

UserUri        :
RegisterTime   : 2/23/2015 7:15:11 PM
DeRegisterTime :
Version        : UCCAPI/15.0.4675.1000 OC/15.0.4675.1000 (Microsoft Lync)
Server         :
Pool           :

Posted in Lync | Leave a comment

Lync 2010 vs Lync 2013 Address Book Troubleshooting

When troubleshooting Address Book issues in Lync, I keep forgetting to ask users which version of the Lync client they are using. After all, it is a bit of a pain if you walk them through deleting their Global Address List files and setting the GalDownloadInitialDelay setting in the Registry just to find out that you did all the work for the wrong version.

So, just a reminder to everyone, make sure you do the work in the right areas for users based on the version of the client that they are currently using. When trying to make sure that they have the proper Address Book, you need to go through four steps:

  1. Update the Address Book from the server side by running:  Update-CsAddressBook
  2. Exit Lync and then delete the GalContacts.db and GalContacts.db.idx files
  3. Configure the Registry on the client so it will immediately download the new Address Book
  4. Restart the Lync client and verify that everything is happy again

For example, for Lync 2010:

The location for the Gal* files is C:\Users\%username%\AppData\Local\Microsoft\Communicator

The location for the GalDownloadInitialDelay in the Registry is HKLM\Software\Policies\Microsoft\Communicator (create the DWORD for GalDownloadInitialDelay and set it to 0)

For example, for Lync 2010:

The location for the Gal* files is C:\Users\%username%\AppData\Local\Microsoft\Office\15.0\

The location for the GalDownloadInitialDelay in the Registry is HKLM\Software\Policies\Microsoft\Office\15.0\Lync (create the DWORD for GalDownloadInitialDelay and set it to 0)

Jeff Schertz does a great job explaining the details for Lync 2010 on his blog:

Remember, to modify the locations for Lync 2013 and it is pretty much the same thing. I highly suggest reading Jeff’s blog as he does an awesome job of explaining the process and verifing that the Update-CsAddressBook was successful.

Posted in Lync | 1 Comment

Lync Web Access for Anonymous Users–Failure

In my current job, I have been using Federation connections for many Lync meetings. My meetings include internal company participants and external participants that are Federated. I love having Lync meetings, and just making Lync phone calls to external users. Presence, Instant Messaging, Desktop and Application sharing and Audio and Video connects all work perfectly.

I was tasked with making sure that we can add external anonymous users. Of course, that should not be an issue. However, during testing, I found that there were many issues. I was able to get some anonymous users connected and send and receive Instant Messages. Well, it appeared to work, but there seemed to be some intermittent issues.

Anonymous users were complaining that they had to try multiple times to make the connection to the Lync conference and that they kept losing their connections. After doing some extensive testing, I was finally able to get some captures of the errors. Anonymous users were receiving errors like the one below when trying to join as a guest:clip_image002

The connection to the server was lost. Check your network connection and try again.

After multiple retries, they were able to join the meeting. However, they were not able to view the shared content. After a short time, they were no longer able to participate in clip_image004the IM session, either. You can see, from the reproduction of the error, that the first message was fine, but the second message that was sent a couple of minutes later failed. Obviously, this is not by design. Smile

Now, I fully admit that I am sick person because I was excited to get these screen shots and to have a chance to troubleshoot this issue.

First Steps:

  1. Check the Conferencing Policy. Obviously, the meeting organizer needs to be assigned a policy that allows anonymous users. I verified that that the policy allowed anonymous users and allowed application and desktop sharing.
  2. Cuss at the computer. Cussing is a big part of how I work as an administrator when troubleshooting.

Next Steps:

Try to connect to the meeting using LWA (like an anonymous user) from the same computer where the meeting is initiated. In this case, I was able to reproduce the issue on the internal network. I copied the URL from my meeting to a browser window on my desktop, i.e. and then added the suffix of ?sl=1 to the end of it to force the connection via the browser. The URL used looks like this:

If you don’t add the suffix, then the Lync client will try to connect to the meeting, and the goal here is to test LWA, not the Lync client. 

In this case, the browser connected properly, initially. When clicking the link to Join the meeting using your web browser, it would take me to the next screen where I could select the radio button to Join as a guest.


The same issue appeared and the connection failed. If this had worked, I would have tried using another computer inside the network to see if I could reproduce the issue there as well.

At this point, this looked like an issue with a hardware load balancer. I jumped to this conclusion because I could establish a connection (intermittently) and then would see a failure when trying to send subsequent IMs (which sounds to me like a reconnection to the same session).

Last Steps:

Now, I needed to verify that it was actually an issue with the hardware load balancer.

I used a second computer and configured the hosts file for the address pointing it to a single server in the pool rather than the load balancer’s IP address, and I also did the same with the pool name and set it up in the hosts file as well. Remember, you need to use FQDNs.

Once the hosts file was set up, I retested the LWA connection and it worked like a charm. No issues. I was able to share apps, share the desktop, and IM for an extended length of time. It was rock solid.

So, how did I know for sure it wasn’t a problem with one of the front-end servers in the pool instead of the load balancer? Easy, I just repeated the process for each of the front-end servers by setting the IP for each one in the hosts file and testing the connectivity. Every single front-end worked wonderfully.

Once I removed the hosts file entries, and went back to using the load balancer, it was easy to reproduce the problem. Yep, definitely the hardware load balancer.

Of course, every load balancer is a bit different. In this case, following the guidance of the vendor, the load balancer was reconfigured and the issue was resolved.

Another happy ending in the world of troubleshooting Lync.

Posted in Lync | 1 Comment

Lync Web App and Google Chrome

There was a recent update to Lync Server 2013 (including Lync Server 2013 as found in Office 365) that included a new error page for Chrome users.

It appears that Google dropped support for some older APIs that have been deprecated in Chrome. The APIs were for QuickDraw and Carbon.

While I have not had the experience of seeing the error page, I have heard that is reads:

Lync Web App

Google Chrome no longer supports Lync Web App

To join the meeting:

1. Copy the meeting URL

2. Open Internet Explorer or Firefox

3. Past the URL in address bar, and hit Enter

UPDATE (Dec 15, 2014): Microsoft posted something on this issue last night.

And another UPDATE today (Dec 17, 2014):

Posted in Uncategorized | Leave a comment

Skype for Business

In case you missed the announcement, Lync is being rebranded.

In the first half of 2015, Skype for Business will be released. An updated server component, new features for the on-premises, hybrid, and cloud versions will be released, and a new client will be released for business users. It will be an interesting time.

Read more at the Microsoft Office Blog.

For those that are into hash tagging, the unofficial hash tag is #skype4b

Keep an eye out on the Microsoft Office Blog for more information as it is released.

Posted in Uncategorized | Leave a comment

POODLE and the Impact on Lync–The Registry Settings

In case you haven’t heard from the many sources out there, not only does SSL 2.0 have multiple vulnerabilities, but SSL 3.0 is also vulnerable. For more information about POODLE and the impact on Lync, check Richard Brynteson’s blog here.

The key to the madness is that we don’t need SSL 2.0 or SSL 3.0, and we should protect ourselves from known vulnerabilities in SSL.

The easy fix is to make a few changes in the registry in Windows and then restart the servers to make sure that SSL 2.0 and 3.0 are not used.

Take the following text, copy it and save the file as a .reg file, and the import it into the registry. Restart the server, and you are done.

Windows Registry Editor Version 5.00


[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]

Or, just download my file here.

Posted in Uncategorized | 1 Comment

OWAS Configuration and -CertificateName

I downloaded my certificate and was working on configuring an Office Web App Server 2013 Farm. As I was running the New-OfficeWebAppsFarm cmdlet, I received an error as I was using Subject Name of the certificate for the –CertificateName option as shown here, along with the results of the command saying that it doesn’t work.

New-OfficeWebAppsFarm -internalurl “” -externalurl “” –certificatename “”

New-OfficeWebAppsFarm : Office Web Apps was unable to find the specified certificate.

At line:1 char:1

+ New-OfficeWebAppsFarm -internalurl “” -externalurl “ht …

+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    + CategoryInfo          : ObjectNotFound: (:) [New-OfficeWebAppsFarm], ArgumentException

    + FullyQualifiedErrorId : CertificateNotFound,Microsoft.Office.Web.Apps.Administration.NewFarmCommand

The option wants the Friendly Name for the certificate, but the certificate didn’t have one. In the Friendly Name field, if you looked at the Certificate by using the Certificates MMC, it showed “<None>” in the field.

The installation docs are pretty clear that it is supposed to be the Friendly Name. Hey, clip_image002what can I say other than, I just wanted to try and see if it would accept another method of identifying the certificate in the store if there isn’t a Friendly Name. So, I tried using several different variations for the Friendly Name. I tried leaving it blank, I tried using a space between quotes, and I tried a few other methods, but none of them worked. It was kind of a bit of fun on my part to see if I could make it work.

Finally, I broke down, and selected the properties of the certificate in the MMC and entered OWAS.  Of course, it worked perfectly when I used that Friendly Name.

Yeah, I could have saved a couple of minutes if I had taken this step earlier, but I really enjoy experimenting.

Posted in Lync | 1 Comment