The Lyncdude

Plan Skype for Business to Microsoft Teams Migration

Tohamey - MSFT — Wed, 18 Apr 2018 14:19:46 GMT

Howdy, I talk to many customers every day about the possible migration options or as we call it in Microsoft "Upgrade Journey" from Skype for Business to Microsoft Teams and decided also to write an article explaining and trying to simplify those options. Depending on the customer's business requirements, one of those options could be used. So let's keep it clear here, our goal in the end is to move all users from Skype for Business to Microsoft Teams and start using Teams-Only. In our journey to reach that end state some interop between both platforms will take place and that won't happen without a hybrid configuration with Skype for Business Online. So if the customer is running Skype for Business On-Premise, they will need to start planning and configuring Skype for Business hybrid before moving to Teams-Only infrastructure. Please keep in mind those methods are still being worked on, and keep an eye on our official documents for any updates (found here).

Migration Modes

We introduced five upgrade modes, how i explain it to my customers is think of it like 5 scenarios of how they can use and run Skype for Business and Microsoft Teams in their organization. Those scenarios are not the migration options I'm speaking of, we use one or a combination of those scenarios in our migration options, keep reading you will get it by the end of the article :) :

Island Mode: default mode / scenario, where both products running separately from each other, meaning chat (previously known as instant messaging) that happens on Skype for Business stays in Skype for Business and the chat that happens on Teams stays in Teams.
Skype for Business Only Mode: Users are using only Skype for Business and are disabled for Microsoft Teams, some users might be enabled for some specific interop options with Teams, users want to join Teams meetings will have to use the web browser.
Microsoft Teams Only Mode: Users are using only Microsoft Teams and are disabled for Skype for Business, users with Teams-Only mode will have to use Skype for Business web client to join scheduled Skype for Business meetings.
Microsoft Teams Collaboration Only Mode: User will use Teams only for collaboration, meaning Teams and channel conversations only, rest of modalities (chat, A/V calling and meetings) will be done on Skype for Business.
Microsoft Teams Collaboration & Meetings Mode: Users will use Teams for collaboration (as described above) as well as meetings, rest of modalities as in chat and A/V callings will be done on Skype for Business.

For Mode 4 and 5 (Microsoft Teams Collaboration Only and Microsoft Teams Collaboration & Meetings), customers must choose one client only to be used for chat and callings, allowing both clients for both type of modalities will confuse the users and cause bad adoption. As noticed above, 3 modes have chat, calling and meetings provided by Skype for Business, also note that 4 modes have both Teams and Skype for business, and one has Skype for Business only. One more time I have to say that here again and now that I explained the different modes, for the interop between both products to work as described above, the customer must configure and run a hybrid Skype for Business deployment.

Migration Options:

Now that those modes were described, we provide two migration options, or as we call it in Microsoft "Upgrade journey":

Simple Upgrade Journey
Gradual Upgrade Journey

1. Simple Upgrade Journey

In this options, Microsoft Teams is deployed to all users in the organization and configured to run with Skype for Business using the Microsoft Teams Collaboration Only Mode that was explained above. This allows the customer to run and evaluate Teams and make the cutover once they think that Teams is ready to be the solo collaboration and communications platform in the organization.

2. Gradual Upgrade Journey

In this option, Teams is deployed and used in the organization, it will be used in different upgrade modes, some users will have the Island only mode, some others will have Collaboration only mode and so on. As time passes, those users will be moved gradually to Teams Only mode, by the end of the project all users will be running on Teams only and Skype for Business will not be used anymore. In the end, customers should use the migration option suitable for them and their business needs, more information can be found here and I hope I managed to simplify it for you :)

Simple Understanding of Skype for Business Databases

Tohamey - MSFT — Wed, 18 Apr 2018 12:51:09 GMT

Howdy, in the journey of moving my old articles from Lyncdude.com to this blog I decided to include this one in the migration about let’s say Skype for Business databases anatomy, I’ll be talking about a simple SfB pool installation and databases included with it.

Overview of Skype for Business Database Architecture

First things first, in Skype for Business there are couple of places that databases are usually installed, depend on your Skype for Business pool design

