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

• Dashboard report to provide an overview about information in the archiving database
• View detailed information about P2P IM conversations and conferences
• Search for IMs and Conferences by SIP address and date
• Select from multiple Lync Server Archiving databases to search against
• Web-based SSRS reports can be used by anyone with rights and a web browser

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

1. Download the latest version of the Sample Lync Server Archiving Report
2. Extract the zip file
3. Open Report Manager – http(s)://<SRS Server>/Reports
4. Click on New Folder
5. Give the folder a name – i.e. LyncArchivingReport
6. Click OK
7. Click on the folder you just created
8. Click on Upload File
9. Browse to the location where you extracted the LyncArchivingReport zip file and select Search.rdl
10. Click OK to upload the report
11. Repeat Steps 9 and 10 for the rest of the reports
12. (Optional) - To remove the reports from the default view, since you can't directly access them:
1. Go to the properties of the Conference Details Report by clicking on the drop-down and selecting Manage 
2. Click on Hide in tile view
3. Click Apply
4. Go back to the LyncArchivingReport folder and repeat for the Conversation Details Report
13. To configure the report to use your SQL Server(s), you will need to open the Search report in SQL Server Report Builder
1. Click on the drop-down for the Search report and select Edit in Report Builder
2. If this is the first time you've used Report Builder on this computer, select Run when the Do you want to run this application? prompt appears
14. In SQL Server Report Builder, in the Report Data section, expand Parameters and double-click on SqlConnectionString
15. In the Report Parameter Properties window, click on Available Values
16. Click on Specify values
17. Click on Add
18. Enter your Lync Server Archiving Server SQL Server information in boxes in the following format:
1. Label: SQL Server Friendly Name
2. Value: Data Source=<SQL Server FQDN\Instance>;Failover Partner=<SQL Server FQDN\Instance>;Initial Catalog=LcsLog
1. i.e. Data Source=LAB-SQL1\Lync;Failover Partner=LAB-SQL2\Lync;Initial Catalog=LcsLog
2. Note: If you're not using SQL Mirroring for the LcsLog database, then you don't need to include the Failover Partner piece.
19. Repeat Steps 17 and 18 for all Lync Server archiving databases in your environment
20. (Optional) - If you only have one archiving database, you can set the default value so that you don't need to select the SQL Server every time you use the report
1. Click on Default Values
2. Click on Specify values
3. Click on Add
4. In the drop down, select your SQL Server
5. Click on General
6. Select Hidden under Select parameter visibility
21. Click OK
22. Click Save in the Quick Access Toolbar to save the changes to the reporting server
23. Close SQL Server Report Builder
24. Repeat Steps 13 through 23 for the Dashboard report.

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

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

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

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

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

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

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

• Increased width of "Data from" textbox
• Changed End Date range to -1 day from the current date
• Added support for SQL mirroring
• Other formatting changes

Conversation Details Report.rdl - 1.1

• Increased width of "Data from" textbox
• Fixed conversations missing from federated contacts

Conference Details Report - 1.1

• Increased width of "Data from" textbox
• Fixed column formatting issues - changed to a landscape layout
• Added Expand All/Collapse All toggle
• Added additional sorting options
• Other formatting changes

Dashboard - 1.0

• Initial Release

Known Issues

1. Meeting Data Location for Lync Server 2010 conferences is not a valid link.
2. All times are displayed in UTC.  Trying to convert the times to local time zones automatically isn't possible.
3. IM conversations that contain Unicode characters may not be displayed correctly.  SSRS doesn't natively have a way to parse RTF text.  If the conversation is stored in the archiving database in RTF, some non-Latin characters may be stored as Unicode.  This means that the report will not display those IM messages correctly.

Update 6/2/13 - Sample Lync Server Archiving Report is now available!  Click here for more information.
Update 5/29/13 - Updated report download link and moved report to TechNet Gallery.
Update 11/26/10 - OCSArchivingReport - 0.6 is available.  Fixed an issue with RTF text not displaying in the results.
Update 8/26/10 - This blog post will serve as the official home of the OCSArchivingReport.  Please post any questions/feedback in the comments.
Update 8/9/10 - OCSArchivingReport - 0.5 is available.  Fixed an issue with multiparty IMs displaying incorrect results.  Fixed the form automatically pulling data when loaded.

An easy way to get information out of the archiving database has been a common request from customers, but unfortunately a canned report wasn't inculded out of the box.  That is why I have created this SQL report as an easy way to query the database. 

