Within the Skype for Business client, open your options by clicking the gear icon () in the upper right corner.

Locate the drop down for "Logging in Skype for Business"

1. Download LyncTracing.zip and extract it.
2. Run MaxLyncTracing.reg
3. Restart the Skype for Business client to allow these keys to take effect.

• For Lync 2013/SfB 2015 the Tracing folder is located at:
  • %localappdata%/Microsoft/Office/15.0/Lync/Tracing
• For SfB 2016 the Tracing folder is located at:
  • %localappdata%/Microsoft/Office/16.0/Lync/Tracing

• If the issue is easily reproducible then follow these steps:
  1. Exit the Skype for Business client.
  2. Navigate to the Tracing folder outlined above.
  3. Delete the contents of the folder.
     • Some items may not be able to be deleted if other applications such as Outlook are running.  These can be safely skipped.
  4. Launch the Skype for Business client and reproduce your issue.
  5. Once completed, exit the Skype for Business client.
  6. ZIP the entire Tracing folder.

• If the issue is intermittent or unpredictable, then follow these steps:
  1. Continue to use your client until the issue occurs.
  2. If possible, exit the client as soon as possible after the issue reproduces.
  3. ZIP the entire Tracing folder.

• Once you have the ZIP file containing your Tracing folder, provide it to the support individual you are working with.

• A description with the timeframe and steps taken to get the issue.
• Screenshots of the behavior.
• If requested, supplemental logs from another source, such as a network trace or Fiddler trace.