Enterprise Edition Front end Pool – Master databases (XDS) installed on SQL backend server and a read-only copy is installed locally on the front end servers, some of the databases are hosted primarily and only on the backend like Monitoring, Archiving, Persistent chat.
Standard Edition Front end Pool – both master & copy databases are installed locally on the Front end server (SQL Express)
In My lab I have an Enterprise front end pool with a SQL backend server, so I’ll be talking about two locations where databases are installed on the SQL backend and the front end servers. In case of a standard edition front end pool those databases are installed in one location – the front end.

PowerShell command Get-CsConfigurationStoreLocation can help locating the server used as Skype for Business Backend

RTC instance, RTC and RTCLOCAL...huh?!!

for some engineers with limited understanding of SQL (like me), they might get confused when talking about too many use of the word RTC in a conversation, and if you include RTCLOCAL to the conversation they just start fade away so let’s clear things up shall we?

Instance: think of a SQL Instance as a container that have Databases inside it.
Database: well database is where the data is actually stored
taking this definition and apply it to Skype for Business databases we get the following
RTC Instance is used by Skype for Business to store all the backend databases, including the master CMS, Response Groups configuration, location database…etc.

NOTE: RTC is the default name of the Skype for Business instance, but it can be changed during deployments.

RTC Database is used by Skype for Business to store persistent user information like scheduled conferences, contact lists..etc.
RTCLOCAL Instance is used by Skype for Business front end server to store a local copy of the master CMS database and other database used for some user information (presence, endpoints..etc.) explained later in this article.

you can learn more about RTC & RTCLOCAL from my previous article Simple understanding of Skype for Business / Lync CMS

Skype For Business Databases

Now let’s talk about the type of each of those databases you see and what are they used for. In Skype for Business there are number of database types I used the way TechNet divided them with small different (full list can be found here)

Application
Archiving & Monitoring
Central management
Skype for Business Core
Users

Application Databases

following databases are considered “Application” databases

CPsdyn: contain dynamic information used by Call Park application like “Orbits”

RGSConfig: contain the configuration of the Response Groups, like Agents, Workflows, Queues, Holidays…etc.

RGSDyn: contain dynamic “live” information used by the Response Groups

Archiving & Monitoring

I think the name explains it well, just pay attention that usually those databases are installed on a different SQL instance, not the default one.

LCSLog: archive information about Instant messaging sessions, P2P calls and conferencing used by the archiving server.
LCSCdr: store the call details records used by the monitoring server.
QoEMetrics: store information about Quality of Experience used by the monitoring server.

Central Management

XDS: this is the Skype for Business heart, it holds Skype for Business topology, configuration and polices (more details: Simple understanding of Skype for Business/ Lync CMS)
Lis: store location information (network subnets, ports, Switches...etc.) that is used by Skype for Business Location services for E9-1-1 feature.

Skype for Business Core

Following databases are usually installed on both the RTC and RTCLOCAL instances

RTC: as mentioned before, it store persistent user information (contact list, scheduled conferences…etc.)
RTCDyn: Store dynamic “live” data about users (current presence, endpoints user logged in from…etc.)

Users

RTCAB: store the Skype for Business address book information used by Skype for Business address book services
RTCXDS: store a back up of user data

that’s all, a small quick and to the point explanation of Skype for Business databases types and functionalities, hope you found it helpful.

Simple Understanding of Lync / Skype for Business CMS

Tohamey - MSFT — Thu, 05 Jan 2017 14:41:29 GMT

Howdy, I decided to write a "Simple Lync CMS Explanation" article, the difference with this article is that I decided to use easy words not big words as much as I can, to make it easier for Engineers with little SQL experience to understand Lync / Skype for Business CMS and how does it work, replicateetc. So less words and more diagrams to make it understandable, instead of 5 pages of words

What is CMS?

Lync/ Skype for Business Central Management store (CMS), is a Microsoft SQL database (will be under the name xds in the SQL server) that is used by Lync/ Skype for Business to store the following data:

Topology (contain all data and information created by the topology builder)
Configuration (contain all Lync's different settings e.g. certificates, dial-in conferencing number)
Policies (contain the different Lync policy e.g. dial plans, client policies, meeting policies)

Those kind of data are stored as XML documents in the database, and CMS services replicate those data to the required servers. In previous versions as in OCS and OCS 2007 R2, those kind of data were stored in the Active Directory, Windows Management Instrumentation (WMI) and also SQL database, if you had worked with OCS you will remember that you needed to extend the Active Directory Schema to add a new features or functions and wait for replication across your AD infrastructure to complete, with Lync/ Skype for Business CMS it became way much easier as all data are stored in one location. NOTE: Lync still save some user object information in Active directory to maintain "Backward Compatibility" with OCS.

Data Scope

Data stored in CMS can be stored with four different scope levels:

Global
Site
Service
Tag

For each of those scope, there will be only one xml document, so if you have in your Lync/ Skype for Business deployment a site dial plan in addition to the Global dial plan, there will be two XML document in your CMS, one for the Global dial plan and one for the site dial plan. If you have good experience with SQL, you can check the "Document" table in the xds database and you will notice that each xml document end with a "scope" and only one file exist by scope

How to access CMS?

The answer for this question is "You cannot", access to the CMS is limited by only a .dll file (programming library) called "Microsoft.Rtc.Management.Core", the following Lync/ Skype for Business tools are using this file:

Lync/ Skype for Business Control Panel
Lync/ Skype for Business Topology Building
Lync/ Skype for Business Management Shell

So to modify data in CMS, you must use one of those Lync/ Skype for Business Management tools. NOTE: this .dll file has too many validation rules to check if what you trying to do is supported by Lync/ Skype for Business core design, then when it find that it is valid, it writes the new data to the CMS.

CMS Directory Structure

Before explaining how does the CMS replication works, I will explain the structure of the CMS directory, but first you need to know that CMS operate in a Single master / multiple replica (another word: Copies)system, we will talk more about that later in this article, but this mean that any Lync/ Skype for Business deployment has ONE and Only ONE master CMS stored in the Lync/ Skype for Business file store defined in the Lync/ Skype for Business Topology. Inside the file store you can find the "Central Mgmt" folder that is used by the Master CMS to replicate data. The xds-master folder is where all the magic happens, this folder is located in \\Lync fileshare\CentralMgmt folder\CMS FileStore\ xds-master contain two sub folders:

replicas
working

Inside the replicas folder, you can find a folder for each Lync/ Skype for Business server you have in your deployment, the folder name will be the FQDN of the Lync/ Skype for Business server, to make things easier, let us say you have a simple Lync/ Skype for Business deployment that consist of one Lync/ Skype for Business Frontend (lyncfe.lyncdude.local) and oneLync/ Skype for Business Edge server (lyncedg.lyncdude.local), inside the replicas folder you should find two subfolders of those two Lync servers Inside each of those subfolders, you will find another two subfolders (just try to keep up, I'm putting a big diagram in the end to show you overall view of the structure):

from-replica
to-replica

Here, we finished explaining the structure of the xds-master directory in the file share, and below is a diagram that helps you visualize the structure of the xds-master directory As I mentioned, for each server there is a replicas folder with its name in the \xds-master\replicas\ directory. Each Lync/ Skype for Business server has a local "xds-replica" folder located under \\Lync server FQDN\xds-replica that it uses to replicate to or from the "xds-master" If you log into one of the Lync/ Skype for Business servers, and navigated to C:\ drive, you find a folder called "RTCReplicaRoot" where under it you will find the xds-replica folder NOTE: IF YOU TRY TO ACCESS THIS FOLDER YOU WILL NEED TO CHANGE THE OWNER OF THE FOLDER WHICH YOU SHOULD NOT DO BECAUSE IT WILL BREAK YOUR LYCN SERVER, I DID THAT ON A LAB Under the xds-replica you find three subfolders:

from-master
to-master
Working

How does CMS Replica works

Like I mentioned before, the CMS operate in Single Master / Multiple replicas (copies) system, so one master located on the SQL backend server (called RTC), and each Lync/ Skype for Business server in the topology have a copy (replica) of this master (called RTCLOCAL). In case of an Enterprise edition pool deployment you will have a dedicated SQL server as a backend, so it will be like the following diagram, the master (RTC) stored on the SQL server and each Lync/ Skype for Business frontend will have a copy(RTCLOCAL) in case of a standard edition pool deployment the master xds and the replica (copy)will be both hosted in the same server using SQL Express server In case of the Edge server, which is not joined to the domain and located on a DMZ network, it gets the replication using HTTPS over port 4443 The location of the master CMS is stored in an Active directory object called"msRTCSIP-GlobalTopologySetting" which under its properties you find an attribute named"msRTCSIP-BackEndServer" This location is called "Service Connection Point" SCP which is created by the topology builder in the first time you published the topology and can be edited using the move-CsManagementServer cmdlet, or checked by using the Get-CsManagementConnection. The CMS master has three service installed on it:

Lync/ Skype for Business Master Replicator Agent
Lync/ Skype for Business File Transfer Agent
Lync/ Skype for Business Replica Replicator Agent

All those services are running on the CMS Master except for the "Replica Replicator agent which is not, the Replica Replicator agent services runs on other Lync/ Skype for Business servers in the topology.

Step by Step Replication (more words)

Each 60 seconds a task run to check if there is any changes made to the CMS master that need to be replicated.
If changes are found (xml files), they are all packed in a Data.zip file which have size less than 100KB to make the replication fast
The data.zip is copied to each "to-replica" folder of each server's replica folder in the xds-master directory
The FTA service running on the Master monitor all "to-replica" folders and once it sees a data.zip file in them it start the replication process
On the servers themselves, the Replica replicator is monitoring the "from-master" folder, once it sees a data.zip file in it, it unpack it and apply the changes to the server
After the changes are applied, a status.zip file is created and placed in the "to-master" folder in the server.
FTA is monitoring "to-master" folders on all Lync/ Skype for Business Servers and once it sees status.zip file it pull it to the "from-replica" folder on the CMS-Master
The Master replicator then unpack the package and update the status CMS-Master

For Edge: Lync/ Skype for Business edge server uses the replication web services over HTTPS / 4443 port to copy the Data.zip file, the replication web services uses the internal Certificate issued by the internal CA and trusted by the Lync/ Skype for Business in the replication process. NOTE: it takes 60 seconds to pull changes from Master + some seconds to apply the changes + 60 seconds to pull from replica + some replication delays maybe, that's why it takes up to 3 minutes for changes to reflect and be visible by the Lync users that's it, hope I did a good job :) let me know in comments

Simple Understanding of Media Traversal in Lync / Skype for Business

Tohamey - MSFT — Tue, 03 Jan 2017 14:36:28 GMT

Howdy everyone, Hope you all had a nice holiday and wish you a happy and successful new year :) . This is one of my “Simple Understanding” articles to provide an easy way to understand how ICE “Interactive Connectivity Establishment” protocol is used in Lync and Skype for Business to find available media path for an audio, video, desktop sharing sessions to overcome the Firewall / NAT obstacle in an infrastructure. This article was really hard to write as I found myself too many times getting into too much details which lead into deleting or cutting paragraphs in it, and finally after 2 weeks I got this, so let’s start.

