1. SFB Client or Computer issues
2. Authentication or provisioning issues
3. Network/Connectivity related issues
4. Server related issues

Manual vs Automatic Sign in

Simpler way to identify if DNS Records are the problem is by testing Manual Sign in vs Automatic Sign in method. To do that, we can edit the Advanced settings and manually provide Skype for Business Server/Pool name like below:

Skype for Business Client Settings -> Tools -> Personal -> Advanced

For Manual Sign in, provide the Skype for Business Pool name or Server name and the Port number manually in Internal or External Server name Box (depending on whether we are testing internal Sign in or External Remote Connectivity)

Internal Server Name  : Front End Pool name & Port

External Server Name : External Access Edge FQDN & Port

If manual sign in worked, we know that Client is able to sign in when its connecting directly to Server/Pool using Manual settings, it’s just the Automatic sign in that is not functional, basically client is not able to determine where to connect to sign in.

For Automatic sign in to work, there are certain DNS Records (refer to Server Discovery step in previous article) that needs to be configured so that client can make DNS Query and get the Pool Info.

Skype for Business Client Log

Since we know from above step that automatic sign in is failing, we can look at client logs to see what all DNS Queries it made and whether it’s able to resolve DNS records or not.

If we have Logging Enabled on the client, we can open client Side Log ‘Lync-UccApi.Uccapilog’ present in Location “C:\Users\Mouli\AppData\Local\Microsoft\Office\1X.0\Lync\Tracing” using a notepad or any editor, below are sample log where client queries DNS for

Lyncdiscover Records:

