Update 12/27/14 - Added additional information on the change to Lync Web App.
Update 12/17/14 - Added link to KB article.

After applying the Lync Server 2013 December 2014 Cumulative Update, if a user using Google Chrome tries to use the Lync Web App to join a Lync meeting, they will get the following message:

Google Chrome no longer supports Lync Web App

Google is making multiple changes to the Chrome browser which affect the plug-in used by the Lync Web App (LWA) to provide a rich meeting experience including audio, video, and content sharing from the browser.  These changes include discontinuing 32-bit Chrome support for Mac, and discontinuing support for the so-called "Netscape Plug-in API" (or NPAPI) commonly used by browser plugins.  Microsoft is making changes to the Lync Web App to reduce the impact of these Google changes on our customers.  For now, users will need to use Internet Explorer or Firefox if they would like to join the Lync meeting using Lync Web App.  Additional information can be found here.

I had a customer question the other day that I hadn't seen before.  The issue was that people were noticing that every time when they initiated an IM conversation to a specific user, they would get the following in the IM window:

Context not supported: this conversation includes context which requires a Microsoft Lync plug-in. Please contact your administrator to enable this context.

What was interesting is that it only happens in one direction.  Using the users in the example above, anyone initiating an IM to Judith saw the issue, but if Judith initiated the conversation, the message wasn't displayed in either IM window.  We looked at the trace file from William's Lync client and it shows an INVITE being received by the Lync client with information about an application ID:

Note: You may need to click on the image above in order to read the text.

It turns out that Judith has a Conversation Window Extension (CWE) registered on her machine.  You can learn more about contextual Lync conversations and Conversation Window Extensions here.  This application was only registered on Judith's local machine and not everyone else that was trying to IM her.  If other users had the same application installed, they wouldn't see the message in the IM window.  To figure out what the application was we opened Registry Editor on Judith's computer and navigated to:

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Lync\Addins\{D0C33971-D36C-4063-885A-1CC3E8AF1253}

This shows that the name of the application is "Logi Far End Control":

Looking in Programs and Features shows that Judith installed a plugin from Logitech.  Specifically this plugin is used for far-end camera control for a Logitech webcam:

The user didn't need the far-end camera control plugin installed, so after they uninstalled it users were no longer getting the message in their IM window.

I ran into this issue at a customer recently.  The Lync Server 2013 Deployment Wizard would throw an error while trying to install SQL Server 2012 Express:

Checking prerequisite SqlInstanceRtc...installing...failure code -2067922934
Prerequisite installation failed: SqlInstanceRtc

Clicking on View Log didn't tell us a lot either:

Note: You may need to click on the image above in order to read the text.

Neither did the SQL installation log file, which can be found at C:\Users<username>\AppData\Local\Temp\1\SqlSetup.txt:

Note: You may need to click on the image above in order to read the text.

The only real interesting thing in the log file was:

Process returned exit code: 0x84BE000A

This particular customer uses OS images that have been hardened according to a set of STIGs (Security Technical Implementation Guide).  You can find some more information on STIG here.  In comparing the changes to a default installation of Windows we found that all of the users had been removed from the "Debug programs" policy:

Note: You may need to click on the image above in order to read the text.

The user running the Lync Server 2013 Deployment Wizard needs to be included in order for SQL to be installed.  The default setting includes the local Administrators group:

Note: You may need to click on the image above in order to read the text.

After adding the local Administrators group and rebooting the server, we were able to complete the SQL Server 2012 Express installation and continue on with the Lync Server 2013 install:

If you are installing Lync Server 2013 on an OS that has been hardened, ensure that the user doing the install has all the rights necessary for a smooth installation.

If you've migrated to Lync Server from a previous version of OCS, you may have noticed that you might have an additional simple URL configured.  You can see this in the Lync Server Control Panel under Topology > Simple URL:

Note: You may need to click on the image above in order to read the text.

It shows up as Dialin13.  You can also see it if you run:

Get-CsSimpleUrlConfiguration | Select-Object -ExpandProperty SimpleUrl

This is the dial-in URL that was used in OCS.  So where did this URL come from?  First, the dial-in URL was part of the Communicator Web Access component of OCS.  You can find some additional information in the Ten Things You Might Not Know About the 2007 R2 Release of Communicator Web Access TechNet article.  Specifically you needed to run Step 4 under Deploy Communicator Web Access:

This step published the URLs for Communicator Web Access.  You can find some additional information in the Publishing Communicator Web Access URLs TechNet article.

So when you click on Publish, where does that information get stored?  It is actually stored in two locations.  The first is in WMI on the CWA Server(s):

The second location is in Active Directory.  Specifically in the Global Settings folder under RTC Service:

The two attributes are: ms-RTC-SIP-DefaultCWAExternalURL and ms-RTC-SIP-DefaultCWAInternalURL.  So now that we know where the information is stored, how did it get into Lync?  The Dialin13 simple URL was created in Lync when you ran Import-CsLegacyConfiguration as part of the migration steps from OCS to Lync Server.  In order to remove the old OCS dial-in simple URL, we're going to follow the steps outlined in Example 3 in the Set-CsSimpleUrlConfiguration TechNet article:

Because the Set-CsSimpleUrlConfiguration cmdlet needs to work with URL objects, the example starts by creating a new object that contains the exact same property values as the URL to be deleted.  To do that, the first command uses the New-CsSimpleUrlEntry cmdlet to create a URL entry that points to https://im.test.deitterick.com/dialin; this URL entry is stored in a variable named $urlEntry:

$urlEntry = New-CsSimpleUrlEntry -Url "https://im.test.deitterick.com/dialin"