OPTIONS https://director.nny.local/WebTicket/oauthtoken HTTP/1.1
Accept: */*
Origin: https://webdir.nnylync.info
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type, accept, x-ms-origin

HTTP/1.1 400 Bad Request
X-Ms-diagnostics: 28020;source="Director.NNY.local";reason="No valid security token."
X-MS-Server-Fqdn: Director.NNY.local

Well this is odd, an OPTIONS request?  Understanding what is going wrong here requires a little understanding of the same-origin security policy enforced by most modern browsers.  As a protection mechanism, browsers will not allow a website loaded from one domain name to make XMLHttpRequest requests to a different domain.   This creates a little conundrum for our UCWA API, since one of the goals is to allow people to embed Lync features into their own web applications.

To securely work around this, UCWA leverages an iframe which loads a page from the UCWA API, and then it uses the HTML 5 postMessage function to have it send HTTP requests to that iframe.  You can get more details here: https://ucwa.lync.com/documentation/GettingStarted-CrossDomain

There are other methods for managing cross-origin requests, and this explains how we end up with our OPTIONS request.  A mechanism called Cross-Origin Resource Sharing (CORS) can be used by browsers to authorize the cross-origin request.  You can get details about CORS here: https://www.w3.org/TR/access-control/

If a browsers sees that a cross-origin request is about to occur, it will first perform a preflight request to see if the resource is aware of CORS.  That preflight request takes the form of the OPTIONS request that we see.  Unfortunately UCWA does not support/implement CORS, so this request fails and the startup process terminates.

Since UCWA should be using the iframe, however, why would the browser think a cross-origin request is occurring?  Looking one step back in our trace will give us an answer.

During the UCWA startup process, we reach the point where we make our request to the autodiscover service, and we get our first 401:

GET https://webdir.nnylync.info/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=nnylync.info HTTP/1.1

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer trusted_issuers="", client_id="00000004-0000-0ff1-ce00-000000000000"
WWW-Authenticate: MsRtcOAuth href="https://director.nny.local/WebTicket/oauthtoken",grant_type="urn:microsoft.rtc:windows,urn:microsoft.rtc:passive,urn:microsoft.rtc:anonmeeting,password"

Note that our request here is going to webdir.nnylync.info, however the MsRtcOAuth href in the response is directing us to director.nny.local. For context, webdir.nnylync.info is the external web services FQDN for my director pool, and director.nny.local is the internal web services FQDN for my director pool.

Now this begins to make some sense.  We have an iframe for webdir.nnylync.info, but our next request would be trying to go to director.nny.local which would be cross-domain.

So the real question; why is the MsRtcOAuth href directing us to director.nny.local?

The answer is that it is based on which IIS website we hit on the front end.  Lync has two websites, Lync Server External Web Site, and Lync Server Internal Web Site. The internal website operates on 443.  The external website operates on 4443.  Additionally in the Lync topology you define an internal and external web services FQDN for each pool.

It is expected that requests coming in from the public internet will be going through a reverse proxy which will apply a port translation rule going from 443 to 4443.  Therefore all requests from the public internet should land on the external website, and requests on the internal network can land on the internal website. 

UCWA understands whether it is running on the internal or external side, and this will change which FQDN's get returned in responses.  Since the MsRtcOAuth href contains the internal web services FQDN, that means our request must be landing on the internal website.

In this case, the fact that we hit the internal website while having used the external web services FQDN is the problem.  UCWA is designed to channel all traffic through the external web services FQDN.  This is done for use cases where a device (like a mobile app) could transition from the internal and external networks throughout the day.  In order to keep a consistent connection point for the application, UCWA requires all traffic, both internal and external, to go through the external web site. 

That means that the external web service FQDN resolved by an internal user should still point to the public IP/outside interface IP of the reverse proxy.  It should NOT be going directly to the front end server/director IP.

This image, coming from TechNet documentation, shows this scenario well.

You can see these articles for more details regarding this:

https://ucwa.lync.com/documentation/ITAdmin-Architecture

https://technet.microsoft.com/en-us/library/hh690030.aspx

Also, for a small test environment that does not have external access configured, you can work around this problem by simply making the external web services FQDN match the internal web services FQDN in the Lync topology.  Then, regardless of the situation, all connections should land on the Lync internal web site, and since the two web services FQDN's match, there is no cross-domain issue.  This should only be done for test environments, since making this change would cause breaking issues in a production environment where external services are expected to work on the public internet.

If you check the HTTP response you'll see:

HTTP/1.1 400 Bad Request
Content-Length: 25
Content-Type: application/json
X-Ms-diagnostics: 28020;source="Director.NNY.local";reason="No valid security token."

{"error":"invalid_grant"}

At its core, invalid_grant simply means you were unable to be authorized.  Possibly bad credentials, or some other reason.  (See https://ucwa.lync.com/documentation/GettingStarted-Authentication)

However in this case people will swear they are putting in the correct information.

The reason for this failure is actually pretty simple, but due to the design of the sample it is not always the first thought that comes to mind.  The sample only includes a field for your Sign-in address and password, but no username.  It makes an assumption that the users SIP sign-in address will be the same as their UPN.  If this is not valid for the environment the sample is running in, then there is effectively no way to sign into the sample without making some changes.

The simplest solution is to just add a 3rd text box to allow a username to be entered separately from the sign-in address:

Attached are some changed sample files that can be used to achieve this.

UCWASamples Login Fix.zip

HTTP/1.1 500 Internal Server Error
X-Ms-diagnostics: 28032;source="Lync-SE.NNY.local";reason="The web ticket is invalid.

If you follow the steps listed on https://ucwa.lync.com/documentation/KeyTasks-CreateApplication then the first time the problem will surface will generally be on Step 9.  Instead of getting a 201 as expected, you may get the above 500 error instead.  The reason this occurs is because you have used a web ticket from one pool when trying to communicate with a different pool.  Web tickets are only valid on the pool which issued them. 

You may have to change pools because your environment uses directors to service lyncdiscover.domain.com, or you have multiple Lync front end pools and lyncdiscover.domain.com is pointed at Pool A, but your actual user account is homed on Pool B.  In either of these cases, your initial connection steps will be completed against the pool servicing lyncdiscover.domain.com up to step 8.  At step 8 if your account is hosted on a different pool, then the _links provided will have the external web services FQDN for your home pool, instead of the FQDN you had been connected to up to this point.

This may look something like this:

GET https://webdir.nnylync.info/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=nnylync.info HTTP/1.1
Authorization: Bearer cwt=AAEBHAEFAAAAAAAFFQAAALtGgOI4o_RhEkWWK1MEAACBEDp8srKSInRRsMUh3b7vStaCArAQgyCi3SnwxgLCUr_YoF_XOv0-ZnI-np_NhzH8eCu_yHEXfoYIXmTYAt5_0QgNEDp8srKSInRRsMUh3b7vStY

HTTP/1.1 200 OK
Content-Length: 269
Content-Type: application/json

{"_links":{"self":{"href":"https://lyncweb.nnylync.info/Autodiscover/AutodiscoverService.svc/root/user"},"applications":{"href":"https://lyncweb.nnylync.info/ucwa/oauth/v1/applications"},"xframe":{"href":"https://lyncweb.nnylync.info/Autodiscover/XFrame/XFrame.html"}}}

If you'll note, the GET was sent to webdir.nnylync.info, while the _links in the response are all to lyncweb.nnylync.info.

If we then blindly proceed with step 9 and send the POST to https://lyncweb.nnylync.info/ucwa/oauth/v1/applications while including the Authorization header, then we will run into the 500 error response, since the web ticket we have is issued for webdir.nnylync.info, and is not valid on lyncweb.nnylync.info.

The best way to deal with this situation will be to detect when the domain for our request changes, and if it does, omit the Authorization header.  By omitting the Authorization header the connection to the new pool will throw a 401 allowing you to retrieve a new web ticket from the new pool.  Basically you can jump back to step 4, proceed to the point where you have the web ticket at step 6, and then resume your request on step 9 and include the new web ticket in the Authorization header which should now succeed since it is a web ticket from that pool.

Continuing from the previous response it might look like this:

POST https://lyncweb.nnylync.info/ucwa/oauth/v1/applications HTTP/1.1
Accept: application/json
Content-Type: application/json

{"userAgent":"UCWA Samples","endpointId":"380a9e10-c680-488c-8f15-94e7cd87d28f","culture":"en-US"}

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer trusted_issuers="", client_id="00000004-0000-0ff1-ce00-000000000000"
WWW-Authenticate: MsRtcOAuth href="https://lyncweb.nnylync.info/WebTicket/oauthtoken",grant_type="urn:microsoft.rtc:windows,urn:microsoft.rtc:anonmeeting,password"

POST https://lyncweb.nnylync.info/WebTicket/oauthtoken HTTP/1.1
Accept: application/json
Content-Type: application/x-www-form-urlencoded;charset='utf-8'
Content-Length: 57

grant_type=password&username=nny%5Cfry&password=********

HTTP/1.1 200 OK
Content-Length: 250
Content-Type: application/json

{"access_token":"cwt=AAEBHAEF...FECMUFwI","expires_in":28132,"ms_rtc_identityscope":"local","token_type":"Bearer"}

POST https://lyncweb.nnylync.info/ucwa/oauth/v1/applications HTTP/1.1
Accept: application/json
Content-Type: application/json
Authorization: Bearer cwt=AAEBHAEF...FECMUFwI
Content-Length: 98

{"userAgent":"UCWA Samples","endpointId":"380a9e10-c680-488c-8f15-94e7cd87d28f","culture":"en-US"}

HTTP/1.1 201 Created

Attached is a version of Authentication.js which has been modified to handle this scenario.  It may not be the best solution, but this should demonstrate the process outlined above and allow the sample to work in this kind of topology.

Authentication.js