With the release of Lync Server 2013, there are two versions of the Lync 2013 client available:
What's the difference between the two?
Lync Basic 2013 provides all the basic functionality that’s available in the full version of Lync (Lync 2013). However, if you want to use any of the following features, you will need to upgrade to Lync 2013:
You can find more information on which specific features are supported in each client in the Client Comparison Tables TechNet article.
Where can I download the Lync 2013 clients?
Lync Basic 2013 is available on the Microsoft Download Center and comes in two versions:
Lync 2013 is available via the Microsoft Volume Licensing Service Center for customers with a Volume Licensing agreement.
Update 4/8/14 - Updated prerequisites for Windows Server 2008 R2.Update 1/12/13 - Updated with additional information.Update 11/10/13 - Updated with links to updates for Office Web Apps Server.Update 3/18/13 - Updated for RTM of Lync Server 2013.Update 11/14/12 - Updated for RTM of Office Web Apps Server.
The Office Web Apps Server is a required role when deploying Lync Server 2013. By default when you add conferencing to the pool, you'll notice that in Topology Builder, you will be required to associate the Standard Edition Server or Enterprise Edition pool with an Office Web Apps Server, either new or existing:
However, you can deselect the check box and continue along without associating the Office Web Apps Server. This is not recommended, as you won't be able to use any features that rely on the Office Web Apps Server.
Defining a New Office Web Apps Server is easy...all you need is the FQDN of the server:
Once the Office Web Apps Server is defined, Topology Builder will let you continue:
So what is the advantage of using an Office Web Apps Server? From the Overview of Office Web Apps Server TechNet article:
How Lync Server 2013 uses Office Web Apps Server for viewing PowerPoint broadcasts
In Lync Server 2010, PowerPoint presentations are viewed in one of two ways. For users who run Lync 2010, PowerPoint presentations are displayed by using the PowerPoint 97-2003 format and they are viewed by using an embedded copy of the PowerPoint viewer. For users who run Lync Web App, PowerPoint presentations are converted to dynamic HTML files then viewed by using a combination of the customized DHTML files and Silverlight. Although generally effective, this approach did have some limitations:
To help address these issues, and to improve the overall experience of anyone who presents or views PowerPoint presentations, Lync Server 2013 uses Office Web Apps Server to handle PowerPoint presentations. Among other advantages, this new approach allows the following capabilities:
Now that you know what the Office Web Apps Server does, how do you go about preparing to install it? From the Deploy Office Web Apps Server TechNet article:
Installing Required Roles and Services
Windows Server 2008 R2 and Windows Server 2012/2012 R2 have slightly different prerequisites. Be sure to install the correct prerequisites for your operating system.
To prepare a server that runs Windows Server 2008 R2:
Install the following software:
Next, open the Windows PowerShell prompt as an administrator and run the following sample commands to install the required roles and services:
Add-WindowsFeature Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Ink-Handwriting,IH-Ink-Support
To prepare a server that runs Windows Server 2012/2012 R2:
Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-WCF-HTTP-Activation45
Installing Updates
Make sure that you also install any updates to the Office Web Apps Server(s). You will need to download and install the updates listed here: Update center for Office, Office servers, and related products.
Certificates
When creating the certificate request the Office Web Apps Farm make sure that you include SAN entries for the FQDNs of all of the servers in the farm:
If you don't include all of the Office Web App Server 2013 server FQDNs in the SAN of the certificate, you may see the issues here.
Once you have the Office Web Apps Server installed, updated, and configured, the Lync Server 2013 Front End Servers will discover the Office Web Apps Server and you will see the following events in the Event Log on the Front End Servers:
What is the User Experience if you Don't Deploy an Office Web Apps Server?
So what happens you define, but haven't yet deployed an Office Web Apps Server in your environment? The first thing you'll notice is that the Lync Server 2013 Front End Servers will throw the following error in the Event Log:
Office Web Apps Server (WAC) discovery failed, PowerPoint content is disabled.
Attempted Office Web Apps Server discovery Url: https://TEST-OWAS.test.deitterick.com/hosting/discovery/Received error message: The remote name could not be resolved: 'test-owas.test.deitterick.com'The number of retries: 2, since 8/7/2012 10:38:06 PM.Cause: Office Web Apps Server may be unavailable or network connectivity may have been compromised.Resolution:Check HTTPS connectivity from this box to the Office Web Apps Server deployment using the discovery Url.
Also, clients will notice the following error message when they try to share a PowerPoint presentation:
As you can see, the Office Web Apps Server will be an important component in your Lync Server 2013 deployments! Make sure to plan and include it when installing/migrating to Lync Server 2013.
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 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.
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:
I was installing Lync Server 2013 Preview in my lab and while running Step 1 from the Deployment Wizard I got the following message:
I found the Additional Software Requirements TechNet article (http://technet.microsoft.com/en-us/library/gg398686(v=ocs.15)) that lists the additional software that needs to be installed with Lync. I found Windows Identity Foundation and the link in the TechNet article directed me to download the software from here:
http://go.microsoft.com/fwlink/p/?linkId=204657
After downloading the software and running the installer on my Windows Server 2012 Release Candidate Front End Server, I got the following error message:
Installer encountered an error: 0x80096002
The certificate for the signer of the message is invalid or not found.
After doing a little research, I discovered that Windows Identity Foundation is built into Windows Server 2012 Release Candidate as an additional Feature that you can add via Server Manager:
After selecting Windows Identity Foundation 3.5 from the Add Roles and Features Wizard, I clicked Next and then Install. Once the installation wizard completed I ran Step 1 from the Lync Server 2013 Preview again and this time Windows Identity Foundation passed the prerequisite check:
So if you are installing Lync Server 2013 Preview on Windows Server 2012 Release Candidate, make sure that you add Windows Identity Foundation from the Add Roles and Features Wizard!
Update 3/17/13 - Added information about additional update steps from KB2809243.
Just like previous versions of OCS/Lync, there are two methods to update the servers with OCS/Lync cumulative updates. You can use Microsoft Update/WSUS or you can use LyncServerUpdateInstaller.exe. Both ways accomplish the same thing, but what I find is that a lot of customers who use the Microsoft Update/WSUS method forget to then go back and apply any database updates that are needed. This blog post focuses on the LyncServerUpdateInstaller.exe method, as I prefer using it over the Microsoft Update/WSUS method:
Installing Standard Edition Server Cumulative Updates
To apply the latest cumulative updates to a Standard Edition Server, all you need to do is run LyncServerUpdateInstaller.exe and click on Install Updates:
The installer will detect what Lync services have been installed on the server and will display whether or not the latest update has been applied. Once the updates have been installed, restart the server if prompted to do so and then skip down to the "Installing Lync Database Updates" at the bottom of this article.
Installing Enterprise Edition Pool Front End Server Cumulative Updates
With the release of the Lync Server 2013 Cumulative Updates, the process for updating Front End Servers in an Enterprise Edition Pool has changed slightly. Most of the changes have to do with the move to using Windows Fabric to replicate data between the Front End Servers in an Enterprise Edition Pool. With the introduction of Windows Fabric a couple of other concepts were also introduced, User Groups and Upgrade Domains. Both are created and managed by Windows Fabric automatically. You can read more about these new features in the Lync Server 2013: Windows Fabric & User Groups blog post. Because of these new concepts in Lync Server 2013, you will need to update your Front End Servers one at a time, making sure that services are fully restored on that server before you move on to the next Front End Server in the pool in order to make sure that you maintain quorum and at least one copy of all of the user groups. The flow chart below, from the Upgrade or Update Front End Servers TechNet article, walks through the process:
Running Get-CsPoolUpgradeReadinessState should return something similar to the following output:
If the cmdlet returns True for IsReadyForUpgrade for the server you are going to update, you can then run LyncServerUpdateInstaller.exe and apply the necessary updates on the Front End Server:
This process is the same as updating a Standard Edition Server. Once the updates have been installed, restart the server if prompted to do so. Once the server has been restarted, make sure that all of the services have returned to the running state and then run the Get-CsPoolUpgradeReadinessState cmdlet again and repeat the process until all of the Front End Servers in the pool have been updated. You can then skip to the "Installing Lync Database Updates" at the bottom of this article.
Installing Lync Database Updates
Also like previous version of OCS/Lync there Lync database updates that need to be applied. The steps are detailed in the "Step 2: Apply the back end database updates" section in KB2809243. You apply the update by running the following PowerShell cmdlet on one Front End Server in each Enterprise Edition Pool and all Standard Edition Servers in your environment:
Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn FEBE.FQDN -Verbose
Additional Update Steps
Also make sure that you follow the steps in sections "Step 3: Enable the Mobility service" and "Step 4: Enable the Unified Communications Web API" in KB2809243.
Installing Updates on Other Lync Server 2013 Servers
To apply the latest cumulative updates on other Lync Server 2013 servers in your environment, just run LyncServerUpdateInstaller.exe and click on Install Updates.
Update 11/26/13 - I have release an updated version of the reports. This version of the reports includes a Dashboard. See the changelog below for more details on what's new.
The Sample Lync Server Archiving Report is an update to the popular Sample OCS Archiving Report, however this report has been completely redesigned based on feedback from the community. We've expanded the report to include more information from the archiving database and we've changed the layout of the report to make the information easy to consume.
Features
The reports have been tested against Lync Server 2010 and Lync Server 2013 using SQL Reporting Services 2012. You will need to have a functioning SQL Reporting Services server before trying to deploy this report.
Installing the Reports
If there are users that will be running the Dashboard report that don't have dbo rights to the LcsLog database, they may get the following error:
An error has occurred during report processing. (rsProcessingAborted) Query execution failed for dataset 'DatabaseVersion'. (rsErrorExecutingCommand) The EXECUTE permission was denied on the object 'DbGetVersion2', database 'LcsLog', schema 'dbo'.
This is because they don't have access to run the DbGetVersion2 stored procedure. You will need to perform the following additional steps to grant access:
In SQL Server Management Studio, add the user or group that contains the users you want to be able to run the Dashboard report in the Security > Users folder under the LcsLog database. Right-click on the user and select Properties. Make sure that the Securables page is displayed:
Click on the Search button:
Make sure that Specific objects is selected and click OK. Click on the Object Types button:
Select Stored procedures and click OK. Click on the Browse button:
Select [dbo].DbGetVersion2] and click OK:
Click OK:
Select the Grant check box for the Execute permission. Click OK.
The reports are now ready to be used.
Using the Reports
Dashboard
Note: You may need to click on the image above in order to read the text.
The Dashboard report shows you an overview about information contained in the archiving database. You can see information about the SQL Server that hosts the archiving database, as well as, information about the archiving database itself. The number of instant messages and conferences are shown for the time period selected as well as top users for instant messages and conferences.
Search
The Search report is the main report that you will use. As it's name implies, this is the report that you will use to generate your queries against the archiving database. The report requires a couple pieces of data, namely the SIP addresses of the user's that you want to search against and the date range of the search. If you want to search every user or if you only want to search for any communications to/from a single user, use the NULL option. This essentially means any user. You can also pick the SQL Server you want to run the query against.
The results are broken up into two sections, Instant Messages and Conferences. Clicking on the link will drill down into more information for that conversation.
Conversation Details Report
Drilling down into an instant message conversation will display something similar to above. You can see when and who sent the initial message, as well as the client versions of the users, and a transcript of the conversation.
Conference Details Report
Drilling down into a conference shows you a lot of information gathered by the Archiving Server role. You can expand each section to take a look at the data that was captured.
Please leave any questions/comments/feedback in the comments section below.
Click here to download the latest version of the report.
Changelog
November 2013 Release
Search - 1.2
Conversation Details Report.rdl - 1.1
Conference Details Report - 1.1
Dashboard - 1.0
Known Issues
Update 7/11/13 - Added "How Do I View Archived Content?" section
Lync Server 2013 has made a couple of changes to what can be archived and where that archived data can be stored.
What's New?
With the collocation of the Archiving Server role onto the Front End Servers, we've eliminated the need for a separate Archiving Server in Lync Server 2013. This will help to reduce the server footprint required. The Archiving service uses Unified Data Collection Agents that are responsible for capturing data and are located on all Front End Servers and Standard Edition Servers. This also means that MSMQ is no longer needed! It has been replaces by LySS (Lync Storage Service). Also, you now have the choice to use Lync for the archiving store or Exchange Server 2013. However, you can't archive to both locations at the same time. Archiving to Lync is similar to previous versions. The archived information is stored in the LcsLog database in SQL. If you decide to use Exchange Server 2013 are the archiving store, you will be using OAuth and EWS to deliver the archived data to Exchange Server 2013. Archiving also supports SQL mirroring for high availability and the database can be collocated in the same instance as the Front End Server databases, or it can be in a separate instance.
What Information Can Be Archived?
The following types of content can be archived:
The following types of content are not archived:
The Lync Server 2013 Archiving service does not archive Persistent Chat conversations. To archive Persistent Chat conversations, you must enable and configure the compliance service, which is a component that can be deployed with the Lync Server 2013 Persistent Chat Server.
How Archiving to Lync Works
The first thing is to enable archiving. You can do that in the Lync Server 2013 Control Panel or via the Lync Server Management Console:
EnableArchivingIndicates which items (if any) are saved to the archiving database. Valid values are:
Once archiving is enabled and an Archiving Policy is applied to your users, the Archiving Data Collection Agent on each of the Front End Servers in the pool will monitor for IMs and/or Web Conferences that need to be archived. It will send those to be archived communications to the LySS. The LySS will then write it to the appropriate repository, either SQL or Exchange Server 2013.
How Archiving to Exchange Server 2013 Works
The process for archiving to Exchange Server 2013 works similarly to archiving to SQL. When configuring the archiving settings for Exchange Server 2013, remember to check the box for Exchange Server integration.
EnableExchangeArchivingWhen set to True, Lync Server 2013 instant message and conferencing transcripts are stored in Microsoft Exchange Server 2013 rather than a separate SQL Server database. Note that if you enable Exchange archiving then users will be managed by the Exchange archiving policies instead of Lync Server 2013 archiving policies. The default value is False.
Lync Server 2013 will use OAuth to connect to the user's mailbox in Exchange Server 2013. You will need to configure both Lync Server 2013 and Exchange Server 2013 for Oauth. You can refer to the Configure OAuth Authentication TechNet article for Exchange Server 2013 and the Managing Server-to-Server Authentication (Oauth) and Partner Applications TechNet article for Lync Server 2013. For users with a mailbox on Exchange Server 2013 and on In-Place hold the Exchange Archiving Policies override Lync Server archiving policies. You can also set the archiving policy manually for individual users using the Set-CsUser to select the archiving policy:
ExchangeArchivingPolicyIndicates where the user's instant messaging sessions are archived. Allowed values are:
Where in Exchange Server 2013 are Archived Lync Messages Stored?
When the user is set to archive into Exchange Server 2013, the messages are stored in a hidden folder (Recoverable Items > Purges) in their mailbox. One way to verify this is to use EWSEditor:
Opening up the Purges folder will show you all the conversations that have been archived for that user.
Best Practices
One thing to check when setting up archiving to either SQL or Exchange Server 2013 is to run the Get-CsArchivingConfiguration cmdlet make sure that ArchiveDuplicateMessages is set to True:
From the Set-CsArchivingConfiguration TechNet article:
The ArchiveDuplicateMessages parameter specifies how "cross-pool" instant messages should be archived. Consider a simple example: Ken Myer (with an account in Pool 1) sends an instant message to Pilar Ackerman, who has an account in Pool 2. Pilar, in turn, sends a reply to Ken’s instant message. If ArchiveDuplicateMessages is set to False, then (based on a built-in algorithm) the session transcript will be logged in either Pool 1 or Pool 2, but not both. If ArchiveDuplicateMessages is set to True (the default value), the transcript will be logged in both pools.
Another parameter to look at and possibly adjust depending on your company policies is CachePurgingInterval. From the Set-CsArchivingConfiguration TechNet article:
This parameter indicates how often (in hours) the system is purged of transcripts where none of the participants have been enabled for archiving. By design, all group IM sessions and conferencing sessions are recorded when they take place. At the specified interval, the system determines whether any of the participants in these sessions have been enabled for archiving. If the system finds a session where none of the participants have been enabled for archiving, then that transcript will be deleted from the database. The CachePurgingInterval property can be set to any integer value between 4 and 168, inclusive. The default value is 24.
How Do I View Archived Content?
One way to view archived data in SQL you can use the Export-CsArchivingData cmdlet. This will export P2P and conference data to .eml messages.
This will export the conversations to the output folder and create folders for each date that a matching conversation was found:
If you open one of the folders you will see all of the conversations listed. The file names have conf or p2p at the end so that you can quickly tell conferences apart from 1:1 conversations. The conversations are stored as .eml files. This means that you can open them using Outlook.
Opening one of the messages using Outlook will show you the transcript of that conversation:
Another way is to use a third party tool or report to pull information out of the archiving database. I have created a Sample Lync Server Archiving Report that you can use:
You can find more information on the report, including the download link, here.
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.
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 ServerSource: LS User ServicesDate: 10/15/2013 4:02:05 AMEvent ID: 32042Task Category: (1006)Level: ErrorKeywords: ClassicUser: N/AComputer: LyncFE01.contoso.localDescription: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 ServerSource: LS MCU InfrastructureDate: 10/15/2013 4:02:20 AMEvent ID: 61045Task Category: (1022)Level: ErrorKeywords: ClassicUser: N/AComputer: LyncFE01.contoso.localDescription: 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.
Update 6/23/13 - Added information about modifying the Monitoring Reports Data Sources connection string.
I was playing around with the Lync Server 2013 Monitoring Reports and decided to deploy it to both of my SQL Servers in my lab. I have a SQL mirror setup and I installed Reporting Services on both servers. My initial thought was to use a hardware load balancer to distribute the traffic to both Reporting Services Servers. This would also give me high availability within the site for the Monitoring Reports. However, when I went to deploy the Monitoring Reports to the server acting as the SQL mirror, I received the following error:
Cannot grant ReportsReadOnlyRole to user "LAB\srvLyncReports". For details, see the following error message:Exception calling "Create" with "0" argument(s): "Create failed for User 'LAB\srvLyncReports'."
From the error message it looks like the Deploy Monitoring Reports wizard can't assign rights to the service account in SQL. Opening up the SQL instance in SQL Server Management Studio on the SQL mirror you can see that all of the databases are listed and mirroring is working correctly:
However when I go into the properties for the service account and click on the User Mapping page, I received the following message:
One or more databases are inaccessible and will not be displayed in list.
When I tried the same thing on the primary SQL Server, all of the databases are listed correctly and you can see that the service account is assigned ReportsReadOnlyRole:
It appears that you can only assign permissions to databases on the primary SQL Server in the mirror and the Deploy Monitoring Reports wizard won't continue unless it can access the databases, even though the permissions are already set on the primary. At this point the Monitoring Reports are only deployed to the primary SQL Server. They don't get replicated to the mirror, since Reporting Services doesn't participate in the SQL mirroring that is configured. Looking at the SQL Server Reporting Services (SSRS) website on the SQL mirror, you can see that this is the case:
So in order to publish the Monitoring Reports to the SQL mirror you will need to fail the databases (LcsCDR and QoEMetrics) over to the SQL mirror. You can accomplish this by running the Invoke-CsDatabaseFailover cmdlet:
This will make just the Monitoring Server databases active on the SQL mirror. You can confirm this in SQL Server Management Studio:
With the Monitoring Server databases active on the SQL mirror, you can now run the Deploy Monitoring Reports wizard and deploy the reports:
You can confirm the reports were published by going to the SSRS website on the SQL mirror:
Once you have successfully deployed the Monitoring Reports to the SQL mirror you can fail the Monitoring Server databases back to the primary SQL Server. Now that both SQL Servers have the Monitoring Reports deployed, the Lync Server 2013 Control Panel will display both servers under the View Monitoring reports section:
However, if you try to view the Monitoring Reports from the SQL Server that isn't currently the primary for the Monitoring databases, you will receive the following error message:
This is because connection string data sources is pointing to the local SQL Server:
Connection string: data source=(local);initial catalog=LcsCDR
In order to make the reports more resilient, you need to edit the connection string and add the SQL mirror. The connection string should look like:
data source=(local);Failover Partner=LAB-SQL2;initial catalog=LcsCDR
You will need to do this for both Data Sources (CDRDB and QMSDB) on both the primary SQL Server and on the SQL mirror. This way, no matter which server hosts the Monitoring databases and which SSRS website you view the reports from, it will just work! Now I could load balance the SSRS website to both SQL Servers if I wanted.
In the example above, I chose to install SSRS on both the primary SQL Server and on the SQL mirror. If you were just using a single SSRS website, then you would just need to do the last steps to modify the connection string on the Data Sources. That process is documented in the Associating Monitoring Reports with a Mirror Database TechNet article.
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:
November2014
December 2014
When requesting certificates in your Lync Server 2013 environment, you will notice that there is a new certificate type that needs to be requested, OAuthTokenIssuer. What is OAuth and what do we use it for in Lync Server 2013?
OAuth (Open Authorization) is a protocol for server-to-server authentication and authorization. With OAuth, user credentials and passwords are not passed from one computer to another. Instead, authentication and authorization is based on the exchange of security tokens; these tokens grant access to a specific set of resources for a specific amount of time. Lync Server 2013 supports three server-to-server authentication scenarios. With Lync Server 2013 you can:
You can read more about OAuth and it's uses in the Managing Server-to-Server Authentication (Oauth) and Partner Applications TechNet article.
As you complete the request for the OAuthTokenIssuer certificate and view the certificate, you'll see that it looks something similar to:
One important thing to note about the OAuthTokenIssuer certificate, that is different from other certificates in Lync Server 2013, is that the OAuthTokenIssuer certificate is a global certificate:
So what does that mean? It means that the same OAuthTokenIssuer certificate needs to be used by all of the Lync Server 2013 servers. In order to assure this, when you assign this certificate, it is replicated via the CMS and is assigned to all of the Lync Server 2013 servers that require OAuth. If you look in the directory where the Lync Server 2013 logs are stored (C:\Users\<username>\AppData\Local\Temp), you will see a log file similar to:
ReplicateCMSCertificates-[2012_07_31][11_49_20].html
If you open that log file it will look something similar to:
If you wait for replication to succeed and then look at another Lync Server 2013 server, you will see that the OAuthTokenIssuer certificate has been replicated and assigned to that server:
So what happens if I request an OAuthTokenIssuer certificate on multiple servers? In that case whichever certificate is replicated to the CMS last will be used by all of the Lync Server 2013 servers.
So when requesting the OAuthTokenIssuer certificate in Lync Server 2013, remember to only request it once and sit back and let CMS replication take care of the rest!
Update 10/31/13 - Added an additional SQL query if you have the Monitoring Server available.
A question that comes up from customers from time to time is how do I get a list of what users are actually using OCS/Lync? While there's no built in report to easily tell you what users are actually signing into the environment, there is some information stored in SQL that you can use to help figure out adoption rate in your environment. The information we're looking for is stored in the LastNewRegisterTime column in the HomedResourceDynamic table in the rtcdyn database. You can run the following queries* to pull back the user's SIP URI and their last registration time:
For Lync Server 2010/2013
USE rtcdynSELECT rtc.dbo.Resource.UserAtHost, rtcdyn.dbo.HomedResourceDynamic.LastNewRegisterTimeFROM rtcdyn.dbo.HomedResourceDynamicINNER JOIN rtc.dbo.Resource on rtc.dbo.Resource.ResourceId = rtcdyn.dbo.HomedResourceDynamic.OwnerIdINNER JOIN rtcdyn.dbo.RegistrarEndpoint ON rtcdyn.dbo.RegistrarEndpoint.OwnerId = rtcdyn.dbo.HomedResourceDynamic.OwnerIdWHERE IsServerSource = 0ORDER BY UserAtHost
Which produces the following output:
For OCS 2007 R2
USE rtcdynSELECT rtc.dbo.Resource.UserAtHost, rtcdyn.dbo.HomedResourceDynamic.LastNewRegisterTimeFROM rtcdyn.dbo.HomedResourceDynamicINNER JOIN rtc.dbo.Resource ON rtc.dbo.Resource.ResourceId = rtcdyn.dbo.HomedResourceDynamic.OwnerIdORDER BY UserAtHost
Note: A user with a LastNewRegisterTime of NULL is a user that has never logged in, but has been added to someone's contact list. You would want to remove these entries from your exported results.
While the query to gather the information is very similar the SQL instance that you connect to to retrieve this information is different depending on which version you're using. In OCS 2007 R2 all of this information was stored in the rtcdyn database on the SQL instance that you defined when first creating the pool. Because of the changes to the registrar functionality in Lync Server 2010 to support survivability, the information that we're looking for has moved to the RTCLOCAL SQL instance that is stored on each registrar.
You can see this if you compare the HomedResourceDynamic table in the rtcdyn database between the Front End Pool SQL Instance and one of the Front End Server's RTCLOCAL SQL Instance:
Front End Pool SQL Instance
RTCLOCAL SQL Instance
For row 2, OwnerId 12 corresponds to my Lync test user that has logged into the client. You can see that the information that we're looking for, LastNewRegisterTime, only gets populated in the RTCLOCAL SQL instance on the Front End Server. So this means that in Lync Server 2010 you don't have one place you can go for all of the users homed on that pool. You will need to run the query and aggregate the data from every registrar in the pool, as well as any SBA/SBS deployed. The other issue that comes up in an Enterprise Edition pool with multiple Front End Servers is that when users fail-over to another Front End Server in the pool, there is a record created in that Front End Server's RTCLOCAL rtcdyn database. After you run the queries and have exported all of the results you would want to clean up the duplicate entries so that you weren't reporting inflated numbers.
Even though there's a little work involved in gathering the information this is a fairly easy way to gauge adoption and see which of your users are actually using the OCS/Lync.
Using the Lync Server 2013 Monitoring Server
If you have the Monitoring Server role configured in your environment, and for Lync Server 2013 everyone should!, you can use information contained in the LcsCDR database to pull back the last time a user signed in. You can run the following query* to pull back the user's SIP URI and their last login time:
USE LcsCDRSELECT dbo.Users.UserUri, dbo.UserStatistics.LastLogInTimeFROM dbo.UserStatisticsJOIN dbo.Users ON dbo.Users.UserId = dbo.UserStatistics.UserIdORDER BY UserUri
The advantage to using the Monitoring Server to obtain this data is that unlike the information contained in the rtcdyn database, the information from the LcsCDR data will persist even when the user isn't signed into Lync.
*These queries are provided for you to use at your own risk. Please make sure you test before running in a production environment.
I've run into this issue a couple times when deploying Lync Server 2013 in my lab and at customer sites. Topology Builder makes it very easy to deploy your Lync servers quickly, but in Lync Server 2013, there's one gotcha you need to be aware of when initially deploying multiple Lync Server 2013 servers at once. And it has to do with the OAuth certificate used in Lync Server 2013. I've previously written about OAuth and its role in Lync Server 2013 here: OAuth Certifcate in Lync Server 2013.
The gotcha is that you need to have the OAuthTokenIssuer certificate assigned before you can complete Step 3 in the Deployment Wizard and proceed to starting services. If this is the first set of Lync Server 2013 servers you're deploying, the OAuthTokenIssuer certificate was replicated to the CMS when you assigned it to the first Lync Server 2013 server. The problem arises if you have already completed Step 1 in the Deployment Wizard on the other Lync Server 2013 servers that require the OAuthTokenIssuer certificate.
Part of Step 1 in the Deployment Wizard is to connect to the CMS and grab a copy of the current topology. This copy of the topology doesn't yet have the OAuthTokenIssuer certificate in it.
When you get to Step 3 in the Deployment Wizard, you will see that the OAuthTokenIssuer certificate hasn't replicated to this Lync server...and it won't. This server is looking a the local copy of the CMS that was imported during Step 1. That means that in order for this server to know that there's an OAuthTokenIssuer certificate in the CMS that it's supposed to use, you need to get the updated topology replicated to this server. There are two ways to accomplish this. The first way is to use the Export-CsConfiguration and Import-CsConfiguration with the -LocalStore parameter. The second way is to just let CMS replication happen. You will need to make sure that at least one Front End Server is operational in the pool configured to host the CMS. Then on the other Lync Server 2013 servers that need the OAuthTokenIssuer certificate replicated to it, make sure that the Lync Server Replica Replicator Agent service is started:
Once the Lync Server Replica Replicator Agent service is started, you will be waiting for replication to happen and the following events to appear in the Lync Server event log:
Once you see Event ID 3038, the CMS has replicated the OAuthTokenIssuer certificate to the server. You can also check Get-CsManagementStoreReplicationStatus and make sure that the server is up-to-date:
UpToDate : TrueReplicaFqdn : LAB-LS15-DIR1.lab.deitterick.comLastStatusReport : 11/24/2012 8:15:36 PMLastUpdateCreation : 11/24/2012 8:08:05 PMProductVersion : 5.0.8308.0
If you refresh the Certificate Wizard or run Step 3 from the Deployment Wizard again, you will now see the OAuthTokenIssuer certificate assigned to the server:
You can now complete Step 3 and continue on with Step 4 in the Deployment Wizard.
While Topology Builder makes it very easy to deploy your entire Lync Server 2013 environment in one shot, you just need to be aware of how and when the OAuthTokenIssuer certificate is replicated to your Lync Server 2013 servers.
Update 3/17/13 - Added information about .NET 3.5 installation error on Windows Server 2012.Update 9/19/12 - Added HTTP Activation for Windows Server 2012.Update 7/20/12 - Added Dynamic Content Compression and additional information for Windows Server 2012.
The following IIS role services must be installed before attempting to install this product:
To make installing the role services easier, here are the PowerShell commands. For Windows 2008 R2 SP1, open a PowerShell command window as Administrator and run the following commands:
Import-Module ServerManagerAdd-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Http-Errors,Web-Asp-Net,Web-Http-Logging,Web-Log-Libraries,Web-Http-Tracing,Web-Windows-Auth,Web-Client-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Web-Scripting-Tools
For Windows Server 2012/2012 R2, open a PowerShell command window as Administrator and run the following commands:
Import-Module ServerManagerAdd-WindowsFeature Web-Static-Content,Web-Default-Doc,Web-Http-Errors,Web-Asp-Net,Web-Asp-Net45,Web-Http-Logging,Web-Log-Libraries,Web-Http-Tracing,Web-Windows-Auth,Web-Client-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Web-Scripting-Tools,NET-WCF-HTTP-Activation45
Note: On Windows Server 2012/2012 R2, you may get the following error message when you try to run the Add-WindowsFeature cmdlet above:
Add-WindowsFeature : The request to add or remove features on the specified server failed.Installation of one or more roles, role services, or features failed.The source files could not be downloaded.Use the "source" option to specify the location of the files that are required to restore the feature. For more information on specifying a source location, see http://go.microsoft.com/fwlink/?LinkId=243077. Error: 0x800f0906
This is because the .NET Framework 3.5 is not included in Windows Server 2012/2012 R2 and needs to be either downloaded from Windows Update or you need to provide the location to the Windows Server 2012/2012 R2 installation media. You can read more about this in the Error codes when you try to install the .NET Framework 3.5 in Windows 8 or in Windows Server 2012 KB article. To provide the location of the Windows Server 2012/2012 R2 installation media, run the Add-WindowsFeature cmdlet from above and add the -Source parameter with the location of the Windows Server 2012/2012 R2 installation media, i.e -Source D:\sources\sxs.
Office Communicator allows you to create groups to sort your contacts. You can also arranged those groups in any order you see fit. So you can move a group that you use frequently to the top of the list, and move others to the bottom. But have you ever wanted to reset that order back to default? Maybe you'd rather have the groups alphabetized. If you have a lot of groups, doing this manually might be tedious. Instead there is an easier way. If you open regedit and navigate to the following key:
HKCU\Software\Microsoft\Communicator\<SIP URI>\GroupStateCacheU
If you have moved groups around, you will see the following value. If you haven't moved the groups around, this value will not be there:
SortGroups REG_BINARY
If you delete this value, close Communicator, and sign back in, you will see that your groups have been reordered.
Before
After
*One thing to note is that the Recent Contacts group will always be the first group in the list. You can always turn off the Recent Contacts group if you don't want it shown in the contact list.
I ran across this today with a customer. We were setting up Exchange UM to connect to Lync and while that was working just fine, users could leave voicemail messages for other users, the email messages weren't being delivered to the user's mailbox. Looking at the Application Event Log on the UM Server we say the following error message:
Log Name: ApplicationSource: MSExchange Unified MessagingDate: 2/11/2013 11:22:08 AMEvent ID: 1423Task Category: UMCoreLevel: ErrorKeywords: ClassicUser: N/AComputer: SERVERNAMEDescription:The Unified Messaging server encountered an error while trying to process the message with header file "C:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\voicemail\8e22c540-bc77-4f72-9a60-758a04a1522b.txt". Error details: "Microsoft.Exchange.Net.ExSmtpClient.TlsApiFailureException: A TLS API failure occurred. Error = 0x80090301
The TLS API failure was being cause because they had applied KB931125 to the server. You can read more about this issue from the Windows Server Blog. Unfortunately this causes the Trusted Root Certificate store to grow rather large and thus causes the TLS API failure. The fix is to either delete any unneeded root certificates or run the Fix it from KB2801679.
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:
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:
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:
From the Lync 2013 client, the PowerPoint presentation was loaded successfully:
I went to look for the client uccapilog file, but it wasn't in the location I was expecting. In previous versions of Communicator and Lync 2010, the client tracing folder was stored in:
C:\Users\<username>\Tracing
In Lync 2013, the client tracing folder in now stored in the following location:
C:\Users\<username>\AppData\Local\Microsoft\Office\15.0\Lync\Tracing
Update 4/2/13 - Updated for release of Android client.Update 3/12/13 - Updated for release of iOS client.
With the release of the Lync Server 2013: February 2013 Cumulative Updates, additional features are available with Lync mobility. In order to take advantage of these new features, you will need to install the Lync 2013 version of the mobile client for the respective mobile platform. The Lync 2013 mobile client will be released for Windows Phone, iOS, and Andriod through their respective marketplace. The time and availability of the mobile apps will vary between each marketplace.
There are a bunch of new features in both the Lync 2013 mobile client and the server. The list below has some of the important changes:
Deployment Considerations
Since A/V is now supported over 3G/4G, or Wi-Fi the Edge Server plays a larger role in mobility deployments. In the diagram below, you can see that the mobile client will still send signaling information via the Reverse Proxy, but it will now send media via the A/V Edge interface on the Edge Server:
When in co-existence with Lync Server 2010, your Lync autodiscover URLs can still resolve to a Lync Server 2010 Front End Server or Director. The Lync autodiscover service will be return the correct external web services FQDN for your user based on your homed pool. The media traffic from the Lync 2013 mobile client can also use a Lync Server 2010 Edge Server.
Windows Phone Client Interoperability
From the table above, you can see that the Lync 2013 Windows Phone mobile client can only be installed on Windows Phone 8 and can only connect if the user is homed on a Lync Server 2013 pool that has the cumulative update installed. If you try to sign in to a Lync Server 2010 Front End Server or a Lync Server 2013 Front End Server without the cumulative update using the Lync 2013 mobile client you will see the following error message:
Error: "You can't sign in with this version of Lync. Please install Lync 2010."
iOS and Android Client Interoperability
The Lync 2013 iOS client has been released for iPhone and iPad. It is now available in the iTunes store. You will need to be running iOS 6.0 or later. Keep in mind that for this client to work you will need to be homed on a Lync Server 2013 Standard Edition Server or Enterprise Edition Pool with at least the Lync Server 2013: February 2013 Cumulative Updates installed. Also the Lync 2013 Android client has been released. It is now available in the Google Play store. The list of supported Android phones is listed in KB2829747.
Update 2/26/14 - This issue has been resolved with the release of Service Pack 1 for Office 2013. You can get more information here.
I ran across this while testing an issue a reader of my blog posted in the comments of an article I wrote about the Lync Basic 2013 client. They had mentioned that when a user using the Lync Basic 2013 client was set to A/V disabled the options for A/V were still presented in the client. In my testing I found this to be true and in fact the options were not only presented to the user, but A/V wasn't blocked if the user tried to initiate an A/V call to another user. For my testing I was using version 15.0.4420.1017 of the Lync Basic 2013 client. You can see in the screen shot below that even though the user is set to A/V disabled in Lync, the Phone tab and the Call Forwarding options still appear and the user is actually in a call with another user:
In addition, the options for starting an A/V call with another user are available:
Also, when looking at the A/V disabled user's presence from another client, you can see that they show as "Video Capable", even though they should be disabled for video:
If you compare this to the same user signed into the Lync 2013 client, you can see that the Phone tab and the Call Forwarding options are removed, as expected:
Also, the options for initiating an A/V call are removed as well:
So how does the Lync client know what features to make available when the user signs in? The answer is through information received by the client via in-band provisioning. The Lync client sends out a SIP SUBSCRIBE requesting provisioning information:
SUBSCRIBE sip:wcooper@test.deitterick.com SIP/2.0
...
Content-Type: application/vnd-microsoft-roaming-self+xml
The response is a SIP/2.0 200 OK and contained in the response is the setting we're interested in:
<telephonyMode>NoAudioVideo</telephonyMode>
The telephonyMode setting can contain a couple of different values, depending on what the user is configured for:
It appears that currently the Lync Basic 2013 client is ignoring this setting and is allowing the user to initiate A/V sessions whether the user is enabled to do so or not.
Another question that comes up from customers, especially when we're talking about migrations and updating clients, is how do I figure out which users are running the old version of the client? You can run the following queries* to pull back the user's SIP URI and the client version that they're signed into:
USE rtcdynSELECT COUNT(*) as Occurrences,CAST(rtcdyn.dbo.RegistrarEndpoint.ClientApp as varchar(100)) as 'Client Version'from rtcdyn.dbo.RegistrarEndpointWHERE IsServerSource = 0group by CAST(rtcdyn.dbo.RegistrarEndpoint.ClientApp as varchar(100))order by CAST(rtcdyn.dbo.RegistrarEndpoint.ClientApp as varchar(100))
SELECT rtc.dbo.Resource.UserAtHost as 'SIP Address', CAST(rtcdyn.dbo.RegistrarEndpoint.ClientApp as varchar(100)) as 'Client Version'FROM rtcdyn.dbo.RegistrarEndpointINNER JOIN rtc.dbo.ResourceON rtcdyn.dbo.RegistrarEndpoint.OwnerId = rtc.dbo.Resource.ResourceIdWHERE IsServerSource = 0
For Lync this query needs to be run against each local registrar's SQL instance (RTCLOCAL).
USE rtcdynSELECT COUNT(*) as Occurrences,CAST(rtcdyn.dbo.Endpoint.ClientApp as varchar(100)) as 'Client Version'from rtcdyn.dbo.EndpointWHERE IsServerSource = 0group by CAST(rtcdyn.dbo.Endpoint.ClientApp as varchar(100))order by CAST(rtcdyn.dbo.Endpoint.ClientApp as varchar(100))
SELECT rtc.dbo.Resource.UserAtHost as 'SIP Address', CAST(rtcdyn.dbo.Endpoint.ClientApp as varchar(100)) as 'Client Version'FROM rtcdyn.dbo.EndpointINNER JOIN rtc.dbo.ResourceON rtcdyn.dbo.Endpoint.OwnerId = rtc.dbo.Resource.ResourceIdWHERE IsServerSource = 0
Both queries produce the following output:
The first query returns each client version that a user is currently signed into and the number of occurrences of each version. This is very similar to the client version summary query on the database tab in the OCS Management Console:
The second query will list each user's SIP URI and the associated client version. In the example above, Jeff Wallace is signed into two endpoints and each one is listed separately. These queries are very useful to make sure that users are using the latest version of the client and if not, which users need to be updated. The important thing to remember is that this data is only stored for users that are currently signed into OCS/Lync, so they will only give you a point in time snapshot of your environment.
Update 4/8/13 - Added information about change to KB2760445 automatically updating.
I came across this issue in my lab the other day. I noticed that in Hyper-V Manager both of my Office Web Apps Servers had really high CPU utilization:
It's pretty rare that one of my VMs would be doing that much to consume that much of the CPU, so I looked at Task Manager on both of the VMs and saw that they were both pegging the processor:
Neither server should be this busy, so I checked out the Application Event Log to find out what was going on and found the following errors:
Log Name: ApplicationSource: .NET RuntimeDate: 3/29/2013 6:11:08 PMEvent ID: 1026Task Category: NoneLevel: ErrorKeywords: ClassicUser: N/AComputer: LAB-OWA1.lab.deitterick.comDescription:Application: WordViewerWfeWatchdog.exeFramework Version: v4.0.30319Description: The process was terminated due to an unhandled exception.Exception Info: System.TypeInitializationExceptionStack: at Microsoft.Office.Web.Common.ServiceInstanceFinder.GetLocalAgentInstance(Microsoft.Office.Web.Common.OfficeServiceType) at Microsoft.Office.Web.Common.WatchdogHelper.PrepareRegistrations(Microsoft.Office.Web.Common.OfficeServiceType) at Microsoft.Office.Web.Common.WatchdogHelper.WatchMachines(Microsoft.Office.Web.Common.OfficeServiceType, CheckServiceInstance, Microsoft.Office.Web.Common.OfficeServiceType, System.String) at Microsoft.Office.Web.WordViewerWatchdog.Wfe.Program.Main()
Log Name: ApplicationSource: Application ErrorDate: 3/29/2013 6:11:08 PMEvent ID: 1000Task Category: (100)Level: ErrorKeywords: ClassicUser: N/AComputer: LAB-OWA1.lab.deitterick.comDescription:Faulting application name: WordViewerWfeWatchdog.exe, version: 15.0.4481.1000, time stamp: 0x50ee5a74Faulting module name: KERNELBASE.dll, version: 6.2.9200.16451, time stamp: 0x50988aa6Exception code: 0xe0434352Fault offset: 0x000000000003811cFaulting process id: 0x17e8Faulting application start time: 0x01ce2cca4f9a878fFaulting application path: C:\Program Files\Microsoft Office Web Apps\WordViewerWfeWatchdog\WordViewerWfeWatchdog.exeFaulting module path: C:\Windows\system32\KERNELBASE.dllReport Id: 8e4fbe96-98bd-11e2-93f0-00155d010f10Faulting package full name: Faulting package-relative application ID:
There were tons of these errors in the Application Event Log. Recently an update for Office Web Apps Server 2013 was installed:
Since I had Microsoft Update enabled on the servers, the update was installed automatically:
Unfortunately Office Web Apps Server 2013 has specific steps that need to be followed in order to correctly apply updates. Those steps are detailed in the Apply software updates to Office Web Apps Server TechNet article. Since I let Microsoft Update automatically install the updates, the machines weren't removed from the Office Web Apps Server farm before the update was applied, which is what caused the errors listed above. Also unfortunate is that KB2760445 doesn't have an uninstall option. This means that to fix this issue you will need to uninstall Office Web Apps Server 2013, reinstall, and setup the Office Web Apps Server farm again:
Once Office Web Apps Server 2013 is installed again, and before you recreate the Office Web Apps Server farm, download and install KB2760445.
Note: You may need to restart the server in order for the Office Web Apps Server 2013 PowerShell cmdlets to be loaded back into PowerShell by default.
After installing KB2760445 and recreating the Office Web Apps Server farm, CPU utilization on the servers is back to normal:
In the future, to correctly install updates for Office Web Apps Server 2013, follow the steps listed in the Apply software updates to Office Web Apps Server TechNet article.
Note: A change was made to the way Microsoft Update handles KB2760445. The update is no longer installed automatically during the Windows Update maintenance window. An administrator will now need to manually installed the update:
Before applying the update, you will still need to follow the steps listed in the Apply software updates to Office Web Apps Server TechNet article!
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.