After the URL entry has been created, the second command uses the New-CsSimpleUrl cmdlet to create an in-memory instance of a simple URL.  In this example, the URL Component is set to Dialin13; the domain is set to *; the ActiveUrl is set to https://im.test.deitterick.com/dialin; and the SimpleUrl property is set to $urlEntry, $urlEntry being the URL entry created in the first command.  This creates an in-memory URL ($simpleUrl) that has the same property values as the URL to be deleted:

$simpleUrl = New-CsSimpleUrl -Component "Dialin13" -Domain "*" -SimpleUrlEntry $urlEntry -ActiveUrl "https://im.test.deitterick.com/dialin"

The final command in the example then deletes the URL from the simple URL collection for the Global site.  This is done by using the Set-CsSimpleUrlConfiguration cmdlet, the SimpleUrl parameter, and the parameter value @{Remove=$simpleUrl}.  This syntax simply causes the URL stored in the object reference $simpleUrl to be removed from the SimpleUrl property:

Set-CsSimpleUrlConfiguration -Identity Global -SimpleUrl @{Remove=$simpleUrl}

Once the command completes, you will see a warning message about running Enable-CsComputer.  You can go ahead and run Enable-CsComputer on your Lync Server Front End Servers for good measure:

If you go back to the Lync Server Control Panel and look in Topology > Simple URL, you will see that the Dialin13 simple URL is no longer there:

Note: You may need to click on the image above in order to read the text.

One important thing to remember is that if you run Import-CsLegacyConfiguration again for any reason, it will recreate the Dialin13 simple URL!  The reason for this is that those attributes still exist in Active Directory and the cmdlet will import them again.  However, this shouldn't be a big issue, since you shouldn't need to run the Import-CsLegacyConfiguration cmdlet again once you've decommissioned your OCS environment.

You may encounter an issue while trying to install the August 2014 Cumulative Update for Microsoft Lync Server 2013 on a computer with just the Lync Server Core Components and/or Lync Server Administration Tools installed.  In the screenshot below, you can see that I only have the Lync Server Core Components and Lync Server Administration Tools installed:

If I try to apply the August 2014 Cumulative Update for Microsoft Lync Server 2013:

I get the following error message:

There were errors during the installation process. For details, see the log file at C:\Users\Administrator.TEST\Desktop\Lync_patchinstallerlog-TEST-LS15-MGMT-[2014-08-19][15-53-17].txt

and you can see that the Lync Server Core Components aren't updated:

For more information on this issue, please see KB2993188.

I had a question from a customer recently that was having issues adding users to Persistent Chat rooms.  When they tried to add a user, they would get the following error:

Invalid members: <user>

Checking the category that the room is a member of shows that they added the Domain Users group as an allowed member:

Note: You may need to click on the image above in order to read the text.

Unfortunately this doesn't quite do what they were expecting it to do.  Adding a group doesn't mean that the users in that group, all domain users in this case, are available to be added individually as members of a room.  What it actually means is that the group, Domain Users, can be added as a member of the room:

So what if you want to add individual users as members, but don't want to micro manage the category's allowed members?  From the Understanding Persistent Chat Membership TechNet article:

We recommend, as a general rule, that you use Active Directory containers, such as domains and organizational units, for defining a category’s AllowedMembers and Creators.

So instead of adding a group, try adding an OU.  In this example I added the Users OU, which contained the user account I wanted to add individually to the room:

Note: You may need to click on the image above in order to read the text.

Now when you try to add a user individually, as long as they're in that OU, they are able to be added successfully:

I had a customer request recently to be able to completely disable photos for some users in Lync 2013.  They didn't want photos to show up anywhere in the Lync 2013 client for these users.  It sounded like an easy enough request, however, it turned out not to be.  Photos in this environment would be coming from AD, stored in the thumbnailPhoto attribute.  When user's logged in, photos would display as expected:

In order to disable photos in the client, you will need to edit the client policy.  You can run:

Set-CsClientPolicy -Identity <policy> -DisplayPhoto NoPhoto

If you sign out and back in to the Lync client, you will notice that photos no longer display:

Simple enough, right?  Unfortunately, there's one small wrinkle.  If you view a user's contact card:

or open an IM window with a user:

You'll notice that their photo is displayed.  This is a different experience than the Lync 2010 client where photos are disabled in the contact card and IM window after setting the DisplayPhoto parameter to NoPhoto in the client policy:

There is another parameter in the client policy that can control photos, MaxPhotoSizeKB.  From the Set-CsClientPolicy TechNet article:

Indicates the maximum size (in kilobytes) for photos displayed in Lync. Setting the MaxPhotoSize to 0 prevents any photos from being displayed in Lync.

The default value is 30 kilobytes.

Unfortunately, you can't set this parameter to 0:

PS C:\Users\Administrator.TEST> Set-CsClientPolicy -Identity <policy> -MaxPhotoSizeKB 0
Set-CsClientPolicy : MaxPhotoSizeKB must be greater than or equal to 1.
At line:1 char:1
+ Set-CsClientPolicy -Identity Global -MaxPhotoSizeKB 0
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (Global:String) [Set-CsClientPolicy], PropertyArgumentOutOfRangeException
    + FullyQualifiedErrorId : InvalidUpdate,Microsoft.Rtc.Management.Internal.SetClientPolicyCmdlet

You can set the value to 1, which means that photos over 1KB in size shouldn't be displayed in the Lync 2013 client.  You can verify that the policy took effect by checking the in-band provisioning settings in the client .UccApilog file:

- <provisionGroupList  xmlns="http://schemas.microsoft.com/2006/09/sip/provisiongrouplist-notification">
       <provisionGroup  name="publicProviders"/>
    +  <provisionGroup  name="userSetting">
    +  <provisionGroup  name="ServerConfiguration">
    +  <provisionGroup  name="locationPolicy">
    +  <provisionGroup  name="persistentChatConfiguration">
    +  <provisionGroup  name="mediaConfiguration">
    +  <provisionGroup  name="meetingPolicy">
    +  <provisionGroup  name="privacyPublicationGrammar">
    +  <provisionGroup  name="presencePolicyV2">
    +  <provisionGroup  name="ucPolicy">
    +  <provisionGroup  name="publicationGrammar">
    -  <provisionGroup  name="endpointConfiguration">
        -  <propertyEntryList>
               <property  name="ShowRecentContacts">true</property>
               <property  name="ShowManagePrivacyRelationships">false</property>
               <property  name="MaxPhotoSizeKB">1</property>
               <property  name="DisableMusicOnHold">true</property>
               <property  name="PhotoUsage">NoPhoto</property>
               <property  name="AbsUsage">WebSearchOnly</property>
               <property  name="HotdeskingTimeout">300</property>
               <property  name="EnableContactSync">true</property>
               <property  name="ShowSharepointPhotoEditLink">false</property>
               <property  name="EnableVOIPCallDefault">false</property>
               <property  name="MaximumDGsAllowedInContactList">10</property>
               <property  name="P2PAppSharingEncryption">0</property>
               <property  name="EnableHighPerformanceP2PAppSharing">false</property>
               <property  name="EnableHighPerformanceConferencingAppSharing">false</property>
               <property  name="TracingLevel">Light</property>
        - </propertyEntryList>
    - </provisionGroup>
 </provisionGroupList>

Checking the size of the photo, you can see that it is larger than 1 KB:

You can also view the size of the photo using Fiddler:

Note: You may need to click on the image above in order to read the text.

Unfortunately the Lync 2013 client will still display photos in the contact card and IM window.  Currently there's no way to completely disable photos from showing in the Lync 2013 client.

I see this a lot in customer environments with Office Web Apps Server 2013 deployed for use with Lync Server 2013, where if you run the Get-OfficeWebAppsMachine cmdlet, the HealthStatus parameter is Unhealthy:

However, even though Office Web Apps Server 2013 reports as unhealthy, as far as Lync Server 2013 is concerned, everything is working fine.  Presenters in meetings are able to upload PowerPoint presentations and attendees can see the presentations.  So what is causing the unhealthy status and how do you fix it?

There are generally two issues that could be causing Office Web Apps Server 2013 to report as unhealthy.  If you look in the Microsoft Office Web Apps Event Log on the Office Web Apps Server 2013 server, you may see an error similar to the following:

<?xml version="1.0" encoding="utf-16"?>
<HealthReport xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <HealthMessage>BroadcastServicesWatchdog_Wfe reported status for BroadcastServices_Host in category '4'. Reported status: Contacting Present_2_0.asmx failed with an exception: Could not establish trust relationship for the SSL/TLS secure channel with authority 'test-owas1.test.deitterick.com'.</HealthMessage>
</HealthReport>

In this error message, you can see that there appears to be an issue with the certificate being used for the Office Web Apps Farm:

Could not establish trust relationship for the SSL/TLS secure channel with authority 'test-owas1.test.deitterick.com'.

This is because when you create the certificate for the Office Web Apps Farm, you need to include SAN entries for all servers in the farm.  Even if there's only a single server in the farm, if the names that you enter for the ExternalURL and/or InternalURL parameters are different than the server FQDN, you will need to add the server FQDN to the certificate.  In this example, I have a single Office Web Apps Server 2013 server and for the ExternalURL and InternalURL parameters, I've entered:

When creating the certificate for the Office Web Apps Farm, I needed to add the server FQDN as a SAN entry to the certificate:

This may be enough to resolve your issue and get Office Web Apps Server 2013 to report healthy:

Note: It may take awhile for the server to report a HealthStatus of Healthy.

If you are still seeing the HealthStatus reported as Unhealthy:

There may still be an additional error showing up in the Microsoft Office Web Apps Event Log:

<?xml version="1.0" encoding="utf-16"?> <HealthReport xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">   <HealthMessage>AgentManagerWatchdog reported status for AgentManagerWatchdog in category 'Recent Watchdog Reports'. Reported status: Machine health is Unhealthy</HealthMessage> </HealthReport>

This error is generally caused by not having the HTTP Activation feature installed on the Office Web Apps Server 2013 server:

You can install the missing feature using Server Manager or by running the following PowerShell cmdlet:

Add-WindowsFeature NET-WCF-HTTP-Activation45

After adding the missing feature, the Office Web Apps Server 2013 should now report healthy:

Note: It may take awhile for the server to report a HealthStatus of Healthy.

I was troubleshooting an issue with media connectivity in Lync Web App and needed to gather additional information on what was happening with the Lync Web App.  By default LWA logs some basic information.  Unfortunately this didn't tell me what I needed.  In order to get more detailed logs from LWA, you just need to append the following to the meeting join URL:

https://meet.test.deitterick.com/william.cooper/YL6HFCPK?sl=1&log=full

Adding &log=full to the end of the meeting join URL will cause the Lync Web App to log additional information.  The logs that LWA creates are stored here:

C:\Users\<username>\AppData\Local\Microsoft\LWAPlugin\Tracing

Specifically, the file you are looking for is:

LWAJSPersistentx.log