It builds on the functionality provided by the Archiving PowerShell script that was written (http://communicationsserverteam.com/archive/2009/09/28/584.aspx) and adds a GUI interface, the ability to filter by date, and message formatting.  It has been tested against OCS 2007 R2 and SQL Reporting Services 2005.  You will need to have a functioning SQL Reporting Services server before trying to deploy this report.

Installation

1. Download the latest version of the OCSArchivingReport.
2. Open Report Manager – http(s)://<SRS Server>/Reports
3. Click on New Folder
4. Give the folder a name – i.e. OCSArchivingReport
5. Click OK
6. Click on the folder you just created
7. Click on Upload File
8. Browse to the location where you downloaded OCSArchivingReport.rdl and select the file
9. Click OK to upload the report
10. Click on New Data Source
11. Enter LcsLog for the Data Source name
12. Enter Data Source=<SQL Servername>;Initial Catalog=LcsLogfor the Connection String
    1. Replace <SQL Servername> with your SQL server\instance
13. Select the Windows integrated security radio button
14. Click OK
15. Click on OCSArchivingReport
    1. You will see the following error: The report server cannot process this report. The data source connection information has been deleted. (rsInvalidDataSourceReference).  This is normal, since we haven’t linked the report to the data source we just created.
16. Click on the Properties tab
17. Click on Data Sources in the left-hand column
18. Make sure A shared data source radio button is selected
19. Click the Browse button
20. Expand OCSArchivingReport and click on LcsLog
21. Click OK
22. Click Apply

The report is now linked to the data source and ready to be used.

Using the Report

The report allows you to enter the SIP URI of any 2 users that you want to view archived messages from.  If you enter “Any User” (case sensitive) for either of the user input boxes, you are able to view any message from any user to a specific user as well as any user to any other user.  You can use the Start Date and End Date to narrow down the search to a specific date range.  Once you have entered all of the inputs, click on View Report.
The results of the search are shown.  The First User column represents the sender of the message and the Second User column represents the recipient of the message.  The Message column shows the message that was sent as well any formatting on the message.  Changing Show Toast to Yes will show the toast messages as well as the Toast column.

Click here to download the latest version of the report.

A big Thank You to Rich Thorp for helping me put together this report!

* This is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of Use (http://www.microsoft.com/info/cpyright.htm).

Update 1/1/11 - Updated post with more information on what happens with an Enterprise Edition pool and how EndpointConfiguration.cache adds a wrinkle to the whole process.

In Lync Server 2010 the Director is now a dedicated role.  Because there's an actual Director role now you don't have to worry about users accidentally getting homed on the Director, like you did in OCS 2007 R2.  But the real reason to take another look at the Director role in Lync Server 2010 has to do with the new resiliency option.  Specifically the ability to associate a backup registrar pool.  The Director plays an important role in informing the clients what their primary and backup registrars are.

So the natural question that comes up is "Is a Director required for the backup registrar ability to work?".  The answer to that is technically no, it isn't required.  The Director isn't providing any special functionality.  Just like in OCS 2007 R2, the Front End Servers have the same Registrar service/functionality as the Director.  If a user registers against a registrar that isn't their primary registrar, a 301 Redirect will be returned that includes the user's primary and backup registrar.  A Front End Server or a Director both have the ability to do this.  There is another option described below, but it has some limitations of it's own.  Using a Director is the recommended and simplest way to take advantage of this functionality.

The trace below shows the response from the Director to the client during client sign in: 

12/20/2010|11:56:24.001 728:A3C INFO  :: Data Received - 172.16.8.8:5061 (To Local Address: 172.16.8.7:50327) 756 bytes:
12/20/2010|11:56:24.001 728:A3C INFO  :: SIP/2.0 301 Redirect request to Home Server
Authentication-Info: TLS-DSK qop="auth", opaque="E44B1AA4", srand="50E900F0", snum="1", rspauth="23003a3babd1b5a8b3b02c34372b07e66a8b0bfa", targetname="BETA-LS14-DIR.beta.deitterick.com", realm="SIP Communications Service", version=4
From: <sip:acooper@beta.deitterick.com>;tag=4787346104;epid=c68d71323c
To: <sip:acooper@beta.deitterick.com>;tag=FBF2A5131E02B962310A8078B52D77C3
Call-ID: a59c3223b23b4d398d4c77b95769e1b1
CSeq: 4 REGISTER
Via: SIP/2.0/TLS 172.16.8.7:50327;ms-received-port=50327;ms-received-cid=100
Contact: <sip:beta-ls14-se1.beta.deitterick.com:5061;transport=TLS>;q=0.7
Contact: <sip:beta-ls14-se2.beta.deitterick.com:5061;transport=TLS>;q=0.3
Expires: 2592000
Content-Length: 0


12/20/2010|11:56:24.001 728:A3C INFO  :: End of Data Received - 172.16.8.8:5061 (To Local Address: 172.16.8.7:50327) 756 bytes

The two important lines from the redirect are these:

Contact: <sip:beta-ls14-se1.beta.deitterick.com:5061;transport=TLS>;q=0.7
Contact: <sip:beta-ls14-se2.beta.deitterick.com:5061;transport=TLS>;q=0.3

The Director passes back to the client both the user's primary and backup registrar.  The q= value tells you if the server is the primary or secondary.  In this case, beta-ls14-se1.beta.deitterick.com is the primary, and beta-ls14-se2.beta.deitterick.com is the backup.  The q=0.7 specifies the primary registrar and the q=0.3 specifies the backup registrar.

If we take the Director out of the environment and set the SRV record to point to beta-ls14-se1.beta.deitterick.com any user that is homed on that pool won't be notified of their backup registrar.  Looking at the trace below from a user homed on that server you can see that there isn't a 301 Redirect returned to the client:

This means that the client doesn't know about it's backup registrar.  If the server/pool that the user is homed on is unavailable the user will be unable to register with the backup registrar.

There are two ways to resolve this issue.  The first is to include a Director in your design.  The SRV record for automatic client log on will point to the Director and users will be returned their primary and backup registrars.  The second option is to use multiple SRV records with different priorities.  Using this method you can specify both the primary and backup registrar in DNS for automatic client log on so that in the event that the primary registrar is unavailable the client has a way to contact the backup registrar.

The only issue with the second option is that it doesn't scale very well.  For a small environment with two pools, this would work fine, but for a large environment with multiple pools in multiple data centers this may not be the most efficient option and a Director might make more sense.

Enterprise Edition Pool

An Enterprise Edition pool behaves pretty much the same as a Standard Edition Server, with one difference, there are multiple registrars in the pool that the user can register with.  In Lync Server 2010 a user homed on an Enterprise Edition pool has one Front End Server defined as their primary registrar.  In Lync Server 2010 the Registrar service has been split out into it's own component with no shared registrar database anymore.  Because of this all of the endpoints for a user need to register against the same registrar server in the user's home pool.  What that all means is that depending on the Front End Server you try to register with, you may or may not get a 301 Redirect to your home server returned to you.  If you try to register with the registrar that is defined as your primary registrar, you won't be redirected.  If you try to register with any of the other Front End Servers in the pool, you'll get the 301 Redirect.  And as I mentioned above, the 301 Redirect is where the client is informed of the user's backup registrar.

So another question that comes up is "How do I figure out with Front End Server in the pool that is defined as a user's primary registrar?".  The answer is pretty simple...PowerShell.

You can use the PowerShell cmdlet Get-CsUserPoolInfo to display a user's primary and backup registrars as well as the order of Front End Servers that the user will register against.

Get-CsUserPoolInfo -Identity lcarter@beta.deitterick.com

PrimaryPoolFqdn                     : ls14pool.beta.deitterick.com
BackupPoolFqdn                      : beta-ls14-se2.beta.deitterick.com
UserServicesPoolFqdn                : ls14pool.beta.deitterick.com
PrimaryPoolMachinesInPreferredOrder : {1:5-2, 1:5-1}
BackupPoolMachinesInPreferredOrder  : {1:3-1}

As you can see, the user's primary pool is ls14pool.beta.deitterick.com and their backup pool is beta-ls14-se2.beta.deitterick.com.  For their primary pool they will registrar against server 1:5-2 first, then 1:5-1.  That's great, but how do you match those identifiers up with the actual Front End Server FQDNs?  The answer to that is more PowerShell, of course!

If you pipe the command above to the Select-Object cmdlet, you can expand the properties of PrimaryPoolMachinesInPreferredOrder.  I also piped all of that to a Format-List to pull out the important pieces from the output:

Get-CsUserPoolInfo -Identity lcarter@beta.deitterick.com | Select-Object -ExpandProperty PrimaryPoolMachinesInPreferredOrder | Format-List MachineId,Fqdn

MachineId : 1:5-2
Fqdn      : beta-ls14-ee2.beta.deitterick.com

MachineId : 1:5-1
Fqdn      : beta-ls14-ee1.beta.deitterick.com

So from this you can see that beta-ls14-ee2.beta.deitterick.com is the user's primary registrar.

Now that we know which Front End Server in the pool the user will be redirected to we know that if they try to register with beta-ls14-ee2.beta.deitterick.com, no 301 Redirect will be returned.  If they try to register with beta-ls14-ee1.beta.deitterick.com, a 301 Redirect will be returned and it will include the backup registrar.

In this trace, the user contacts their primary registrar (172.16.8.10), so no 301 Redirect is returned:

12/31/2010|13:18:17.346 630:358 INFO  :: Sending Packet - 172.16.8.10:5061 (From Local Address: 172.16.8.7:50430) 795 bytes:
12/31/2010|13:18:17.346 630:358 INFO  :: REGISTER sip:beta.deitterick.com SIP/2.0
Via: SIP/2.0/TLS 172.16.8.7:50430
Max-Forwards: 70
From: <sip:lcarter@beta.deitterick.com>;tag=e5fc295f13;epid=159a38c2a2
To: <sip:lcarter@beta.deitterick.com>
Call-ID: 50490a0fd7534119ad400d5ca46e20aa
CSeq: 1 REGISTER
Contact: <sip:172.16.8.7:50430;transport=tls;ms-opaque=d4b2948966>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:C816ACB8-5459-5B19-ADB3-2A9F0A6974A7>"
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Supported: gruu-10, adhoclist, msrtc-event-categories
Supported: ms-forking
Supported: ms-cluster-failover
Supported: ms-userservices-state-notification
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Content-Length: 0

12/31/2010|13:18:17.346 630:358 INFO  :: End of Sending Packet - 172.16.8.10:5061 (From Local Address: 172.16.8.7:50430) 795 bytes

In this trace the user contacts the other server in the pool (172.16.8.9) and a 301 Redirect is returned.  You can see in the response that it also includes the primary and backup registrars:

01/01/2011|13:09:59.182 B34:A44 INFO  :: Sending Packet - 172.16.8.9:5061 (From Local Address: 172.16.8.7:50779) 795 bytes:
01/01/2011|13:09:59.182 B34:A44 INFO  :: REGISTER sip:beta.deitterick.com SIP/2.0
Via: SIP/2.0/TLS 172.16.8.7:50779
Max-Forwards: 70
From: <sip:lcarter@beta.deitterick.com>;tag=e820708c06;epid=159a38c2a2
To: <sip:lcarter@beta.deitterick.com>
Call-ID: 5de48871972847a0b16669398687d8dd
CSeq: 1 REGISTER
Contact: <sip:172.16.8.7:50779;transport=tls;ms-opaque=edd211a910>;methods="INVITE, MESSAGE, INFO, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;+sip.instance="<urn:uuid:C816ACB8-5459-5B19-ADB3-2A9F0A6974A7>"
User-Agent: UCCAPI/4.0.7577.0 OC/4.0.7577.0 (Microsoft Lync 2010)
Supported: gruu-10, adhoclist, msrtc-event-categories
Supported: ms-forking
Supported: ms-cluster-failover
Supported: ms-userservices-state-notification
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Content-Length: 0

01/01/2011|13:09:59.197 B34:A44 INFO  :: End of Sending Packet - 172.16.8.9:5061 (From Local Address: 172.16.8.7:50779) 795 bytes

01/01/2011|13:09:59.260 B34:A44 INFO  :: Data Received - 172.16.8.9:5061 (To Local Address: 172.16.8.7:50779) 758 bytes:
01/01/2011|13:09:59.260 B34:A44 INFO  :: SIP/2.0 301 Redirect request to Home Server
Authentication-Info: TLS-DSK qop="auth", opaque="212BCC58", srand="A46A87C1", snum="1", rspauth="9a517940f6f912c5fd30a4ab48f95c4bb256adf7", targetname="BETA-LS14-EE1.beta.deitterick.com", realm="SIP Communications Service", version=4
From: <sip:lcarter@beta.deitterick.com>;tag=e820708c06;epid=159a38c2a2
To: <sip:lcarter@beta.deitterick.com>;tag=9E9546E818951C08C2E9CA2E852F3D2E
Call-ID: 5de48871972847a0b16669398687d8dd
CSeq: 4 REGISTER
Via: SIP/2.0/TLS 172.16.8.7:50779;ms-received-port=50779;ms-received-cid=9B000
Contact: <sip:beta-ls14-ee2.beta.deitterick.com:5061;transport=TLS>;q=0.7
Contact: <sip:beta-ls14-se2.beta.deitterick.com:5061;transport=TLS>;q=0.3
Expires: 2592000
Content-Length: 0

01/01/2011|13:09:59.260 B34:A44 INFO  :: End of Data Received - 172.16.8.9:5061 (To Local Address: 172.16.8.7:50779) 758 bytes

At this point the client knows about the user's backup registrar.  If the client lost connectivity to the entire pool/data center the client would be able to contact the backup registrar.

So now for the wrinkle...EndpointConfiguration.cache.  Upon the first successful logon, the client writes out the user's primary registrar to the EndpointConfiguration.cache file.  All subsequent logons will use this file to determine which server to send the initial register to.  That means that even if you have a Director configured in the environment, it won't be used after the first logon.  This also means that the client will connect directly to it's primary registrar, so no 301 Redirect will be returned to the client.  Also, the backup registrar is not cached on the client.  It needs to be provided to the client at each logon.

What happens if the user's primary registrar is/goes down?  In this case the client can't use the EndpointConfiguration.cache file, so it will fall back to automatic or manual configuration, depending on which you have configured in your environment.  At that point the client would connect either to a Director and be redirected to the next Front End Server in the user's PrimaryPoolMachinesInPreferredOrder list or to the pool and possibly be redirected to the next Front End Server in the user's PrimaryPoolMachinesInPreferredOrder list.  I say possibly because there's no way of knowing which Front End Server the client will try to connect to.  In my lab environment I'm using DNS load balancing.  The IP addresses for both Front End Servers will be returned to the client and then the client will pick one and attempt to connect.  It's possible that the IP that the client picks is the user's registrar.  Without a Director, there is no way to guarantee that the client will always get the user's backup registrar returned to it.

So...what does this all mean?  When you are planning your Lync Server 2010 deployment, if you are planning on defining a backup registrar for your users, you need to make sure that you understand how the backup registrar will be returned to the clients and make sure that you can guarantee that all clients will be able to connect to their backup registrar, either by using a Director, multiple SRV records, or both.  By doing this you can make sure that in the event of a fail over, you can achieve the resiliency that you are looking for.

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 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:

• The embedded PowerPoint Viewer (which provided a more optimal viewing experience) is available only on the Windows platform.
• Many mobile devices (including some of the more popular mobile telephones) do not support Silverlight.
• Neither the PowerPoint Viewer nor the DHTML/Silverlight approach supports all the features (including slide transitions and embedded video) found in the more recent editions of PowerPoint.

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:

• Higher-resolution displays and better support for PowerPoint capabilities such as animations, slide transitions, and embedded video.
• Additional mobile devices can access these presentations. That's because Lync Server 2013 uses standard DHTML and JavaScript to broadcast PowerPoint presentations instead of customized DHTML and Silverlight.
• Users who have appropriate privileges can scroll through a PowerPoint presentation independent of the presentation itself. For example, while Ken Myer is presenting his slide show, Pilar Ackerman can scroll through and view any slide she wishes, all without affecting Ken's presentation.

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:

1. Windows Server 2008 R2 Service Pack 1
2. .NET Framework 4.5
3. Windows PowerShell 3.0
4. Platform update for Windows 7 SP1 and Windows Server 2008 R2 SP1 (KB2670838)

Next, open the Windows PowerShell prompt as an administrator and run the following sample commands to install the required roles and services:

1. Import-Module ServerManager
2. And then run:

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:

1. Open the Windows PowerShell prompt as an administrator and run the following sample commands to install the required roles and services.

1. Import-Module ServerManager
2. And then run:

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.

With the release of Lync Server 2013, there are two versions of the Lync 2013 client available:

• Lync Basic 2013
• Lync 2013

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:

• Advanced call features (not available with all Office 365 subscriptions); advanced call features include team ring, call forwarding, simultaneous ring, voice mail, call park, call delegation, response groups, and remote call control
• Calendar delegation
• Gallery video view
• OneNote sharing
• Recording
• Skill search (not available with Office 365)
• Virtual Desktop Infrastructure (VDI) (not available with Office 365)

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:

• Microsoft Lync Basic 2013 (64 Bit)
• Microsoft Lync Basic 2013 (32 Bit)

Lync 2013 is available via the Microsoft Volume Licensing Service Center for customers with a Volume Licensing agreement.

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 rtcdyn
SELECT rtc.dbo.Resource.UserAtHost, rtcdyn.dbo.HomedResourceDynamic.LastNewRegisterTime
FROM rtcdyn.dbo.HomedResourceDynamic
INNER JOIN rtc.dbo.Resource on rtc.dbo.Resource.ResourceId = rtcdyn.dbo.HomedResourceDynamic.OwnerId
INNER JOIN rtcdyn.dbo.RegistrarEndpoint ON rtcdyn.dbo.RegistrarEndpoint.OwnerId = rtcdyn.dbo.HomedResourceDynamic.OwnerId
WHERE IsServerSource = 0
ORDER BY UserAtHost

Which produces the following output:

For OCS 2007 R2

USE rtcdyn
SELECT rtc.dbo.Resource.UserAtHost, rtcdyn.dbo.HomedResourceDynamic.LastNewRegisterTime
FROM rtcdyn.dbo.HomedResourceDynamic
INNER JOIN rtc.dbo.Resource ON rtc.dbo.Resource.ResourceId = rtcdyn.dbo.HomedResourceDynamic.OwnerId
ORDER BY UserAtHost

Which produces the following output:

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 LcsCDR
SELECT dbo.Users.UserUri, dbo.UserStatistics.LastLogInTime
FROM dbo.UserStatistics
JOIN dbo.Users ON dbo.Users.UserId = dbo.UserStatistics.UserId
ORDER BY UserUri

Which produces the following output:

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.

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.

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:

For Lync Server 2010/2013

USE rtcdyn
SELECT COUNT(*) as Occurrences,
CAST(rtcdyn.dbo.RegistrarEndpoint.ClientApp as varchar(100)) as 'Client Version'
from rtcdyn.dbo.RegistrarEndpoint
WHERE IsServerSource = 0
group 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.RegistrarEndpoint
INNER JOIN rtc.dbo.Resource
ON rtcdyn.dbo.RegistrarEndpoint.OwnerId = rtc.dbo.Resource.ResourceId
WHERE IsServerSource = 0

For Lync this query needs to be run against each local registrar's SQL instance (RTCLOCAL).

For OCS 2007 R2

USE rtcdyn
SELECT COUNT(*) as Occurrences,
CAST(rtcdyn.dbo.Endpoint.ClientApp as varchar(100)) as 'Client Version'
from rtcdyn.dbo.Endpoint
WHERE IsServerSource = 0
group 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.Endpoint
INNER JOIN rtc.dbo.Resource
ON rtcdyn.dbo.Endpoint.OwnerId = rtc.dbo.Resource.ResourceId
WHERE 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.

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

An issue I ran into when trying to publish my topology is that it would complete with errors when trying to do the enabling topology step:

Looking at the log, I can see that I'm getting the following errors when it trys to connect to the share:

Error: Error accessing share \\BETA-LS14-SE1.beta.deitterick.com\share - Method failed with unexpected error code 2310..  

Error: Cannot create directory. The path is read only: \\BETA-LS14-SE1.beta.deitterick.com\share\2-ApplicationServer-1\AppServerFiles

In this instance this server was a Standard Edition server and the issue was that I never created the share manually.  Unlike in OCS 2007 R1/R2, for a Standard Edition install, you need to manually create the share before publishing your topology.  This same error will happen for an Enterprise Edition pool if you haven't created the share, but for an Enterprise Edition install, you always had to manuall create the shares ahead of time.

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:

• NoAudioVideo = Audio/Video Disabled
• None = PC-to-PC only
• Rcc = Remote Call Control
• Rcc Only = Remote Call Control only
• UC = Enterprise Voice

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.

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.

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:

• Configure server-to-server authentication between an on-premise installation of Lync Server 2013 and an on-premises installation of Exchange 2013 and/or Microsoft SharePoint Server.
• Configure server-to-server authentication between a pair of Office 365 components (for example, between Microsoft Exchange 365 and Microsoft Lync Server 365, or between Microsoft Lync Server 365 and Microsoft SharePoint 365.
• Configure server-to-server authentication in a cross-premises environment (that is, server-to-server authentication between an on-premises server and an Office 365 component).

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 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:

• Web Server
  • Common HTTP Features
    • Static Content
    • Default Document
    • HTTP Errors
  • Application Development
    • ASP.NET - (Note: For Windows Server 2012, ASP.NET 3.5 & ASP.NET 4.5 are required.)
    • .NET Extensibility
    • Internet Server API (ISAPI) Extensions
    • ISAPI Filters
  • Health and Diagnostics
    • HTTP Logging
    • Logging Tools
    • Tracing
  • Security
    • Windows Authentication
    • Client Certificate Mapping Authentication
    • Request Filtering
  • Performance
    • Static Content Compression
    • Dynamic Content Compression
  • Management Tools
    • IIS Management Console
    • IIS Management Scripts and Tools

• .NET Framework 4.5
  • WCF Services
    • HTTP Activation - (Note: Required for Windows Server 2012/2012 R2.)

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 ServerManager
Add-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 ServerManager
Add-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.

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.

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 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: 

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:

I was troubleshooting PIC connectivity with a customer recently and we ran into an issue when following the steps in Scott Oseychik's blog post on changing the cipher suite order (http://blogs.msdn.com/b/scottos/archive/2009/04/03/resolved-ocs-2007-r2-pic-fails-against-aol.aspx).  I've used the steps outlined in the blog post on Windows 2008 before, but never on Windows 2008 R2.  It just so happened that this customer had a Windows 2008 R2 Edge server.  When we went to paste the newly ordered cipher suite back into the Group Policy Editor, we noticed that the whole string didn't paste back in:

The string got cut off close to the end, but it was missing the last few ciphers.  It appeared that the text box could only accept so many characters and in doing a little research, that's exactly the case.  Scrolling down in the help section on the right, you will find the instructions for editing the cipher suite order:

Step 6 is the key.  The maximum length is 1023 characters.  So the text box will only accept 1023 characters, but I never ran into this issue on Windows 2008?  Digging a little deeper it appears that there were some additional ciphers added between Windows 2008 and 2008 R2.  In Windows 2008 the list of ciphers is 831 characters.  In Windows 2008 R2 the list of ciphers is 1071 characters.  So we can't use the Group Policy Editor to reorder the list of cipher suites.

The workaround that I came up with is to modify the registry key that this group policy object updates.  The standard warnings about modifying the registry apply...be careful when editing the registry!  The key that the group policy object updates is: 

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
Type = REG_SZ
Name = Functions
Data = TLS_RSA_WITH_RC4_128_MD5,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,...

The "Functions" value shouldn't already exist, so you will probably need to create a new "String Value".  Take your newly ordered list of ciphers and paste them into the value data field.  This time the whole list will paste in correctly.  Reboot your server and the new cipher suite order should be in effect.

I was helping to troubleshoot an issue where users were unable to login via Remote User Access using the Edge server.  They were able to successfully login from inside the network, but externally, the client would come back with an error.  We made sure that the user account was enabled for Remote User Access and that they were able to successfully telnet to the Access Edge server.  We took SIPStack logging on the front-end and found a couple interesting error messages when the client tried to login.

The first error listed below is complaining about failing to be able to validate the user's credentials against Active Directory and the second is the SIP error message that is returned to the client.  It's a 401 Unauthorized with an error code 0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED).

TL_ERROR(TF_SECURITY) [8]0D04.12B4::09/28/2010-22:33:22.019.0006247e (SIPStack,SIPAdminLog::WriteSecurityEvent:SIPAdminLog.cpp(413))$$begin_record
LogType: security
Text: Failed to validate user credentials
Result-Code: 0x80090302
SIP-Start-Line: REGISTER sip:domain.com SIP/2.0
SIP-Call-ID: c8f814156fe8424b91f58a7593130b7a
SIP-CSeq: 3 REGISTER
Data: gssapi-data="NTLMSSP.........x...............H.......R.......b...........U..B..(.....d.o.m.a.i.n.b.a.r.k.s.d.a.D.6.2.0.-.S.P.A.R.E.1........(+H~B.\Q.d.^.7......0Nf........&U.*...F.i8...I".....E{..a"
$$end_record

TL_INFO(TF_PROTOCOL) [8]0D04.12B4::09/28/2010-22:33:22.019.0006269e (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 00008E99
Direction: outgoing;source="local"
Peer: ocsedgeint.domain.com:51824
Message-Type: response
Start-Line: SIP/2.0 401 Unauthorized
From: <sip:username@domain.com>;tag=ef63196ac5;epid=66ae95f7d4
To: <sip:username@domain.com>;tag=9E59F3FCA63C8513AB67D79A59A71738
CSeq: 3 REGISTER
Call-ID: c8f814156fe8424b91f58a7593130b7a
Date: Tue, 28 Sep 2010 22:33:22 GMT
WWW-Authenticate: NTLM realm="SIP Communications Service", targetname="ocspool.domain.com", version=4
Via: SIP/2.0/TLS 10.1.1.143:51824;branch=z9hG4bK9CEF35AB.842743D325E6B7D1;branched=FALSE;ms-received-port=51824;ms-received-cid=13300
Via: SIP/2.0/TLS 192.168.2.104:1161;received=111.111.111.111;ms-received-port=54335;ms-received-cid=1F00
ms-diagnostics: 1000;reason="Final handshake failed";source="ocspool.domain.com";HRESULT="0xC3E93EC3(SIP_E_AUTH_UNAUTHORIZED)"
Content-Length: 0
Message-Body: –
$$end_record

Their OCS environment is running on Windows 2008 R2 and as we continued to troubleshoot this we discovered that they didn't complete all the steps listed in KB982021 (http://support.microsoft.com/kb/982021/).  Specifically, they didn't complete Step 8. 

8. The default security setting on Windows Server 2008 R2 operating system for NTLM SSP requires 128-bit encryption. Depending on the client operating system mix in the enterprise, you may have to reduce this setting on a Windows Server 2008 R2 operating system that is running Office Communications Server 2007 R2 as a down level operating system. The key is set to "No requirement."
   1. For any down level operating system, such as Windows XP or for Windows Vista, the default value is set to "No Minimum."
   2. For a Windows 7 operating system, the default value is set to "Requires 128-bit encryption."

For more information about the “Changes in NTLM Authentication” as it applies to Windows 2008 R2 and Windows 7 operating systems, please visit the following Microsoft Web site:

Learn more about the changes in NTLM Authentication

If you want to change the NTLM setting, follow these steps:

1. Start secpol.msc on a Windows Server 2008 R2 operating system server.
2. Click to select Local Policies and then click Security Options node.
3. Make sure that the following values of the policies are set to "No Minimum."
   • Network Security: Minimum session security for NTLM SSP based (including secure RPC)
   • Network Security: Minimum session security for NTLM SSP based (including secure RPC) servers

Once we changed the security policy the user could successfully login.  It just so happened that the users that couldn't login were running Windows XP.  Testing from a Windows 7 workstation before making the change resulted in the user being able to login.  Also, none of their internal Windows XP users had any problems logging in.  This makes sense, since internally the Communicator client is using Kerberos to authenticate and only when the user is external and coming in through the Edge server, is NTLM used.

So remember to follow all of the steps in KB982021 (http://support.microsoft.com/kb/982021/), especially if you have Windows XP users enabled for Remote User Access. 

I was setting up a Lync Server 2010 Edge Server in my lab and I wondered what would happen if I didn't configure the full computer name on the Edge Server.  In previous OCS 2007 environments, I've seen this happen where the domain name is not configured and the full computer name is left as just the computer name:

Since Lync Server 2010 uses a local copy of the Central Management Store to determine which roles to install on the server, and Topology Builder is expecting you to enter the FQDN of the Edge Server, I was curious to see what happens.  I left the full computer name as above and proceeded to install the Edge Server.  Step 1: Install Local Configuration Store completed successfully, which I expected, since all this is doing is installing SQL Express for the local copy of the CMS database.  It was Step 2: Setup or Remove Lync Server Components that I expected something to happen.  Running step 2 resulted in the following in the log:

As you can see, the host name found was the computer name, not the full computer name.  Since this short name didn't match the FQDN entered in Topology Builder, the installer didn't find any roles to install.

The other interesting part is that since no roles were found, the installer skipped running Enable-CsComputer.  This is important because in the beginning of this step the installer ran Disable-CsComputer.  So what does the Disable-CsComputer cmdlet do?  Here's an excerpt from the RTCCmdlets document:

Removing a service or server role from a computer does not automatically update the Lync Server 2010 topology. Instead, that service or role must be disabled before the changes are fully updated in the topology. The Disable-CsComputer cmdlet provides a way for administrators to disable any services or server roles that have been removed from the local computer.

So the Disable-CsComputer cmdlet disables services, but what services do we have installed for Lync Server 2010 at this point?  Looking in the Services MMC shows that there is only one, the Lync Server Replica Replicator Agent service.  It gets installed as part of Step 1: Install Local Configuration Store.  After that step completes, the service looks like this:

But after running Step 2: Setup or Remove Lync Server Components, the service looks like this:

As you can see, Disable-CsComputer disabled the service from starting.  This is interesting, but does it have any impact on the Edge Server?  In order to find out I fixed the computer full name and continues on with the install.

After restarting the server, I ran Step 2: Setup or Remove Lync Server Components again. 

This time the full computer name was found by the installer. 

Since there was a matching entry in the local CMS database, the installer determined that this server is supposed to be configured as an Edge Server and the Edge Server role was installed.  I was then able to complete the rest of the installation and start the services, but what about the Lync Server Replica Replicator Agent service that was disabled before?  Looking in the Services MMC you can see that it's still disabled.

With this service disabled, no replication of any configuration changes will be sent to the Edge Server.  This is especially important if you make any changes to the Edge Server configuration using the Lync Server 2010 Control Panel, like adding/removing a federation partner, PIC, or any Edge Server changes in Topology Builder.  If you look at the Topology section in the Lync Server 2010 Control Panel, you will see that replication for the Edge Server will have a red 'X'.

To fix this issue all you need to to is set the Lync Server Replica Replicator Agent to Automatic and start the service.  After a couple of minutes, replication should start and the Lync Server 2010 Control Panel should show the following:

Also on the Edge Server you should see the following events in the Lync Server Event Log:

Log Name:      Lync Server
Source:        LS Replica Replicator Agent Service
Date:          10/16/2010 3:56:04 PM
Event ID:      3017
Task Category: (3003)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      TEST-LS14-EDGE.test.deitterick.com
Description:
Successfully started replication service using current configuration.

Service Uri: https://TEST-LS14-EDGE.test.deitterick.com:4443/ReplicationWebService

Log Name:      Lync Server
Source:        LS Replica Replicator Agent Service
Date:          10/16/2010 4:00:19 PM
Event ID:      3013
Task Category: (3003)
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      TEST-LS14-EDGE.test.deitterick.com
Description:
Microsoft Lync Server 2010 (RC), Replica Replicator Agent reported the latest replica status.

Status report reason: DataReceived

If you need to change the location where you originally configured the OCS shares, there are a couple of steps that you need to follow.  One reason to change the location is if you originally configured the shares to be on your Front-End server in an Enterprise Pool.  Although this technically will work, it is not recommended, especially if you have more than one Front-End server in the pool.  As you can see in the 2 images below, the shares for LiveMeeting and the Address Book are configured on the Front-End server.  If another server was added to the pool and the server hosting the shares was offline, client wouldn't be able to download the address book or upload/download content from a LiveMeeting.

To change the location of the shares, you will need to make the change in WMI.

First you need to go to Start > Run > wbemtest

Click Connect
For the namespace, enter: root\cimv2
Click Connect

Next, click on Query.

Enter one of the following queries:

Select * from MSFT_SIPAddressBookSetting
Select * from MSFT_SIPDataMCUCapabilitySetting
Select * from MSFT_SIPDataComplianceSetting

Double-click on the returned value.

Scroll down until you find the following values:

For MSFT_SIPAddressBookSetting, the property you are looking for is:
OutputLocation = "\\server\AddressBook"

For MSFT_SIPDataMCUCapabilitySetting, the properties you are looking for are:
MeetingMetadataLocation = "\\server\MeetingMetadata"
MeetingPresentationContentLocation = "\\server\MeetingContent"

For MSFT_SIPDataComplianceSetting, the property you are looking for are:
MeetingContentComplianceLocation = "\\server\MeetingArchiving"

To edit the properties, click on Edit Property.  Enter the new location for the share.  When you are done, make sure to click on Save Property and Save Object.

If you are trying to change the location on OCS 2007 R2, you will need to change the WMI query a little.

Select * from MSFT_SIPAddressBookSetting where Backend="<SQL Instance>"
Select * from MSFT_SIPDataMCUCapabilitySetting where Backend="<SQL Instance>"
Select * from MSFT_SIPClientUpdaterSetting where Backend="<SQL Instance>"
Select * from MSFT_SIPDataComplianceSetting where Backend="<SQL Instance>"
Select * from MSFT_SIPPoolConfigSetting where Backend="<SQL Instance>"
Select * from MSFT_SIPApplicationConfigSetting where Backend="<SQL Instance>"

*Note: for MSFT_SIPApplicationConfigSetting, there are a couple Instance Ids returned.  You want the Instance Id that corresponds to the Response Group service.  The easiest way to figure out which Instance Id this is, is to look at the DisplayName property of each Instance Id for the value "Office Communications Server Response Group".

For MSFT_SIPAddressBookSetting, the property you are looking for is:
OutputLocation = "\\server\AddressBook"

For MSFT_SIPDataMCUCapabilitySetting, the properties you are looking for are:
MeetingMetadataLocation = "\\server\MeetingMetadata"
MeetingPresentationContentLocation = "\\server\MeetingContent"

For MSFT_SIPClientUpdaterSetting, the property you are looking for is:
FileLocation = "\\server\ClientUpdate"

For MSFT_SIPDataComplianceSetting, the property you are looking for are:
MeetingContentComplianceLocation = "\\server\MeetingArchiving"

For MSFT_SIPPoolConfigSetting, the property you are looking for is:
ApplicationDataLocation = "\\server\ApplicationData"

For MSFT_SIPApplicationConfigSetting, the property you are looking for is:
DataLocation = "\\server\ApplicationData"

You will need manually create the shares as well as assign share and NTFS permissions.

Share Permissions for the Address Book Share
Authenticated Users - Read
RTCHSUniversalServices - Read, Change
RTCUniversalServerAdmins - Read, Change
RTCUniversalGuestAccessGroup - Read

NTFS Permissions for the Address Book Share
Authenticated Users - Read, List Folder Contents
RTCHSUniversalServices - Modify
RTCUniversalServerAdmins - Modify
RTCUniversalGuestAccessGroup - Read, List Folder Contents

Share Permissions for the Meeting Content Share
RTCComponentUniversalServices - Read, Change
RTCUniversalGuestAccessGroup - Read

NTFS Permissions for the Meeting Content Share
RTCComponentUniversalServices - Modify
RTCUniversalGuestAccessGroup - Read, List Folder Contents

Share Permissions for the Meeting Metadata Share
RTCComponentUniversalServices - Read, Change

NTFS Permissions for the Meeting Metadata Share
RTCComponentUniversalServices - Modify

Share Permissions for the Meeting Compliance Share
RTCComponentUniversalServices - Read, Change

NTFS Permissions for the Meeting Compliance Share
RTCComponentUniversalServices - Modify

Share Permissions for the Application Data Share
RTCComponentUniversalServices - Read, Change
RTCUniversalServerAdmins - Read, Change

NTFS Permissions for the Application Data Share
RTCComponentUniversalServices - Modify
RTCUniversalServerAdmins - Modify

Share Permissions for the Client Update Share
RTCHSUniversalServices - Read
RTCComponentUniversalServices - Read, Change
RTCUniversalServerAdmins - Read, Change
RTCUniversalGuestAccessGroup - Read

NTFS Permissions for the Client Update Share
RTCHSUniversalServices - Read, List Folder Contents
RTCUniversalServerAdmins - Modify
RTCUniversalGuestAccessGroup - Read, List Folder Contents

Once you are done creating the share and assigning permissions you can copy over the data from the old share.  You will also need to update the path in IIS for the Abs>Ext>Files and Abs>Int>Files and Etc>Place>Null>FileTree folders to point to the new location.  When that is finished, restart the OCS Services on the Front-End server and you're all set.

I ran into a couple of issues getting the file upload feature to work in Group Chat.  I followed all of the documentation found on TechNet (http://technet.microsoft.com/en-us/library/dd441213(office.13).aspx), which unfortunately leaves out some important steps.  Below is a list of the issues that I ran into and the resolutions:

Issue #1

When trying to upload a file in Group Chat, I got the following error:

A file transfer error occurred. Unable to connect to the remote server

I checked to make sure that all of the Group Chat services were running, and I noticed that the Web Service was stopped.

Continuing to look through the configuration options, I saw that the URL for the Web Services started with https, but I didn't remember adding the certificate to IIS, so I checked and sure enough, the only binding was for http.  I added another binding for https.

Once I did that, refreshing the Group Chat Server Configuration application, the Web Service was running.  Issue #1 resolved!

Issue #2

I tried uploading another file and got the following error message:

A file transfer error occurred. Server was unable to process request. ---> [121] Sql error: opening a connection

---> Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

This was interesting because I was sure that I changed IIS to use the channel service account for anonymous access.  I checked and it wasn't set to the channel service account, so I changed it and restarted IIS.  This step is documented here: http://technet.microsoft.com/en-us/library/dd441213(office.13).aspx.  Issue #2 resolved!

Issue #3

I again tried uploading another file and got the following error:

A file transfer error occurred. Server error.

This one was difficult to track down.  The file would start to upload, but then error out.  The error message doesn't give you much to go on.  I had a feeling that file permission were going to be an issue, so I started looking at the shares that I created.  I noticed that in the share for the Web Service,  the file was sucessfully uploaded to the UploadTemp directory, but it wasn't being moved to the directory for the chat room.  My issue ended up being caused by the fact that I had the Compliance Server role setup and I didn't have the proper permission on the compliance share.  This was causing the upload to fail because the channel service account didn't have rights to copy the file to the compliance share.  Below is a list of the permissions needed for both shares:

Share Permissions for the Compliance Share
Channel Service Account - Read, Change
Compliance Service Account - Read

NTFS Permissions for the Compliance Share
Channel Service Account - Modify
Compliance Service Account - Read, List Folder Contents

Share Permissions for the Web Service Share
Channel Service Account - Read, Change

NTFS Permissions for the Web Service Share
Channel Service Account - Modify

After making sure that the shares had the correct permission, I was finally able to successfully upload a file.  Issue #3 resolved!

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.