Understanding ICE

ICE is a protocol that is used to find & establish media path in a call, simply like with SIP, we have a SIP server “your Lync / Skype for Business Frontend” and a SIP client “Lync / Skype for Business client”, also with ICE we have an ICE server “Lync / Skype for Business Edge” and an ICE Client “Lync / Skype for Business client” ICE uses two other Protocols to find and establish a suitable media path for a call, those Protocols are:

STUN (Session Traversal Utilities for NAT)
TURN (Traversal Using Relays around NAT)

because this is a simple understanding article and not a deep dive, I won’t go into details about the mechanism of STUN and TURN, a simple search online will gives tons of articles about that. but we need to understand the difference between those two is simply:

STUN: the media travels directly between both endpoints in a call (the NAT device is considered an endpoint)
TURN: the media will be proxied using the TURN server between both endpoints in a call

understanding this will help when we talk about the scenarios later in this article in a Lync / Skype for Business deployment, STUN server or TURN server is always the Lync / Skype for Business Edge server (A/V Server)

Candidates List

what is a Candidates list? It is simply a list of IP-addresse(S), ports and protocols (wither UDP or TCP) that is shared between the call endpoints to tell each other what is the possible media path that can be used in this call, the candidates list is sent in the INVITE message inside the SDP part of the message. in a SIP Stack file it look like this

