Code – UCWA in C# – Part 01 of 05

This post is part 1 of a series of 5 on writing C# applications using UCWA 2.0.

I used Microsoft Visual Studio Community 2015 running Windows 10 and targeted Windows Desktop Application to .NET Framework 4.6.1. The application illustrates the steps like autodiscover both internal and external and the different steps involved to logon. Next some examples of using resources like Note, Location, Presence and sending a Hello World IM as well as Call via Work.

In upcoming posts more advanced code, handling redirects, implementing event channels, keeping the application alive and handle both incoming and outgoing conversations.

Later on more complete implementation of the remaining documented features of UCWA implemented, and how to access the less documented modalities such as audio and video.

In the App.config nothing special, just added the defaultProxy allowing my program to run in our company behind firewall and proxy server that would else block HTTPS traffic.


In Program.cs nothing special, just launching the Form1. The code is intended for illustrating the UCWA concepts, therefor quite old-style monolithic.


Applications based upon UCWA have different authentication possibilities, here I use the password grant type. We need to provide a number of parameters, the user interface provides text boxes to enter these and as well as a ‘Safe profile’ button to save them for later retrieval. The profiles are stored in XML files located in the same directory as the executable, below a sample altered with dummy data.

Below a screenshot of the user interface of the main screen. The top section is for entering authentication and define logging level. The middle section is user Logon, Report my Activity and get and set Presence, Note and Location. The bottom fields are used for sending IM and perform Call via Work.

Finally the code of the Form where everything happens. The code is quite self explaining, I am use httpClient with async and await to have a responsive application supporting the GET and POST requests from UCWA. For sake of illustration I used both XML and JSON formatted REST requests, therefor references as shown below.


The Logon button can be clicked to launch establishing an UCWA session.

The logon process actually requires multiple sequential steps, for clarity I named the Logon_Step00 up to Logon_Step08.

First we attempt autodiscovery to lyncdiscoverinternal. When you are located internally these requests will typically be completing normally using internal DNS resolving, and the request will be directed the internal IIS of Front End Server pool.

When you are located externally that step will typically fail as lyndsicoverinternal is not defined in public DNS. So next we try lyncdiscover, that request will rerouted through your Reverse Proxy Server to the external IIS of the Front End Server pool.

Opposite to Microsoft UCWA documentation I prefer using the header application/;v=1 as it returns much more information than the JSON format.

After following the sequence of 7 steps logon is complete and your have access to all resources. The code is quite self-explaining and is following UCMA documenation.

Please not that in most of my global customer environments we have multiple sip domains, multiple pools and multiple datacenters and optionally directors. This means that the lyncdiscover may be pointed to the reverse proxy infrastructure of one datacenter, while the user may be homed in another datacenter. When this is detected in step 05, authentication header is cleared and logon resumes back on step 02 on the datacenter where the user is registered. Also in environments where directors are in place this will provide the logic for authenication. Underlying reason is that webtickets are associated to pools and new webtickets are needed when redirection to different pool is needed.

Now the logon is complete, and we have all the needed resources available at least for a few minutes. Actually we should implement a regular ReportMyActivity to keep the session active, but that is for later. Below some general use routines.

I have added capabilities to log to the user interface (ListBox) as well to text based files (Disk). The combo boxes allow defining the level of details, the higher the value the more details you get. Log files are typically handy to perform low level analysis of technical issues, such as debugging UCWA, Skype for Business Web App, Skype for Business Mobile Clients etc… Please be aware that the higher values also store sensitive data such as authentication info (domain, user, passwords…) and other sensitive data (sip addresses, tokens, topology details…). Make sure to remove them afterwards or replace sensitive content with dummy values before distribution.