Skype for Business Client Sign in Workflow Chart (External)
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:
- The network adapter preference order in Network Connection settings
- 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
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
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
Mark is an Independent Microsoft Teams Consultant with over 15 years experience in Microsoft Technology. Mark is the founder of Commsverse, a dedicated Microsoft Teams conference and former MVP. You can follow him on twitter @UnifiedVale