Where x is a number, usually 0 or 1.  Opening up the file, you will see a whole bunch of information including information about WebTicket, MRAS, and ICE candidates among other information.

You can use the query* below to get a list of explicit permissions assigned in Group Chat or Persistent Chat:

SELECT tblNode.nodeName AS "Category/Channel",
tblPrincipal.prinName AS "Name",
CASE tblPrincipalType.ptypeDesc
WHEN 'Parlano.Server.Common.User' THEN 'User'
WHEN 'Parlano.Server.Common.ExternalUser' THEN 'External User'
WHEN 'Parlano.Server.Common.FederatedUser' THEN 'Federated User'
ELSE tblPrincipalType.ptypeDesc
END AS "Type",
CASE isMember WHEN 1 THEN 'Y' ELSE 'N' END AS "Member",
CASE isManager WHEN 1 THEN 'Y' ELSE 'N' END AS "Manager"
FROM [GroupChat].[dbo].[Exp_RoleView]
INNER JOIN [GroupChat].[dbo].[tblPrincipal] on Exp_RoleView.principalId=tblPrincipal.prinGuid
INNER JOIN [GroupChat].[dbo].[tblPrincipalType] on tblPrincipal.prinTypeID=dbo.tblPrincipalType.ptypeID
INNER JOIN [GroupChat].[dbo].[tblNode] on Exp_RoleView.nodeDbId=tblNode.nodeID
/* WHERE isManager = 1 */
/* WHERE isMember = 1 */
ORDER BY [Category/Channel]

Note: This same query works on Lync Server 2013 Persistent Chat, however you will need to change the following line:

INNER JOIN [GroupChat].[dbo].[tblPrincipal] on Exp_RoleView.principalID=tblPrincipal.prinGuid

Remember to update the query above with the correct database name.  For GroupChat, replace [GroupChat] with the name of your GroupChat database.  For Persistent Chat, replace [GroupChat] with [mgc].

If you want only a list of members or managers, you can uncomment the appropriate line:

/* WHERE isManager = 1 */
/* WHERE isMember = 1 */

The query will produce results similar to this:

Thanks go out to Indranil Dutta for sending this my way and to Justin Kulesa and Michael Hendrix for working on the SQL query.

*These queries are provided for you to use at your own risk. Please make sure you test before running in a production environment.

A question I get a lot when talking with administrators about Lync is how to handle name changes and what effect changing a user's SIP address has on other users.  In the example below we will look at the effects of changing a user's SIP address and what other user's will need to be aware of.  In the screenshot below, William has Judith as a contact on his contact list.  Judith's last name is changing and so will her SIP address:

After updating the user's display name and changing their SIP address, the user will be signed out of the Lync client:

If we take a look at what actually happened in the database, before making any changes, you can see that each user is assigned a unique ResourceId:

These IDs are what are used by the database to keep track of your contact list.  This means that since your contacts aren't stored with the SIP address being the identifying field, when a user on your contact list has their SIP address changed, you don't need to remove and re-add them to your contact list again.  The only exception to this is federated contacts.  Those contacts would need to be removed and re-added since they aren't part of our Lync environment:

After changing Judith's SIP address, you can see that the ResourceId stayed the same:

Once Judith changes her sign in address in the Lync client, she will be able to sign in successfully and you can see that her updated display name is shown.  Also any contacts that she had on her contact list would still be there:

However, for William Cooper, you can see that his client didn't pick up the changes:

This is because these users will need to sign out and back in before their client will pick up the changes.  After signing out and back in, you can see below that William's client now displays the correct contact:

Joining a meeting that Judith scheduled before her SIP address was updated will produce the following error:

This is because the join URL is referencing her old SIP address:

https://meet.test.deitterick.com/judith.kramer/ZC5126N0

The meeting information that is stored in the database is valid, but since the join URL is incorrect, Lync is unable to find the correct meeting.  After changing Judith's SIP address her join URL changes to:

https://meet.test.deitterick.com/judith.smith/ZC5126N0

This means that any scheduled meetings would need to be updated so that users are able to join without issue.

Searching the address book for Judith may produce inconsistent results:

Since the Address Book service hasn't run yet to update the address book, the Lync client may be pulling some stale information.  In the screenshot above, the old SIP address was still be used so a 404 was being returned to the client.  After updating the address book, searching for Judith produced the expected results:

The Lync client handles SIP address changes fairly well.  Just remember to have users update their meetings and let any federated contacts know that their SIP address has changed.

The PAL (Performance Analysis of Logs) tool is a powerful tool that reads in a performance monitor counter log and analyzes it using known thresholds.  The Lync Server 2013 Threshold files help you to identify performance issues on your Lync Server 2013 Servers.  Files are included for the following roles:

• Front End
• Edge
• Mediation

You can download the latest version of the Lync Server 2013 threshold files here.

After downloading, make sure to copy all of the threshold files into the PAL installation directory.  You can download the latest version of PAL here.

The PAL (Performance Analysis of Logs) tool is a powerful tool that reads in a performance monitor counter log and analyzes it using known thresholds.  The Lync Server 2010 Threshold files help you to identify performance issues on your Lync Server 2010 Servers.  Files are included for the following roles:

• Front End
• Monitoring/Archiving
• Edge
• Mediation

You can download the latest version of the Lync Server 2010 threshold files here.

After downloading, make sure to copy all of the threshold files into the PAL installation directory.  You can download the latest version of PAL here.

