Lync 2013 Client and Group Chat 2010–Co-existence Issue

An interesting co-existence problem came up yesterday. It appears that there is a known issue with the Lync 2010 client and Windows 8, where it is possible to fire off multiple instances of communicator.exe, which then causes the Lync 2010 client not to even launch.

Well, the Lync 2013 client has some new coding that prevents multiple instances from starting. Now, this is a bit interesting because, in the past, OCS/Lync clients have never been backwards compatible. In case of Lync 2013, it does work with Lync 2010. Until… you add in Group Chat 2010 in the mix.

The Lync 2013 client will, as a single client, work with Lync Server 2013 and Persistent Chat. One of the nice selling points is that running 2013 means reducing the need for a separate chat client.

Well, the thought was, why not deploy Lync 2013 to connect to Lync Server 2010, andclip_image002 continue using the Group Chat 2010 client to connect to the Group Chat server? Well, the answer is that the Group Chat 2010 client doesn’t recognize that the Lync 2013 client is running and this causes the Group Chat 2010 client to not only display all rooms, but also display all contacts as shown here. Yes, I had to hack this one up to protect the innocent. Smile

Anyway, as you can see from the image, it is possible to send/receive IMs in the Group Chat 2010 client, even though the Lync 2013 client is also running. What is the answer? I have no idea…

Posted in Lync | Leave a comment

Generate a Simple Group Chat Report

I get all sorts of odd, and fun, requests. Recently, I was asked to provide a quick and dirty report on which users are configured for Group Chat and to list the rooms they can join.

I really don’t want to get too good at this SQL stuff, but this one was good fun.

$SQLQuery = “SELECT isMember,isManager,prinID,prinName,prinDisabled,nodeName,nodeDesc,disabled,visibility

FROM [GroupChatDB].[dbo].[Exp_RoleView]

       INNER JOIN [GroupChatDB].[dbo].[tblPrincipal] on Exp_RoleView.principalId=tblPrincipal.prinGuid

           INNER JOIN [GroupChatDB].[dbo].[tblPrincipalType] on tblPrincipal.prinTypeID=dbo.tblPrincipalType.ptypeID

           INNER JOIN [GroupChatDB].[dbo].[tblNode] on Exp_RoleView.nodeDbId=tblNode.nodeID

      ORDER BY prinName”


$Connection = new-object

$Connection.connectionString=”Data Source=VSQLNCSB0010CDC\N1SQL01;Initial Catalog=GroupChatDB;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 ConnectionList.csv -notype


$Connection = $null


Posted in Uncategorized | 1 Comment

Changing the Lync Conference ID

I had an unusual request, earlier today. The user was worried that somebody was joining their Lync conferences, anonymously, and they wanted to change their conference ID.

I have never done that before, but found out it is pretty easy to do.

First, go to, and it will take you to the Dial-in Conference Settings and PIN Management page, as shown here.



Then, after you click the Sign In link, it will take you to this screen. You can either click the Sign In button, and it will use your current credentials, or you can click the Sign in with a different account link and use those credentials.


If you don’t have a PIN already set, you will be prompted for a PIN, otherwise, go to the section for Assigned Conference Information section and click on the Reset my Assigned Conference Information link, and it will create a new conference ID for you.



Posted in Uncategorized | 1 Comment

Undoing RCC and Enterprise Voice Client Side Settings


I use my Lync client to dial a call. It might be as an RCC client or an Enterprise Voice client.

For example, I call my boss using RCC for a 1:1 meeting, but since I am never allowed to actually talk, I just put him on speaker phone and listen to him pontificate on how wonderful I am, but I am still not going to get an awesome raise.

When I am on the call with him, I get the nice little window generated by Lync with the call status.

In the meantime, somebody important calls me via a Lync call (we need to decide where to go for lunch, for example). I want to close the window for the call (not put it on hold, just in case the boss might actually ask me an important question while he talks on and on) and keep my call running on my phone device so I can leave it running on speakerphone in the background. So, I close the window.


I get the prompt:

Do you want to end the call when you close this window?

If you answer No, the window will close, but the call will continue on your audio device.

There is a nice check box that I can enable to Always end the call without asking, and I enable the check box and click No.