<Info><![CDATA[Discovery request sent to URL https://lyncdiscoverinternal.contoso.com?sipuri=mouli@contoso.com, txn (10A4EBE8), action id(1), type(InternalUrl)]]></Info>

<Info><![CDATA[Discovery request sent to URL https://lyncdiscover.contoso.com?sipuri=mouli@contoso.com, txn (10A4EB68), action id(2), type(ExternalUrl)]]></Info>

SRV Records:

09/12/2016|19:30:07.502 1098:E10 INFO :: QueryDNSSrv - DNS Name[_sipinternaltls._tcp.contoso.com]

09/12/2016|19:30:07.502 1098:E10 INFO :: QueryDNSSrv - DNS Name[_sip._tls.contoso.com]

09/12/2016|19:30:07.502 1098:112C TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete[0D2F4C30] Entered host lync2010-se.contoso.com

09/12/2016|19:30:07.502 1098:112C TRACE :: SIP_MSG_PROCESSOR::OnDnsResolutionComplete get DNS result server: lync2010-se.contoso.com IP: 192.168.2.50:5061

Host A Records:

09/12/2016|19:34:00.56 1064 ERROR ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipinternal.contoso.com)

09/12/2016|19:34:00.567 1064 ERROR :: ResolveHostNameUsingGetAddrInfo - getaddrinfo(sip.contoso.com)

09/12/2016|19:34:00.567 1064 ERROR :: ResolveHostNameUsingGetAddrInfo - getaddrinfo(sipexternal.contoso.com)

Nslookup Tool:

We could also make use of windows Builtin tool Nslookup to check the DNS Resolution.

Nslookup Lyncdiscover.contoso.com [For SRV Record we need to run ‘Set type=SRV’ ]

From above check we will know if DNS Records exists or not, based on that we could configure DNS Records to fix the issue.

Host File Entries:

Sometimes even if DNS Record is resolvable, automatic sign in might still be failing, as DNS Records might be pointing to a Load Balancer or Reverse Proxy or Firewall or different Skype for Business Pool which is having issues.

In such situation, we could use host file entries (admin rights is needed) to override DNS and point user to hit the Front end or Edge Server IP Address directly and test it out. Host file entries overrides DNS Queries, I, e, Client prefers host file entries over DNS query response.

By default, host file is located in “C:\Windows\System32\drivers\etc”

At the End of this stage, we will be in a state where we will know if the issue is specific to user's home server/Pool or whether its with different pool and due to the Redirection failure, based on the outcome we should take necessary actions to fix the issue.

Now that we confirmed that DNS isn’t the problem, or takes steps to fix the DNS Issue, if sign in is still failing, next thing to check if whether client is able to make network connection to the Skype for business server and whether it was able to establish a TLS Session successfully or not.

We could make use of Telnet or Port Query tool (needs to be installed) to check if required ports are open and whether client is able to make successful connection. (if telnet is successful, you will see a Blank window in cmd prompt)

Telnet Sip.contoso.com 443

If telnet or Port Query is blocked on firewall (due to security restrictions), we can collect a Network trace from client to see whether connectivity check is succeeding or not.

If it’s able to connect, then we should see TCP 3 Way Handshake (A -> A,S -> A), if not we would see Retransmits, where client to trying to connect over the required port & its failing.

Based on the outcome, we could proceed further or we could work with Security team to get the required ports accessible for Client to be able to make connection to Server.

Other than above basic connectivity check, for client to be able to connect to Skype for Business Server, TLS Check is necessary. After successful Port connectivity check, client will try and establish a secure TLS connection, for this to work, below are some of things to consider:

Client should trust the Certificate issued on the Server (Client should contain the Root/Intermediate Certs)

FQDN/ URL that we are trying to access should be part of Certificate SAN entry on the Server where we are connecting to.

Required TLS Protocol & TLS cipher suites should be allowed in Firewall (If any)

If we have surpassed above steps, then we should see SIP REGISTER Request being sent by client to initiate sign in process. This is another trick to identify, if all the above checks are successful is by opening UCCAPI Logs using Snooper Tool, if we see any REGISTER Messages being sent, which means client has performed all previous steps and then only sending SIP Requests.

Using Snooper Tool (Needs to be installed) we can open the Skype for Business Client side logs located in “C:\Users\Mouli\AppData\Local\Microsoft\Office\1X.0\Lync\Tracing” to see what's happening at the application level.

Depending the issue cause, sometimes Client logs might reveal the exact cause of the issue (for Ex : "Destination URI either not enabled for SIP or does not exist") and sometimes it would just give a generic Error (For Ex : 500 Internal Server Error )

Once we see which server is the source for generating this Error, we could take a look at server side Logs to see what's going on. Some of the Logs that we can look on the Server side are below:

Lync Server Event Logs (for any Server side or user specific Error, if logged)

Security Event Logs (for any Authentication failures, failure security audit)

Skype for Business CLS Logs (for detailed information on what's happening at SIP level)

Centralized Logging Service Logging is something that we can use to collect Server side logs while reproducing the issue. we could use the CLSLogger or the CLS Logging commands and collect the logs for IMAndPresence scenario (SIPStack & User Services) to get detailed information on what's going on when server gets the REGISTER request from the Skype for Business Client.

CLS Logging commands:

Start-CsClsLogging -Scenario "IMAndPresence" -Pools "SFB-SE.Contoso.com"

Stop-CsClsLogging -Scenario "IMAndPresence" -Pools "SFB-SE.Contoso.com"

Search-CsClsLogging -Pools "SFB-SE.Contoso.com" -Computers "SFB-SE.Contoso.com" -Components "SIPStack,UserServices" -StartTime "10/14/2016 6:09:51 PM" -EndTime "10/14/2016 6:14:51 PM" -LogLevel "All" -MatchAll -OutputFilePath "C:\Logs\SFBLog.txt"

Fiddler Tool

If we are suspecting issues where users is not able to connect to HTTPS services like Lyncdiscover or Certificate Provisioning web services, to see client side request and response, we can collect Fiddler trace from client machine when we try to sign in.

Network Monitor

If we are suspecting Network connectivity or TLS Session establishment issue, we can use Network monitor Tool to collect network capture. Sometimes simultaneous capture from client and server would help identify if there are any firewall between blocking the packets

Snooper Tool

To view Client side UCCAPI logs or Server side CLS logs, we could make use of Snooper Tool to see SIP requests and responses.

Lyncdiscover Records

Lyncdiscoverinternal.contoso.com

Lyncdiscover.contoso.com

SRV Records

_sipinternaltls._tcp.contoso.com

_sip._tls.contoso.com

DNS A Records

Sip.domain.com

Sipinternal.domain.com

Sipexternal.domain.com

At the End of this step, if we have DNS Records configured, skype for business client will get the FQDN/IP Address & Port combination of Skype for business server where it can reach to login.

Port Connectivity Checks

Client attempts Network connectivity check to see if it can reach server on required port

In Networking terms this is termed as TCP 3 Way Handshake [ACK–SYNC–ACK]

TLS connectivity Checks

Client attempts to check if it can establish a secure connection with the server

In this, basically client will check if the certificate presented by server is being trusted on client or not; and it also includes Cipher Selection.

In order for Client to be able to trust the presented certificate, client should have the Root CA Cert of the Certification authority that has issued the certificate to the server in its Certificate Trusted Root Store.

Firstly, Client sends an Unauthenticated REGISTER Request to the Skype for Business Server:

In response to this REGISTER request, Skype for Business Server would send the list of Authentication mechanisms available for Authentication in 401 Unauthorized:

Client would then select one of the authentication methods and gets authenticated (depending on whether signing in internally or externally, first time sign in or subsequent sign in). By default, Skype for Business Registrar Configurations has below 3 Authentications enabled:

If Client is signing in Internally, then all 3 above listed Authentication methods [Kerberos/NTLM/TLS-DSK] will be available.

If Client is signing in Externally, then only 2 authentication methods will be available [NTLM/TLS-DSK] will be available.

If client uses Kerberos authentication

This is the default one that client uses internally during first time sign in I.e. when they don’t have user certificate to sign in using TLS DSK.

Client would reach out to AD Server and gets authentication ticket (Kerberos ticket) for accessing service on Skype for Business Server. Once it gets the Kerberos ticket, it submits that to Server in next REGISTER request, and server would authenticate the user and signs the user.(In Kerberos method, there is an interaction between clients and AD Servers, this is the primary reason why Kerberos Authentication isn't available for Remote Sign in)

When using Kerberos, in client side logs we will see 2 REGISTER Request/Responses between client and the skype server.

If client uses NTLM Authentication

This is the default one that client uses externally during first time sign in I.e. when they don’t have user certificate to sign in using TLS DSK

Client would send information/details required for authentication in the next REGISTER Requests to the skype for business server, skype for business server in turn talks to AD Server and validates the submitted information/details.

If the Validation succeeds then, skype for business server would consider user authentication as valid/genuine and signs the user. (In NTLM method, All the interaction is between client and the Skype for business server and Skype for business Server to Active directory, but no interaction from client directly with Active Directory)

When using NTLM, In Client side logs we will see 3 REGISTER Request/Responses between client and the skype server.

If Client uses TLS-DSK Authentication

In order for client to use this authentication, client should have user certificate issued by the Skype for business server.

Below is how client connects to the Skype for Business Web Services and gets the user certificate issued.

Client would get the location/URL of web services to get the user certificate from, this would be sent by server in first response for anonymous REGISTER sent. (Ex for URL : https://SFB-SEWeb.Contoso.com:443/CertProv/CertProvisioningService.svc)

Client would connect to skype for business Web Services and authenticates itself using Kerberos/NTLM depending on whether its connecting internally or externally and gets the user certificate issued.

Once user certificate is issued, Client would submit the user certificate details to the skype for business server in the next REGISTER and authenticates itself.

When using TLS-DSK, In Client side logs we will see 4 REGISTER Request/Responses between client and the skype server.

If client reached out to Front End Server, where he is homed, then we wouldn’t see this step at all, however, if client reaches out and authenticates against any other front end server (within same pool or different pool) we will see this step, where server would identify where user is homed and redirects to the home Pool Accordingly.

In the above Example, Client reached SFB-FE1.contoso.com (since DNS was pointing here), which inturn redirected to User's home server "SFB-SE.Contoso.com"

In this step we would see client sending SERVICE/SUBSCRIBE SIP requests and getting required responses.

SERVICE           Requesting for Normalization rules (Location Profile).

SUBSCRIBE      Requesting for contact lists

SUBSCRIBE      Requesting for Server side configurations/policies (Inband)

SUBSCRIBE      Requesting for Presence info of users in the contact list

1. User provides the sip uri Mouli@contoso.com on the skype for business desktop client and clicks on sign in.
2. Client first performs “Server Discovery step” and tries Lyncdiscover Records, if it’s not available, then it will failback to SRV Records and then host A Records.
3.  At the end of Server discovery stage, client would get “Server FQDN/IP and the Port to be connecting to”.
4.  Client would now attempt and check if it can establish Network connectivity and TLS Connectivity.
5.  Post successful connectivity checks, client would now send the first anonymous sign in Request “REGISTER” to the server, to learn what all authentication methods are available.
6.  Server would present the available Authentication methods and respective target/service name and other info.
7. Client now selects one of the Authentication methods depending on whether signing in internally or externally, first time sign in or subsequent sign in.
8. Upon successful authentication, if it’s not a home server, then Authenticated server will determine the user’s home server and redirect the user to go user’s home pool/Server.
9. Post successful sign in, client would send subsequent SERVICE/SUBSCRIBE requesting for inband configuration, policies & etc.

Lync Server 2013                : C:\Program Files\Microsoft Lync Server 2013\Web Components\LWA\Int\Plugins

Skype for Business 2013      : C:\Program Files\Skype for Business Server 2015\Web Components\LWA\Int\Plugins

HKCU\Software\Microsoft\SkypeForBusinessPlugin\15.8\AllowedDomains

Create a New String with value “skype.contoso.com”

skype.contoso.com is the Web services FQDN of the Skype for Business 2015 Front End Pool

HKCU\Software\Microsoft\LWA\x86\15.8\AllowedDomains

Create a New String with value https://Lyncweb.domain.com/lwa/WebPages/LwaClient.aspx

Lyncweb.contoso.com is the Web services FQDN of the Lync 2013 Front End Pool

Skype for Business User Mouli@Contoso.com creates a Skype Meeting and shares the Meeting URL "Https://meet.contoso.com/mouli/1LW55RJRC"

User Pranam@contoso.com or Anonymous Users clicks on the URL and tries to join either as Authenticated user or Anonymous users.

Skype Web App pop’s up the SkypeforBusinessPlugin to be installed on the client to support Media (Application sharing or Audio/Video Call)

User Installs Skype for Business Web App Plugin and allows client machine to load the plugin and joins the Meeting.

Skype for Business User Mouli@Contoso.com creates a Skype Meeting and shares the Meeting URL "Https://meet.contoso.com/mouli/1LW55RJRC"

Skype for business user Pranam@contoso.com or Anonymous Users clicks on the URL and tries to join either as Authenticated user or Anonymous users.

Immediately after clicking on Join the Meeting, since Plugin is already installed and allowed to Load user joins the Meeting capability right away without any prompts to install/load Plugin.

1. Skype for Business Client.

2. Outlook Client.

• Before configuring Web scheduler, we see below Simple URL configurations in Skype for business Infrastructure:

Get-CsSimpleUrlConfiguration | Select-Object -ExpandProperty SimpleUrl

• Run below commands from Skype for business Management shell to create a new simple URL Entry for web scheduler:

$SimpleUrlEntry = New-CsSimpleUrlEntry -Url “https://Skypeweb.contoso.com”

$SimpleUrl = New-CsSimpleUrl -Component “WebScheduler” -Domain “*” -SimpleUrlEntry $SimpleUrlEntry -ActiveUrl “https://Skypeweb.contoso.com”

Set-CsSimpleUrlConfiguration -Identity Global -SimpleUrl @{Add=$SimpleUrl} –Verbose

• Now we would see another simpleurl configured below:

Get-CsSimpleUrlConfiguration | Select-Object -ExpandProperty SimpleUrl

• Run Step 2 from Deployment Wizard on all the Front End Servers in the Skype for business Pool, which adds the components for Web Scheduler Feature.       

• After performing above actions, under the Scheduler Virtual Directory (both Internal & External Website) on Skype for business Front End Servers we would see Additional URL Rewrite rules added for Web Scheduler.

• Skype users can use the Scheduler URL “Https://Skypeweb.contoso.com” from the Web browser to schedule the Skype meetings.

• As per the URL Rewrite module settings, Front end Server will redirect user to Internal/External Web services along with Scheduler Virtual Directory (Https://Skype.contoso.com/Scheduler) which provides the sign in page.

1. User provides the sip address Onprem@domain.com and clicks sign in on Skype for Business Client.
2. Skype for Business Client makes Lync Autodiscover Query “Lyncdiscover.domain.com” which will be pointing to Onpremise Servers (as it’s a hybrid setup) and reaches the Front end server (Hybrid Server).
3. Once Request Reaches the Front End server, Server first authenticates the user and checks if user is homed onpremise or online, since user is homed onpremise, User signs in to the onpremise Front end server and server will provide required services.

1. User provides the sip address Online@domain.com and clicks sign in on Skype for Business Client.
2. SFB Client makes Lync Autodiscover Query “Lyncdiscover.domain.com” which will be pointing to On premise Servers (as it’s a hybrid setup) and hits the Front End Server
3. Once Request Reaches the Front End server first authenticates the user and checks if user is homed onpremise or online, since user is not homed onpremise, it will check Hosted SRV parameter and identifies that user is homed online.
4. Onpremise server will redirect the user to connect to online Servers by providing the Hosting Provider FQDN “Sipfed.online.lync.com”.
5. User will then connect to online servers (after multiple redirects to user’s home server), which will re-authenticate the user and provide required services.

ExternalDNS:

InternalDNS:

1. Collect the KHI performance counters.
2. Populate the Average and Maximum values in KHI spreadsheet.
3. Analyze the same and compare with thresholds to identify what’s causing performance bottleneck.

1. Download KHI Collection Script “Create_KHI_Collection” from Lync2010 Networking Guide  or Lync2013/SFB KHI : (downloaded files might be blocked, need to unblock them before using).
2. We have different KHI Collection Script for different version of Lync Server (2010/2013).

3. Copy the “Create_KHI_Collection” file to each front end server where we want to collect the performance data and run this script using windows PowerShell (launched with administrator rights); Depending on the Server version, we need to provide '-Version LyncServer2010 / LyncServer2013 / Skype4B' switch

4. This will create a user defined data collector set named “KHI”. Start -> run -> perfmon -> Performance -> Data Collector sets -> User Defined (you will see data collector set created)

5. This Data Collector set contain a list of all Performance Counters that are required for Lync Server performance analysis. (to view list of counters : KHI -> properties -> performance counters)

6. In order to run the KHI collector set, right click on KHI and choose Start.

Please note: This Data Collector should be started before the company business start and should be stopped at the end of that business day (approx. 8 hours).

7. Once the data collector is started, it will generate a CSV file under the C:\PerfLogs folder. This CSV file will contain all counters data and it will update the file every 15 seconds by default.

8. At the end of business day go ahead and stop the data collector set, right click on KHI and choose Stop:

9. Once completed we will have set of KHI performance data files stored in “C:\perflogs” location on respective Lync Servers.

1. Download KHI Importer tool from here (KHI Importer is basically a Script that we use to read the KHI output data and fill the respective values in KHI threshold file)
2. We will have 2 files ‘import_khi_data’ Script that we will run against the perf data collected (Lync KHI data) and ‘files.csv’ file (where you specify the filenames of the KHI Data)

3. Copy the KHI Importer files, Threshold file (here) and the KHI File (performance data that we collected from Lync Server) to some common location

4. Open files.csv and add the filenames of the KHI Perf data that we collected earlier from Lync server.

5. Here, you need to add all the KHI output filenames that you got as shown above, ServerType can be set to one of below, based on what data we would like to get analyzed.

1        Lync Front-End Server

2        Lync Mediation Server

4        Lync Front-End Server collocated with meditation server

8        Lync Edge Server

16      SQL Back-End Server

6. Run below command from Windows Powershell (launched with administrator rights) to initiate the process of importing the Output files and its analysis.

Import_khi_data.ps1 –CSVFile files.csv –KHIFile Lync_Server_2013_Key_Health_Indicators.xlsx –SingleServer

In the above command;

CSVFile                 files.csv (where we added the filenames of all the KHI Datafiles)

KHIFile                  Threshold file (downloaded earlier in Lync Networking Guide)

SingleServer          Optional Switch if we are running against Std edition Server

7. The above mentioned script will run for a while, during the process, all that it does is below:
   • Read the filename present in files.csv
   • Read the Average and Maximum values for each counters (which all counters depends on what ServerType was selected)
   • Fill these Average and Maximum values against the threshold values in the KHI Threshold file.
   • Once completed, you will see output similar to this in the KHI threshold file.

1. Download KHI Summarizer, It includes a CSV File that has inbuilt Macros Written
2. Copy the KHI Output files to location ‘d:\temp\khi’ (because this summarizer tool is designed to look for KHI File in this location)

3. Ensure that you have Enabled Macros in Excel to run this tool (if Macros isn’t enabled you would get warning that Macros is disabled, we can enable the same)

4. Click "summarize KHI CSVs" to import and process KHI data in a separate Sheet

5. We will get the output with summary of each counters and its average and its maximum value, as shown below:

6. Save this file over to different location for further comparison with Lync threshold file “Lync_Server_2013_Key_Health_Indicators.xslx” which is available in Lync networking guide (Lync2010 Networking Guide or Lync2013/SFB KHI ).

7.  Fill in the Average and Maximum values for Each counters in Lync Threshold file (by looking at the maximum and average values that we got summarizer output file).

In my previous post we discussed about Installing and configuring Office Web App Server 2013 and its integration with Lync Server 2013.

The purpose of this article is to understand the basic workflow from client and server standpoint on what all happens when user initiates or tries to view PowerPoint sharing session.

Also detailed troubleshooting steps on how to isolate where the issue lies (whether at client side or Lync Server side or Office Web App Server side)

This should help tackling major problems/issues that we face with Lync 2013 PowerPoint sharing using Office Web App Server 2013.

Typically issue would be that “users using Lync 2013 clients connected to Lync server 2013, aren’t able to do PowerPoint sharing” and getting Error

“Some presenting features are unavailable due to server connectivity issues”

Workflow:

In Lync 2013 Server we need Office Web App Server 2013 to render the Ppt presentation if we are using Lync 2013 Clients.

(if we use Lync 2010 client, Ppt sharing works legacy way, where there is no involvement of Office Web App Server)

Let’s talk about workflow of how Ppt sharing works if we are using Lync 2013 Client in Lync 2013 and Office Web App Server 2013 Integrated infrastructure.

1. When Lync 2013 user initiates or try to view Ppt presentation, Lync client uploads the PPT file to Lync front end server.

2. Lync 2013 Front end Server Encrypts and saves the Ppt file on to the Content file store (Lync file share) and generates File ID and Access Token for the Ppt file uploaded.

3. Lync Access server then retrieves WAC URL (stored in CMS during WAC Discovery process) and forms an URL that includes, WAC Presentation URL, File ID and Access Token of the Ppt File.

4. Lync Access Server sends this WAC URL formed to Presenter as well as attendees.

5. Lync Presenter/Attendee’s Client sends requests to this URL and contacts office web app server to get the PowerPoint presentation.

6. Once Office Web App Server receives this request it retrieves the Access Token, File ID and File location (file share) and access the Ppt file by contacting the Lync Content File store via Lync Front end Servers (Lync Web Services FQDN will also be present in the initial Request).

7. Office Web App server makes a temporary copy of Ppt file and creates html (dochtml) file and sends it to the Presenter/Attendee’s Client for Ppt presentation rendering.

Troubleshooting:

Now that we know how it works in terms of workflow, lets concentrate on step by step troubleshooting approach on how to tackle such issues.

Client side troubleshooting:

• First thing I would suggest is to use Lync 2010 Client and sign in using same account and test if Ppt feature works? If it does work, that means uploading of Ppt file and access to content file store is fine. 

• If it does work with Lync 2010 client but fails with Lync 2013 client, then we can clearly isolate the issue to be when office web app server is involved in Ppt sharing (that’s doesn’t mean that its office web app server issue, it could be client side issue or configuration of Lync Server side issue as well)

• Use fiddler tool and check if Lync 2013 client is at least attempting Office Web App Server presenter/participant URL or not; To do that follow below steps:

            Download fiddler tool here:

            Launch Fiddler -> Tools -> Fiddler Options -> HTTPS -> Decrypt HTTPS traffic -> Install fiddler Root Certificate.

• When fiddler is running, reproduce the issue by initiating a PowerPoint sharing, Look at fiddler captured requests to see if client is attempting Office Web App Server URL or not.

• If we don’t see any requests towards office web app server url from the client in fiddler, which means client doesn’t even know what URL to use for contacting Office Web App Server

• If we go back to process flow, who gives Office Web app server URL to client? it’s the Lync server which forms WAC URL with Ppt file id and access token and sends to Lync 2013 Clients, So if client isn’t attempting the URL, that means Lync Server haven’t been able to send Office Web App Server URL.

Server Side Troubleshooting

• First thing to do in this case is to check on Lync front end servers to see if we have LS Data MCU 31042 event or not (this event could appear when you publish topology or when web conferencing service is restarted)
  

• Event Logged on Front End Server Upon Successful Discovery of WAC Server/URLs (this happens first time when we add WAC Server to topology and publish or publishing the topology or upon restart of Lync Server Web Conferencing Service)

• If we don’t see 41032 event that to recently after any changes that was done on office web app server, then filter for LS Data MCU Events and you will see 41033 event indicating, failure to discover Office Web App Server URLs; This means, Lync server wasn’t able to contact office web app server to get the WAC URLs.

• In this case, follow the configuration steps and verify if all configurations are done correctly or not 

1. WAC URL and Certificate correctly configured in Office Web app Server farm or not?

2. Whether certificate on the WAC Server contains the URL Wac.contoso.com?

3. Have we mentioned the same URL Wac.contoso.com in WAC URL field in Lync topology Builder or not?

4. Is the WAC discovery URL Https://wac.contoso.com/hosting/discovery browsable without any certificate alert from Lync server or not?

• Unless we get 41032 Event on the Lync Front End Server, Front end server won’t be able to form WAC URL and send it to Lync 2013 client when they try to initiate Ppt sharing.

• Issue Cause can be anything, WAC URL not being resolvable to an IP address or certificate on WAC Server doesn’t contain WAC URL or WAC URL is incorrectly mentioned in the Lync topology builder or an issue with office web app server itself.

• We would have to verify all these one by one and take corrective actions to get it through to have Lync server to be able to discover office web app server URL.

Advanced Troubleshooting:

• Now after fixing the above issue or if we are already getting LS Data MCU 41032 Event, however if issue is still occurring then perform below steps:

• Use Fiddler Tool again and reproduce the issue and see if its attempting WAC URL (since there is 41032 event on Lync FE Server, client should be attempting WAC URL)

• While we have Lync ppt sharing session in progress on Lync Client copy the URL from Fiddler and try to view presentation from a browser

  To do this -> Select the first request -> Copy -> just URL -> Open a browser -> Paste and hit Enter

• Even on browser if we are not able to view presentation, then there is some issue with office web app server itself (WAC Server itself or WAC Accessing File store), need to streamline and troubleshoot on Office Web App Server.

• First to rule out any Lync server side issue, try to resolve the Web Services URL that Office Web App server is attempting to get the ppt file.
  

• Use fiddler and select the request -> copy -> Just URL -> paste it in notepad -> see whats web services URL in it (see screenshot below) -> try to resolve this URL from Office Web App Server and ensure that its resolvable.

• Now that we have isolate issue to be with Office Web App Server, we can collect ULS Logs from Office Web App Server located in C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS and

  use ULS Viewer to look at the logs based on Correlation ID or look at event viewer or engage office web app server specialists to assist on the same.

• Look at the Fiddler trace to get Correlation ID in the initial Requests.

• Using the Correlation ID that you got from the Fiddler trace, filter ULS log using ULS Viewer

• Still if we couldn’t figure out, then it’s best to engage Office Web App Server specialist to have a look at these date and event logs on Office Web App Server.

• From Lync Server side, we can also take CLS Logs for WAC Server scenario for troubleshooting issues on WAC discovery issue on Lync server.

Start-CsCLSLogging -Scenario WAC

Stop-CsCLSLogging -Scenario WAC

Search-CsCLSLogging -OutputFilePath C:\WAC.log 

• From these logs we would see below entries if its successful, if not would see respective Exception errors in case of a failure.
  

• Please note: There are situations where when you try to browse the WAC URL using browser you are able to get presentation, but using Lync 2013 client its giving an error, Please look to see if you are falling under IE11 issue with Office Web App Server (Here) and take corrective actions.

Overall above details just guides you through the troubleshooting steps which we can use to to isolate if issue is at client’s side or office web app server side or Lync server and take corrective actions accordingly to fix the same.

Hope the above information helps!

Pragathi Raj S

Support Engineer – Microsoft iGTSC

The purpose of this post is to show step by step Installation and Configuration of Office Web App Server and its Integration with Lync Server 2013.

There are lot of blogs and articles on this, right from how to install Office Web App Server till integrating with Lync Server 2013, but I thought I would simplify each configurations step by step with screenshots so that even a beginner would be able to configure this and get it working just by following the steps.

There are multiple things involved in making Lync server to be able to use Office Web App Server to provide PowerPoint sharing feature for Lync 2013 clients, if we divide those into simpler steps, below are the step by step configuration procedure.

1. Installing Office Web App Server 2013 Application.

2. Generating Certificate for office web app server.

3. Creating Office Web App Server farm.

4. Integrating Office Web App Server with Lync Server 2013.

In this article we are going to use a simple lab setup with single Office Web App Server and Lync Standard Edition Server as shown below:

Without much ado, Let’s get started!

1.  Installing Office Web App Server 2013:

Before running setup, we need to Install Prerequisites on machine with supported operating system for Office Web Server 2013.

(you can refer here for information on supported Operating system and additional software required)

Install bellow additional software which are prerequisites for Installation of Office Web App Server.

• .NET Framework 4.5

• Windows Management Framework 3.0

• Windows Identity Foundation

• Web Server (IIS)

Installation of Office Web Server Application is straight forward, Run Setup file and follow below steps to complete the installation.

At this point we have completed the installation of Office Web App Server.

2.  Generate Certificate for use in Office Web App Server

Next step is to get a valid certificate generated so that it can be used with Office Web App Server farm, there are different ways to generate the certificate, directly from certification Authority, using different applications and etc, however simpler way is to use IIS which was installed as one of the prerequisites earlier.

We will use one of the Web Server component called ‘Server Certificates’ to generate the certificate request, below are the steps:

From the Office Wep App Server Launch IIS Manager -> Select the Server name -> in features pane, select ‘Server Certificates’

Select ‘Create Certificate Request’ from Actions page.

Fill in the details, Common name is nothing but the Actual URL you are going to use for Office web app server (Issued to name) 

Select RSA and you can Select either 1024 or 2048 for Bit Length

Now we have certificate Request file like below.

Now that we have generated certificate request, we could proceed with getting issued by an internal certification authority or you can go for public Certificate, Decision is purely based on whether you want users to access WAC Internally only or from external machine as well.

If we are to allow Ppt sharing with external folks or federated contacts or from different machines that doesn't contain Internal Root CA Certificate, it’s good to go for third party certificate as its by default trusted on most of the machines.

In our scenario, we are going to use internal Certification Authority to issue the certificate.

To Issue the Certificate, Go to Certification authority Certsrv Webpage using http://Dc.contoso.com/certsrv or https://Dc.contoso.com/Certsrv  -> Select 'Request a Certificate' option.

Select 'Advanced Certificate Request'

Select 'Submit a certificate request by using base-64-encoded cmc' as we already have request file.

Copy the content of Certificate request file generated earlier using IIS and pasted it in the box as shown below -> Select 'Web Server' Template -> Click on Submit

On successful issue of certificate we would get below option to download the certificate; Select Base 64 Encoded -> download Certificate.

Now that we have certificate issued, we can go ahead and install it on Office Web App Server.

To do that, Load Certificate console start -> run -> mmc -> Add/Remove Snap in -> Certificates -> Add -> Computer Account -> Local Computer -> Finish -> OK

Go to personal store as shown below and import the certificate that we just got.

We are not done yet, just one last step. By Default certificate created using above method will not have the friendly name, however we would need Friendly name to be present which will later be used to associate this certificate with Office Web App Server.

Select the certificate -> Go to properties

Add a Valid Friendly Name (just a name for later use) -> click Apply -> OK

Now we have the valid Certificate Ready to be used for Office Web App Server Application.

3.  Create new Office Web App Server Farm:

Installation of Office Web App Server itself isn’t sufficient for it to be functional it only installed the bits and components of Office web app server, Further we need to create a Office Web App Server Farm and associate certificate.

Using Windows PowerShell, we can run below command to create the Office Web App Server Farm:

New-OfficeWebAppsFarm -InternalUrl Https://wac.Contoso.com -ExternalUrl Https://Wac.Contoso.com -CertificateName WacCert -AllowHttp

In the above command, wac.contoso.com would be the Office Web App URL that we will be using (using same for internal and external, however this can be changed as per requirement)

InternalURL Refers to URL that will be used by Lync 2013 Clients connected to Lync server internally.

ExternalURL Refers to URL that will be used by Lync 2013 Clients connected to Lync server Externally.

CertificateName is set to ‘WacCert’ which is the friendly name of the certificate that we created earlier.

Verify if Office Web App Server Farm is functional by browsing the discovery URL Https://Wac.Contoso.com/Hosting/Discovery , we should get below response.

At the end of this step, we have installed office web app server, created a Office Web App Server Farm and have associated valid certificate that was created earlier, Office Web App Server is now Ready.

4.  Integrating Office Web App Server with Lync 2013 Server

Now we are in the last step of this article. To Integrate Office Web App Server with Lync 2013 Server perform below steps:

Use Topology Builder and Define New Office Web App Server as below:

Associate Front End Pool with Office Web App Server by performing below actions:

Using Topology Builder -> Select FE Pool -> Edit Properties -> Select the checkbox ‘Associate pool with Office Web App Server’ -> dropdown and select WAC Server -> Publish Topology

To confirm the successful office Web App Server Integration, Monitor the Lync Server Application Log to see below Entry, this Even suggests that Lync Server has discovered the Office Web App Server URLs.

Now that we have installed and configured Office Web App Server and also integrated with Lync server 2013, Lync 2013 clients can make use of this to use PowerPoint sharing feature.

Hope the above information helps!

Pragathi Raj S

Support Engineer – Microsoft iGTSC

PS : In my Next Blog I am going to write on Troubleshooting Office Web App Server Integration with Lync Server 2013.