I ran into an interesting issue onsite with a customer recently.  They have Group Chat 2010 deployed for their users and one of the users reported that they were not able to see messages or participate in a particular chat room.  Other users in that chat room were able to view the messages and participate in the chat room just fine.  The issue was specific to that user and followed that user.  If they signed into the Group Chat 2010 client on another machine, the same issue would persist there.  The screenshot below shows what that user saw, or didn't see, for that chat room:

As you can see the participant list, message input area, and the actual messages are missing.  When we check another chat room that the user was a member of, everything looked correct:

Also interesting was that the Show Participants and Show Message Input Area options were selected for the chat room that the user was having an issue with:

Since this issue followed the user, we needed to figure out where these settings were stored so that we could take a look at them.  We figured out that the settings are actually stored in two locations.  The first is on the client machine and the other location is in the Group Chat database.  Both locations should contain the same exact settings.  You can check the client by looking here:

C:\Users\<username>\AppData\Roaming\Microsoft\Group Chat\Group Chat Client\Preferences\<user sip address>

In this folder you will find a bunch of files.  For this issue we need to look in the GroupChannels file.  This file contains all of the settings for the chat rooms the user has joined:

Note: You may need to click on the image above in order to read the text.

There is also a GroupChannels.serverstatus file.  If you open this file you will see something similar to:

<?xml version="1.0" encoding="utf-8"?>
<ServerStatusRecord xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <SeqId>7</SeqId>
  <LatestPrefsWrittenToServer>true</LatestPrefsWrittenToServer>
  <Key>GroupChannels</Key>
</ServerStatusRecord>

This file contains the sequence id, basically the version of the settings, and whether or not they've been synced with the Group Chat Server.  To check whether or not the Group Chat Server contains the same settings you will need to run a SQL query* against the Group Chat database:

SELECT [prefLabel]
      ,[prefSeqID]
  FROM [GroupChat].[dbo].[tblPreference]
  WHERE [prefLabel] like 'sip:wcooper%'
  ORDER BY [prefLabel]

This will return results similar to:

Note: The prefSeqID value may not be the same for every file.  Not all of the settings update every time.

As you can see, the prefSeqID for GroupChannels matches the SeqId in the GroupChannels.serverstatus file.  This means that the server contains the same settings as the client, so the user's issue isn't a case of the settings being out of sync with the Group Chat Server.  The next thing to take a look at are the settings that control the participant list and the message input area.  You won't be able to look at these settings in the database, as the data isn't easily readable.  However, since the client and server are in sync, looking at the GroupChannels file will tell us what we need to know:

Note: You may need to click on the image above in order to read the text.

If you scroll through the file, you will see that there are a list of settings for each chat room that the user has joined.  We need to figure out which list of settings pertains to the chat room the user is having an issue with.  You can find a list of chat rooms and their GUID by running the follow SQL query* against the Group Chat database:

SELECT [nodeGuid]
      ,[nodeName]
  FROM [GroupChat].[dbo].[tblNode]
  ORDER BY nodeName

This will return results similar to:

As you can see from the screenshot above, the Operations chat room, which is the chat room the user is having issues with, has a GUID of 65419d20-2419-45b5-b054-bcd87e1d6c3e.  In the GroupChannels file if you search for the GUID, you will be returned a match similar to:

<member name="_key_" type="S.String" value="ma-chan://test.deitterick.com/65419d20-2419-45b5-b054-bcd87e1d6c3e" />

This is the beginning of that chat room's list of settings. Now that we have found the list of settings pertaining to the chat room we were looking for, the specific settings and values to look for are:

<member name="showParticipantListPanel" type="S.Boolean" value="True" />
<member name="participantListPanelWidth" type="S.Int32" value="65535" />

and

<member name="inputBoxHeight" type="S.Int32" value="65535" />
<member name="showInputBox" type="S.Boolean" value="True" />

As you can see, while both showParticipantListPanel and showInputBox are set to True, participantListPanelWidth and inputBoxHeight are set to really large values.  What is essentially happening is that the participant list and message input area are hiding the conversations.  To fix this we just needed to set the values to something more reasonable:

<member name="participantListPanelWidth" type="S.Int32" value="90" />

<member name="inputBoxHeight" type="S.Int32" value="90" />

The Group Chat client needs to be closed when you save the file, otherwise the settings will be overwritten.  Once you save the file and launch the Group Chat 2010 client again, the user should now be able to see everything in the chat room:

*These queries are provided for you to use at your own risk. Please make sure you test before running in a production environment.

I was helping a customer setup Lync Server 2013 when we ran into an interesting issue while testing conferencing with external Lync 2013 clients.  Every time we attempted to present a PowerPoint presentation, the presentation would never display.  From the screenshot below, you can see that the file is and was uploaded to the Lync Server 2013 Front End Server successfully:

In Lync Server 2013, once the PowerPoint presentation is successfully uploaded to the Lync Server 2013 Front End Server, a URL is passed back to all of the clients in order for them to download the PowerPoint presentation.  This URL points the clients to the Office Web Apps Server 2013.  The Lync 2013 client then makes a connection to the Office Web Apps Server 2013 to view the PowerPoint presentation.  However, as you can see in the screenshots below, the presentation is never loaded:

Eventually it would error out with:

Either the network connection has been lost or the server is busy. Please check your network connection.

In order to troubleshoot what was happening we needed to be able to see the HTTPS traffic that the Lync 2013 client was sending/receiving.  The easiest way to do that is to use a program called Fiddler.  It allows you to decrypt and view the HTTPS traffic that is being sent by the Lync 2013 client.  In the screenshot below, you can see that when the Lync 2013 client attempts to connect to the Office Web Apps Server 2013, an error result is being returned:

Note: You may need to click on the image above in order to read the text.

If you look at the raw information being returned, you can see the following error information:

HTTP/1.1 500 ( The request was rejected by the HTTP filter. Contact the server administrator.  )

This means that the request to download the PowerPoint content is being blocked somewhere.  Since the client we took the tracing on is external, the first place to look is on the Reverse Proxy.  In this case, the Reverse Proxy is Threat Management Gateway (TMG) 2010.  Looking at the logging on the TMG server, you can see that in fact, TMG is rejecting the traffic:

Note: You may need to click on the image above in order to read the text.

If you search for the error that is being returned, you will find reference to KB837865.  The workaround in the KB makes reference to editing the Web Publishing Rule that was created for Office Web Apps Server 2013.  If you go into the Firewall Policy in the TMG Management Console:

Right click on the Web Publishing Rule created for Office Web Apps Server 2013 and click on Properties:

Then click on the Traffic tab:

Then click on Filtering > Configure HTTP:

On the General tab, under URL Protection are the settings we're looking for.  KB837865 says to uncheck Block high bit characters, however for the issue we're seeing, the resolution is to uncheck Verify normalization:

Once we applied the changes to TMG, we tested again, and this time as you can see in the screenshot below, the Lync 2013 client was able to successfully connect to the Office Web Apps Server 2013:

Note: You may need to click on the image above in order to read the text.

From the Lync 2013 client, the PowerPoint presentation was loaded successfully:

With the release of the November 2013 Cumulative Update for the Lync 2013 client free/busy information is being pulled by the Lync 2013 client again and being used to change your presence state accordingly.  You can download the latest client update here.

I ran into an interesting issue while I was building out a test environment in my lab.  After applying the latest cumulative updates for Lync Server 2013, if you used the Lync Server 2013 Logging Tool (OCSLogger.exe) from the Microsoft Lync Server 2013 Debugging Tools, SIPStack messages aren't being parsed from the .etl file and displayed in Snooper.  The data is being captured by the Lync Server 2013 Logging Tool, and you can verify that if you open the .etl file in Notepad.

To resolve this issue you just need to copy the latest tracing files into the Debugging Tools directory.  If you look in C:\Program Files\Microsoft Lync Server 2013\Debugging Tools (assuming you chose the default install location), you should see the following: 

If you look at the Properties of the default.tmx file, you can see the following:

Take note of the file size and created date.  If you then navigate out to C:\Program Files\Common Files\Microsoft Lync Server 2013\Tracing, you will see the following:

If you look at the Properties of the default.tmx file, you can see the following:

If you look at the file size and the created date on this version, you can see that it is much larger and newer than the default.tmx file in the Debugging Tools directory.  This file contains the information that the Lync Server 2013 Logging Tools needs to parse the .etl file.  All you need to do is copy both files into the Debugging Tools directory:

Now when you click the Analyze Log Files button in the Lync Server 2013 Logging Tool, the SIPStack messages will be displayed.

While the preferred method of logging in Lync Server 2013 is to utilize the Centralized Logging Service, if you still prefer using the Lync Server 2013 Logging Tool/GUI to configure logging, then make sure to follow the steps above.

Update 11/12/14 - Added information about white paper published for Web Application Proxy for use with Lync Server 2013.
Update 8/30/14 - Added information about Lync 2013 mobility and multiple SIP domains.

With the discontinuation of TMG and with UAG not supporting all of the functionality of Lync, the choices for the Reverse Proxy role have been slimmed down a bit.  Utilizing an existing TMG environment, choosing to setup IIS ARR, or go with a third party product are the options available. Each has its pros and cons. With the release of Windows Server 2012 R2, another option for the Reverse Proxy role for Lync Server 2013 Web Services is possible. Included in Windows Server 2012 R2 is the Web Application Proxy role.  The Web Application Proxy Overview TechNet article provides high level information on the role and it's uses.  You can use the Web Application Proxy role to publish many different types of applications.  This blog post only focuses on publishing Lync Server 2013 Web Services.  One prerequisite for the Web Application Proxy that we won't discuss in this blog post is that you will need AD FS running on Windows Server 2012 R2 already installed and working in your environment.  For environments that aren't using AD FS currently, this may make using the Web Application Proxy role as the Reverse Proxy for Lync Server 2013 Web Services less appealing that another Reverse Proxy solution, but for environments that do leverage AD FS, the ability to combine services might make sense.

A white paper has been published that describes the requirements, planning and configuration of Web Application Proxy for use with Lync Server 2013.  You can download it here.

Installing the Windows Server 2012 R2 Web Application Proxy Role

In Server Manager, open the Add Roles and Features Wizard.  On the Select server roles screen, select Remote Access and click Next:

On the Select features screen, no additional features are needed, click Next

On the Remote Access screen, click Next

On the Select role services screen, select Web Application Proxy and click Next:

When the Add features that are required for Web Application Proxy? box pops up, select Add Features and then click Next:

On the Confirm installation selections screen, click Install:

When the installation is complete, click Open the Web Application Proxy Wizard:

On the Welcome screen, click Next

On the Federation Server screen, enter the appropriate information and then click Next:

Note: The rules we're going to publish for Lync Server 2013 aren't going to use AD FS, but the configuration for the Web Application Proxy requires that AD FS be setup and configured during installation of the role.

On the AD FS Proxy Certificate, select the certificate to be used by the AD FS proxy and then click Next:

Note: The certificate needs to be the AD FS certificate with the private key.

On the Confirmation screen, click Configure:

On the Results screen, make sure that the Web Application Proxy was configured successfully and then click Close:

Publishing Web Applications