a little deeper look, the Candidates list is composed of:

Host Candidates: the local IP address and ports of all active network cards on the client machine (most preferred by Lync / Skype for Business).

Reflexive Candidates (STUN): list of IP-address & ports allocated by a NAT device (second preferred candidate in Lync)

Relay Candidates (TURN): list of IP-addresses & ports of the TURN servers (used when STUN cannot be used)

the Lync / Skype for Business client test each of those candidates till it find a suitable media path for the session (will talk more about that later in the article)

Media establishment mechanism

so how does it actually work?, I divided the mechanism of finding a suitable media path into 3 main stages

Register and locate the media relay server.
Create the Candidate list.
Connect & Establish a media session.

I created a simple traffic animated video describing each one of the steps, after all they say a picture worth thousand words, what about a video then?

1. Register & Locate the media relay server

The animated video can be found here Deeper Look

External client does a SRV lookup to find the Edge server to register
External client send a REGISTER request to the frontend via the Edge access services
Frontend register the client and send back a SIP 200/OK telling the client there is an Edge server for Media relay
client sends a SERVICE request with its location (External or Internal) to the Frontend.
Frontend authenticate with the Edge server on behalf of the client (MRAS Request)
Edge Server creates credentials (valid for 8 hours) for the client using the private key in the “Public SSL Certificate” installed on the A/V services and send them to Frontend (MRAS Response)
Frontend sends a SIP 200/OK to the initial SERVICE request from the client with the name of the Edge server & credentials the client should use for Media relay

HINT: if you wondering about step 6 and 7, those take place because Edge server is not joined to the domain and cannot authenticate users, it create the credentials using the Private Key associated with the public SSL certificate installed on the A/V services and that’s why it is required to use the same SSL certificate with private key on all the Lync / Skype for Business Edge servers in the same Edge pool in case one node goes down.

2. Create the Candidates list

the video can be found here Deeper Look in this stage the client go through some steps to create the candidate list explained previously in this article, so let’s say client_1 (located in home office) is inviting client_2 (located in the HQ) for an audio call.

Client discover Local Host candidate which is the local IP-address of every active network card on the machine, which is using only UDP as it is peer-to-peer connection.
Client connect to media relay server (the Edge server) and discover STUN Candidates whish are:
- UDP candidates equal to the IP-address that the Edge server sees the client coming from.
- TCP candidate equal to the IP-address that the Edge server sees the client coming from.
Client connect to media relay server (the Edge server) and discover TURN Candidates which are:
- UDP candidate equal to the IP-address of TURN server (the Edge server)
- TCP candidate equal to the IP-address of TURN server (the Edge server)
Client_1 send INVITE request with its Candidates list to Client_2
Client_2 does the same and discover its own Candidate list
Client_2 reply to the INVITE with 183 Session Progress with its own Candidates list

3. Connect & Establish a media session

the video can be found here Deeper Look in our scenario:

Client_1 will try to connect using the local candidate first, which will fail because both are in different networks
Then it will try the STUN candidates as it is the preferred by Lync
If for some reason STUN fail, client will failback to TURN/UDP
If TURN/UDP did not work, client will try TURN/TCP

so in SIP stack traffic it happens on 5 steps (not always, just to make it simple) as described in this video

Client_1 send SIP INVITE with its Candidates lists to Client_2

Client_2 reply with SIP 183 Session Progress with its own Candidate list to Client_1

Client_2 send SIP 200 OK with best Candidates to Client_1

Client_1 choose STUN candidate as the best suitable path for Media and send a re-INVITE to Client_2 telling it that

Client_2 choose TURN candidate as the best suitable path for Media and send a SIP 200 OK to Client_1 telling it that

call established and now both clients knows how they can send media to each other

Summary

so that's how it works:

The Client will use the Lync / Skype for Business Edge server to create its Candidates list
Client will INVITE another to a call while providing its Candidate list
Both clients test the candidates list and choose the best suitable media path
inform each other with the chosen candidate
establish the call

till next time :)