So, if I enable the check box and click on No, I never get the prompt again.


How can I get the prompt back?


The registry is your friend, in this case. All of the RCC and Enterprise Voice settings can be found in the DS key here:


It is actually nice to know, if you delete the entire key and it will reset you to the default settings and remove all of the odd changes that you might have made in the past.


Posted in Uncategorized | Leave a comment

Access is Denied During Lync Installation

I remember in my first Windows class, yes, it was Windows NT Server 3.5. My trainer said, multiple times, that every time you see “Access is Denied” it is a permissions issue. I took it with a grain of salt, but I haven’t seen it to not be true, yet.

I was working on an installation and ran into this error. I had set up the installation account as a domain administrator, and had already done the Schema and Forest pieces of the installation without any issues. The installation account was also configured as a local administrator on the server. So, it was a shock to me when I saw the error.

Error: Active Directory operation failed on “ServerNameFQDN”. You cannot retry this operation: “Access is denied 00000005: SecErr: DSID-0315121D0, problem 4003 (INSUFF_ACCESS_RIGHTS), data0″

The answer?

Yes, I didn’t have permissions. Somebody else decided that my account didn’t need to be a Domain Admin and took away the rights.

So, there are two ways to move forward. Either make the account a Domain Admin, or have somebody delegate the required permissions to the OU and domain for the account. is the perfect place to get the right info.



Posted in Uncategorized | 1 Comment

Migration of Edge Server Environment Failure

I have done migrations several times in the past, and the final step of migrating the edge environment has never seemed too challenging. Microsoft has a nice TechNet article on this subject. It has a nice step-by-step process. There are also lots of great articles out there written by my colleagues. It is a well-known process. Well, you would think it is, at least.

In this instance, I failed twice. I figured I was missing something that was different in this case.

Situation: Federation is working using the OCS Edge environment with the Lync 2010 servers. The new Lync Edge servers were installed in the same network segment as the OCS Edge servers, and the firewall rules were all in place, tested, re-verified, and tested again. The certificates were verified multiple times.

Next try: So, not trusting myself, and it being clear that I didn’t know what I didn’t know, I engaged a well-known Microsoft PFE with years of experience. We worked through the process together. We failed. We both researched over and over looking for something that we missed.

This Try: Yep, you guessed it, we failed again. I hated to have to do it, but I called PSS. I hate doing it for a few reasons, but I have to admit it was the best solution in this case. J

Anyway, in our troubleshooting, we were getting really frustrated because each time we ran the Test-CsFederatedPartner cmdlet, we would get an almost immediate response as shown here:

PS C:\ > Test-CsFederatedPartner -targetfqdn -domain

Test-CsFederatedPartner : A 504 (Server time-out) response was received from the network and the operation failed. See the exception details for more information.

At line:1 char:24

+ Test-CsFederatedPartner <<<<  -targetfqdn -domain

    + CategoryInfo          : OperationStopped: (:) [Test-CsFederatedPartner],


    + FullyQualifiedErrorId : WorkflowNotCompleted,Microsoft.Rtc.Management.Sy


This was a pretty worthless response. So, we used the Lync Logging Tool and tried to capture what was going on at the Lync Edge servers. We were not catching anything of value at all there either. In fact, we weren’t getting any errors at all. It was killing us.

I fired off snooper on my client machine, and I did finally find something worth reviewing as shown here:

07/11/2014|17:00:40.363 1AA0:1094 INFO  :: Data Received – (To Local Address: 735 bytes:

07/11/2014|17:00:40.363 1AA0:1094 INFO  :: SIP/2.0 504 Server time-out

Authentication-Info: TLS-DSK qop=”auth”, opaque=”2F0B06CC”, srand=”22152E76″, snum=”2429″, rspauth=”216b4f7de55af7427567d4600c6c1cc0ed0424bf”, targetname=””, realm=”SIP Communications Service”, version=4

Via: SIP/2.0/TLS;ms-received-port=49723;ms-received-cid=2B900

Content-Length: 0

From: “Kaufmann, Russ”<>;tag=ad9fb18754;epid=9eb3bb686d

To: <>;tag=A6FA5C39AA3A033D325BDEEC514F6F83

Call-ID: 413e1caad3a74d7d895e246cd800da32


ms-diagnostics: 1065;reason=”Federation is disabled”;domain=””;source=””

Server: RTC/4.0


07/11/2014|17:00:40.363 1AA0:1094 INFO  :: End of Data Received – (To Local Address: 735 bytes

Ah ha! Federation is disabled. A clue. Wait, though. Everything worked before, and all we did was reconfigure the route. In fact, we verified that the Media was traveling across the new Lync Edge servers before we even started. All we needed to do was move the Federation route. How could it be disabled? Well, a quick search of 1065;reason=”Federation is disabled”;domain=”othercompany took us to Pat Richard’s blog. It pointed out a possible issue with a security policy. By the time we read this post, it was clear that it wasn’t the issue.

Enter PSS: First, we were shamed by the PSS rep. He knew of both of us and was shocked that we couldn’t handle something so easy. Three minutes later, we had the answer. Yes, I felt stupid, but it was at least a quick call and it was kind of fun to be told that I should be ashamed of myself by a PSS rep. J   

Yes, I forgot to set the policy.


Posted in Uncategorized | 1 Comment

Identifying Federation Enabled Users, Including PIC

Microsoft had an agreement with Yahoo, AOL, and itself (Skype and Live Messenger) that enabled organizations to utilize Public IM Connectivity (PIC) to send instant messages between Lync environments and the PIC environments. Microsoft announced that they were going to discontinue their agreements with Yahoo and AOL and the last day is to be June 30, 2014.

June 30, 2014 is almost here.

I am working with AOL on a direct federation agreement. The entire process is extremely painful, and pretty expensive. AOL has set a minimum contract price of $14,400 per year to continue federation. Between legal and security issues, the process of coming to an agreement is a major challenge.

Which takes me to my issue. I had to find out which users are currently connecting to AOL and let them know that there might be an outage as contract negotiations with AOL are going pretty slowly and are not likely to be resolved soon. I expect an outage.

So, how to proceed… There are a couple of ways to look at this.

1. Just identify all users that have been authorized to use PIC. That is pretty easy, using a simple Lync PowerShell script, as shown here:

Get-CsUser | Where ($_.ExternalAccessPolicy –ilike “*Public*”} | Select SipAddress

2. The second way is a good bit more complex. Identify everyone that is actually using PIC to connect to AOL users, and identify the AOL account destinations for the IM conversations. I am sure there is a better way to do this, and I have asked Pat Richard to take a look at this and then write a much more efficient script. The nice thing about this script is that it can be easily modified to identify users that are communicating to specific Federated domains.

The second method provides more accurate data. Of course, it now requires that we query data out of the LcsCDR database. There will be some duplication when it comes to identifying the users that are using Lync to connect to AOL and the accounts that they connect to at AOL, but that is easy to clean up in Excel. You can download it here.

$SQLQuery = “Select





       U.UserUri ‘User1URI’,

       UU.UserUri ‘User2URI’,


From SessionDetails S

Inner join Users U on S.User1Id = U.UserId

Inner join Users UU on S.User2Id = UU.UserId

WHERE S.IsUser1Internal = 0 OR S.IsUser2Internal = 0

Group by








$connection = new-object

$Connection.connectionString=”Data Source=SqlServerFqdn\InstanceName;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 FederationActivity.csv -notype


$connection = $null

$Results = Import-Csv FederationActivity.csv

$Null | Out-File FederationActivityResults.csv

$Header = “User1″ + “,” + “User2″ + “,” + “Time”

$Header | Out-File FederationActivityResults.csv

ForEach ($r in $Results){

               $User1 = $r.User1URI

               $User2 = $r.User2URI

               $Time = $r.SessionIdTime

               If($User1 -imatch “” -or $User2 -imatch “”){

                              #Write-Host “User1’s URI is $User1 and User2’s URI is $User2″

                              $Entry = “$User1″+”,”+”$User2″+”,”+”$Time”

                              Write-Host $Entry

                              $Entry | Out-File FederationActivityResults.csv -Append



Posted in Lync | 1 Comment