Now that the Web Application Proxy has been installed and configured, you need to publish rules for the URLs that you want to pass through the proxy.

Open the Remote Access Management Console

In the Tasks section click Publish:

On the Welcome screen, click Next

On the Preauthentication screen, select Pass-through and click Next:

On the Publishing Settings screen, fill out the fields with the appropriate information and then click Next:

Note: For the Backend server URL field, remember to append ":4443" to the external web services URL and simple URLs.

On the Confirmation screen, click Publish:

Note: You can also use PowerShell to create the published web applications:

Add-WebApplicationProxyApplication -BackendServerUrl 'https://test-ls15-se.test.deitterick.com:4443/' -ExternalCertificateThumbprint 'F689AA0EF22532B560C9DA09B9C15CD8190E26EA' -ExternalUrl 'https://test-ls15-se.test.deitterick.com/' -Name 'TEST-LS15-SE.test.deitterick.com External Web Services' -ExternalPreAuthentication PassThrough

On the Results screen, ensure that the web application was published successfully and then click Close:

Repeat the steps in this section for the remaining Lync URLs that you want to publish:

Since some of the Lync 2013 mobile clients don't yet support Server Name Indication (SNI), you'll need to apply a default SSL certificate for the Web Application Proxy to use.  In the How to: Configure a Port with an SSL Certificate MSDN article, you can use a command similar to:

netsh http add sslcert ipport=0.0.0.0:443 certhash=f689aa0ef22532b560c9da09b9c15cd8190e26ea appid={f955c070-e044-456c-ac00-e9e4275b3f04}

In order to get the correct certhash and appid values, you can run the following command:

netsh http show sslcert

The results will be similar to below:

Find one of the web applications that you published and copy the Certificate Hash and Application ID fields to use in the netsh command above.  This will ensure that clients that don't support SNI are returned a certificate.  If you choose to bind to all IPs (0.0.0.0), you'll need to make sure that all names for all the published web applications are listed on the certificate.  Once all of the web applications are published, you can test them to make sure everything is working correctly.

Lync 2013 Mobility and Multiple SIP Domains

I get asked occasionally whether or not Windows Server 2012 R2 Web Application Proxy will work when you're using the Lync 2013 mobile clients and have multiple SIP domains in your environment.  When I originally wrote this blog post I only had one SIP domain configured in my lab, so I never tested this.  I decided to add another SIP domain and test it out to see whether or not it would work.  The short answer from my quick testing in my lab is that, yes, you can use Windows Server 2012 R2 Web Application Proxy for mobility with multiple SIP domains.  Just keep in mind that you may need to fill out some additional fields in the Lync 2013 mobile client.  In my lab, when trying to sign in with a user provisioned with a SIP URI from the second SIP domain:

Unfortunately, the sign in failed with "We can't sign you in. Please check your account info and try again.":

All I needed to do to resolve this error was to fill out the User Name field under Advanced Options:

This isn't an issue with the way Windows Server 2012 R2 Web Application Proxy works.  It is because my sign-in address doesn't match my UPN in AD.  This causes an issue when trying to authenticate with the WebTicket service.  With the User Name field filled out correctly, this time the sign in completed successfully:

This was a quick test with the Windows Phone version of the Lync 2013 mobile client.  As I get time to test the other version of the Lync 2013 mobile client, I will post any interesting findings.  Make sure that if you are going to be using Windows Server 2012 R2 Web Application Proxy and you have multiple SIP domains you thoroughly test the different Lync 2013 mobile clients for all of the mobile OS versions you will be supporting.

Monitoring

You can use the Operations Status section of the Remote Access Management Console to monitor the Web Application Proxy:

From there you can open the Event Viewer and look at the Admin event log or view the Performance Monitor counters:

While the Web Application Proxy role in Windows Server 2012 R2 may not be as feature rich as a traditional Reverse Proxy, if you're using AD FS today and want an easy way to publish Lync Server 2013 Web Services, it's worth a look.

With the release of the Updates for Lync Server 2013: October 2013, Lync Server 2013 is now supported on Windows Server 2012 R2.  You may see Event IDs 32402 and 61045 logged on the Lync Server 2013 Front End Servers:

Event ID 32042

Log Name: Lync Server
Source: LS User Services
Date: 10/15/2013 4:02:05 AM
Event ID: 32042
Task Category: (1006)
Level: Error
Keywords: Classic
User: N/A
Computer: LyncFE01.contoso.local
Description:
Invalid incoming HTTPS certificate.
Subject Name: LyncFE01.contoso.local Issuer: Contoso-CA

Cause: This can happen if the HTTPS certificate has expired, or is untrusted. The certificate serial number is attached for reference.

Resolution: Please check the remote server and ensure that the certificate is valid. Also ensure that the full certificate chain of the Issuer is present in the local machine.

Event ID 61045

Log Name: Lync Server
Source: LS MCU Infrastructure
Date: 10/15/2013 4:02:20 AM
Event ID: 61045
Task Category: (1022)
Level: Error
Keywords: Classic
User: N/A
Computer: LyncFE01.contoso.local
Description: The DATAMCU was not able to stay connected to the Front End over the C3P channel (HTTPS Connection).
The Web Conferencing Server failed to send C3P notifications to the focus at https:// LyncFE01.contoso.local:444/LiveServer/Focus.

Cause: The Front End may not be running correctly or may be unreachable over the network (broken HTTPS connection) from the MCU. Unavailability of The C3P channel affects conference controls, and can also prevent users from joining, starting conferences.

