There are some great deep dive articles on the internet about the Lync / Skype for Business sign in process. I wanted to add to these by looking at the process from a client perspective. What is the actual workflow and behaviour of the client when a user attempts to login from a workstation?

In an attempt to explain this process I have put together a workflow chart that lists all the key decision / request points the client makes on its journey to sign in the user which we will come to later (If you don’t want to read – scroll to the bottom). First, to gather the behaviour I interrogated the local application log file and followed the log from client launch to first instant message. (Apologies in advance for the abundance of screenshots).

Stage 1 – Local Hardware Discovery

Seems only logical that the client must first discover what peripherals and hardware it has to work with. Therefore the client first interrogates the system to see if it has a webcam available using it’s media manager service

Once discovered, the client then proceeds to set that device as the default video media device

Once set, the client then decides which networking adapter to use for its connection. From experience this is decided by two variables:

1. The network adapter preference order in Network Connection settings
2. The interface that has the perceived route to the network (default route or defined route)

The client does not actually log the network adapter / interface it has chosen, but it does log the ones that it believe cannot be used

Next up is the media device service (I keep calling it a service – but it really is a method within the code) discovers the earphone to be used as the primary peripheral. Once discovered, the earphone is set as default and the volume settings retrieved.

Then the media device service discovers available microphones in the same manner and retrieves

Once complete the media device manager then sets the default device for both ear and microphone including their respective volume settings

Stage 2 – Initial Discovery

Once the hardware has been discovered and initialised, the client will then attempt to sign in. However, first it must discovery the SIP domain and obtain and resolve the correct DNS records in order to send the sign in requests. This is done by the DNS resolver manager service. This is started almost immediately from when the client first launches

Once completed the DNS discovery phase, the discovered records are logged in the client

The client then attempts a TCP socket connection to the discovered access edge service using the chosen internal interface and the information discovered by DNS

Stage 3 – Register

Once the TCP socket has connected, the client sends a register request that contains, but this is denied because authentication has not been performed

Unauthorised response:

The client then attempts to authenticate itself to the Skype for Business deployment, identifying itself as a Remote User, will perform TLS-DSK authentication to the certificate provisioning service of the front end server

The registration is then re-attempted using TLS to obtain the authentication validation from the certificate provisioning service

Successful TLS connection and TLS-DSK authentication established:

Once established the client then attempts a re-register again to register the user. This time declaring TLS-DSK as the authorisation by proxy.

If successful we get a SIP /200 OK response back

At this point the client will register with the required Edge server pool to use as it’s connection point

Confirmation of successful registration will be found in the log

Stage 4 – Login

Up to now, all the client has done is authenticate itself with the Skype for Business server and registered as an endpoint via the Edge server pool. Now the client needs to log the user into the system. This is done by formulating an XML request on the client that contains the user certificate and discovered data from the discovery / registration stages.

If successful the client creates a subscription to the Front End server and then sets the presence or presentity for the user

Stage 5 – Setting up

After setting the presence of the logged in user the client sends a service message to the Front End to collect the location profile of the user (not E911 and location services). This is for dial plan assignment

Response received

<LocationProfileDescription xmlns=”http://schemas.microsoft.com/2007/03/locationProfileDescription”><Name>XXXX_dial_plan</Name><Rule><Pattern>^(\d{6})$</Pattern><Translation>+441785$1</Translation><InternalEnterpriseExtension>false</InternalEnterpriseExtension></Rule><Rule><Pattern>^0([1-9])(\d*)$</Pattern><Translation>+44$1$2</Translation><InternalEnterpriseExtension>false</InternalEnterpriseExtension></Rule><Rule><Pattern>^(00)?([1-9])(\d{5,})$</Pattern><Translation>+$2$3</Translation><InternalEnterpriseExtension>false</InternalEnterpriseExtension></Rule><Rule><Pattern>^(999$|112$|123$|101$)</Pattern><Translation>+$1</Translation><InternalEnterpriseExtension>false</InternalEnterpriseExtension></Rule><Rule><Pattern>^\+440(\d{10}\d?\d?)</Pattern><Translation>+44$1</Translation><InternalEnterpriseExtension>false</InternalEnterpriseExtension></Rule><ExternalAccessPrefix>9</ExternalAccessPrefix><OptimizeDeviceDialing>true</OptimizeDeviceDialing></LocationProfileDescription>

After the correct dial plan has been assigned, the client then reserves the default media port ranges to set for audio, video, content sharing and file transfer

Next the client calls for the user’s contacts and delegates, whether they are Skype for Business contacts or UCS enabled contacts using the subscription manager

While the client is waiting for the contact data to be returned from the Front End server, it makes further subscription calls for the user and device configurations.

Once requested, the front end server returns the data back to the client, starting off with the contact groups and the contact mappings

Once the contact list has been populated, the client then collects the federation settings for public providers such as Skype consumer, sets the dial plan as active and collects the server configuration it needs to ensure it can communicate (typically the information you receive in the configuration information screen).

(screenshot is a limited display of all the settings – limiting to prevent a really long blog becoming even longer).

Essentially this response contains in addition to the above:

• Conferencing Policy Settings
• Media Ports (QoS reconfiguration based on policy)
• Client Policy Settings
• Voice Policy Settings
• E911 settings
• CAC settings
• Location settings
• PSTN usages
• Persistent Chat settings
• Photo URL
• Voicemail enable settings
• User data (custom locations etc)
• Call via Work settings

After this has completed, Exchange calendar information is discovered from Exchange EWS / MAPI and once retrieved the user’s contact card is updated

After this has succeeded, the personal note history is downloaded

Followed by another contact card update. Exchange UM then returns any unread voicemails using the MWI feature

Followed by any missed conversations from conversation history

The last user configuration settings are to set the user’s DDI, extension and set their Exchange UM URL

Now the user has all of their settings to operate with full functionality. However, there are some further steps the client takes that are done in-band. These are more to do with contact availability and presence information than user specific settings.

Stage 5 – After thoughts

The user’s contacts are iterated by the subscription service and are discovered as either “Same Enterprise” or “Federated” contacts. This is then used to decide on how Skype for Business will discover the contacts presence status

Then the client tries to find those contacts, by internal lookup or external partner domain discovery

And then request their presence information

Finally the machine sends a Notify message to the front end to declare it is ready and available (availability set to 3500)

A bit of a long winded explanation, but to recap below is a nice simple flow chart that shows this entire process from start to finish