Resolution: Verify that the Front End server is running correctly and that network connectivity and an HTTPS Connection can be established between the MCU and the Front End server.

If so, follow the workaround listed in KB2901554.

With the release of the September 2013 Cumulative Update for the Lync 2013 client, the icon used in the notification area of the taskbar is back to the original icon showing your presence status:

Update 11/10/13 - This issue has been resolved with the release of the November 2013 Cumulative Update.  You can get more information here.

With the release of the September 2013 Cumulative Update for the Lync 2013 client, there is a known issue with presence not updating based on the user's free/busy status from their Exchange calendar.  You can find more information about the issue in KB2883716.  This issue will be fixed in a future update.

Lync Server 2013 now supports using SQL clustering for the SQL store.  From the Database Software Support TechNet article:

Lync Server 2013 supports the use of either SQL mirroring or SQL clustering for each Lync Server database. You can easily set up SQL mirroring with the Topology Builder tool in Lync Server 2013. For SQL failover clustering, you must use SQL Server for setup.

Lync Server 2013 supports SQL clustering topologies for all deployments, including greenfield deployments and organizations that have upgraded from previous versions of Lync Server.

SQL Clustering support is for an active/passive configuration. For performance reasons, the passive node should not be shared by any other SQL instance.

The following support is included:

•     Two-node failover clustering for the following:
• Microsoft SQL Server 2012 Standard (64-bit edition). Additionally running the latest service pack is recommended.
• Microsoft SQL Server 2008 R2 Standard (64-bit edition). Additionally running the latest service pack is recommended.
•     Up to sixteen-node failover clustering for the following:
• Microsoft SQL Server 2012 Enterprise (64-bit edition). Additionally running the latest service pack is recommended.
• Microsoft SQL Server 2008 R2 Enterprise database software (64-bit edition). Additionally running the latest service pack is recommended.

Update 9/20/13 - With the release of the September 2013 Cumulative Update, the icon has reverted back.  You can get more information here.

With the release of Security update for Lync 2013: July 2013, there is a change to the icon used for Lync 2013 in the notification area of the taskbar.  Instead of the icon showing the current presence state, after applying KB2817465, the icon will now look like the following:

Hovering over the icon will show your current presence state:

Update 12/11/14 - Added database versions for December 2014 Cumulative Update.
Update 11/20/14 - Added database versions for November 2014 Cumulative Update.
Update 10/29/14 - Added database versions for October 2014 Cumulative Update.
Update 9/23/14 - Added database versions for September 2014 Cumulative Update.
Update 8/6/14 - Added database versions for August 2014 Cumulative Update.
Update 4/7/14 - Added database versions for Persistent Chat compliance database.
Update 1/8/14 - Added database versions for January 2014 Cumulative Update.
Update 10/8/13 - Added database versions for October 2013 Cumulative Update.
Update 7/2/13 - Added database versions for July 2013 Cumulative Update.

After downloading and installing Lync Server 2013 updates from KB2809243, it is important to remember to go back and apply the back end database updates.  The steps to apply the back end database updates are listed in the KB article.  After applying the back end database updates, you can use the Test-CsDatabase cmdlet to make sure that the databases are up-to-date.

The cmdlet will show you the expected version and the installed version, as well as whether or not the database is up-to-date:

The tables below list the back end database versions for RTM as well as each cumulative update: 

This was a really interesting issue that I ran into at a customer recently.  The goal was to install the Monitoring Server role so that they could report on adoption and usage of Lync 2010.  They already had an existing Lync Server 2010 environment up and running, so we were just adding the Monitoring Server role to the topology.  However when publishing the topology we encountered the following error:

Viewing the deployment log showed the following error message:

Error: Script failed (code "ERROR_EXECUTE_BATCH") when installing "MonitoringStore" on "TEST-SQL.test.deitterick.com". For details, see the following log file: "C:\Users\Administrator.TEST\AppData\Local\Temp\Create-MonitoringStore-TEST-SQL.test.deitterick.com-[2013_06_24][11_54_11].log"

Looking at the Create-MonitoringStore log file showed the following:

Error executing batch DbRtcCdr.sql on LcsCDR

For some reason there appears to be a problem creating the database, so we went to the SQL Server to see if we could see any issues.  On the SQL Server, in SQL Server Management Studio, I noticed a couple of things.   First, the LcsCDR database did get created, but it was still in the Restricted User state.  That ruled out any kind of firewall or permissions issue.  Secondly, the Address Book databases database names didn't look correct:

The Address Book database names should be rtcab and rtcab1.  They don't get created with capital letters, which means that someone changed them for some reason.  We decided to rename them back to the default values.  Once we did that, we started seeing the following error message on the Front End Server:

Also, on the SQL Server, we started seeing the following message in the Event Log:

The Front End Server is trying to connect to the RtcAb database, but the SQL Server is saying that it can't open that database.  However when we change the Address Book database names back to having capital letters, the errors go away and everything is fine.  So it appears the issue is that the SQL Server can't find the database if the database name in the connection string from the Front End Server isn't the same case.  Case sensitivity is a collation setting on the SQL Server instance.  You can find more information about SQL Server collations in the SQL Server Collation Fundamentals TechNet article.  Looking at the SQL instance properties in SQL Server Studio Manager shows us the root of the problem:

The Server Collation for this instance is set to Latin1_General_BIN, not the default of Latin1_General_CP1_CI_AS.  When you install a SQL instance, there are options for changing the collation settings:

The solution was to go through the process of changing the Server Collation for this instance.  Once the Server Collation was set to the default of Latin1_General_CP1_CI_AS, we were able to complete the creating of the Monitoring Server databases.