Teams und Federation

Bei der Betrachtung von Teams Umstellung und Teams Koexistenz-Konfiguration muss man natürlich auch die Federation zwischen Firmen betrachten.

Diese Seite ist eine Momentaufnahme von Sep 2018 anhand eigener Tests und Traces. Teams wird aber aktiv weiter entwickelt. Insofern kann die Halbwertzeit dieser Information sehr kurz sein. Korrekturen und Hinweise auf Veränderungen nehme ich gerne an.

Update: Eine direkte Teams zu Teams Federation ist nun möglich, wenn beide Teilnehmer "TeamsOnly" sind.

Microsoft Teams/Skype Federation
https://www.youtube.com/watch?v=WSomk_xtLXU

Grundlagen

Teams kann nicht abstreiten, dass es noch viele Komponenten von Skype for Business nutzt. Dazu gehört auch die Federation. Solange es sowohl innerhalb eines Tenants als auch auch über Tenants und Organisationen hinweg neben Teams noch Skype for Business gibt, sollte auch die Skype for Business Federation funktionieren. Selbst innerhalb eines Tenant werden alle Mitarbeiter weiter mit Skype for Business arbeiten, Bis sie per Policy auf "TeamsOnly" umgestellt worden sind. Denn die Stufen sind bei Microsoft klar geregelt:

Wenn wir mal den Island/Legacy-Mode weglassen, dann starten Benutzer mit "SkypeOnly" und landen dann eventuell über die Zwischenschritte "SkypeWithTeamsForCollab" und SkypewithTeamsforCollabAndMeeting" bei "TeamsOnly". Erst wenn der Benutzer auf "TeamsOnly" ist, wird für den Anwender der Skype for Business Client in Rente geschickt.

Wichtig:
Benutzer, die in Teams mit Instant Messaging (Chat) und Präsenz arbeiten wollen und mit Skype for Business Partnern federieren, müssen ggfls. vorher nach Skype for Business Online migriert werden. Die PowerShell warnt aber auch davor

Grant-CsTeamsUpgradePolicy -Identity user3@msxfaq.de -PolicyName tag:UpgradeToTeams

User "user3@msxfaq.de" is homed On-Premises in a Skype for Business or Lync deployment. On-Premises users can be
upgraded to Teams using Move-CsUser in the On-Premises tools. For details, see http://aka.ms/UpgradeToTeams
    + CategoryInfo          : NotSpecified: (CN=79cb73ea-6cc...c1e001,DC=local:OCSADUserOrAppContact) [Grant-CsTeamsUp
   gradePolicy], OnpremUserInvalidOperationException
    + FullyQualifiedErrorId : GrantPolicy,Microsoft.Rtc.Management.AD.Cmdlets.AssignCSTeamsUpgradePolicyCmdlet
    + PSComputerName        : admin1e.online.lync.com

Bis wir dann also irgendwann einmal eine "Teams zu Teams-Federation" haben werden, wird es wohl noch etwas dauern. Das ist dann aber deutlich einfacher für Microsoft zu betreiben, da Teams ja sowieso nur in Office 365 verfügbar ist. Probleme mit Edge-Servern, Zertifikaten oder DNS-SRV-Einträgen sind dann für den Kunden nicht mehr so wichtig. Bis dahin aber bleibt SIP und _sipfederationtls.<domain> vorhanden.

Steuerung der Federation

Federation beschreibt eigentlich die Kommunikation zwischen Firmen, auch wenn ich hier auch die Verbindung zwischen Teams und Skype for Business im gleichen Tenant eingehe. Für die externe Kommunikation müssen Sie aber sicherstellen, dass die Konfiguration in Teams und Skype for Business Online identisch eingestellt sind. Das nicht nicht ganz so einfach, da Sie in Skype for Business etwas anders konfiguriert wird als diese in Teams erfolgt.

  • Teams Federation Konfiguration
    Bei Teams ist per Default die Federation "offen", da die Liste der Domänen leer ist..

    Aktuell bin ich noch nicht sicher, was dann die Blocked Domains anstellen.

Sobald sie aber eine "Allowed Domain" in die Liste aufnehmen, ist die offene Federation nicht mehr aktiv

  • Skype for Business Online
    Hier müssen Sie einstellen, ob die Liste der Domänen als "Block" oder "Allow" wirken oder externer Zugriff generell verboten ist

Wichtig ist, dass die Einstellungen bezüglich Federation in Teams und Skype for Business Online und beim Hybrid-Mode auch in Skype for Business On-Premises identisch sind. Es gibt keinen automatischen Weg um diese Einstellungen abzugleichen. AADConnect übernimmt dies nicht für Sie.

Der Weg wird kein Kurzer sein

Aktuell ist es aber so, dass jegliche Federation noch über die Skype Umgebung geht. Das können Sie mit dem UCCAPILOG des Skype Clients oder Fiddler auch sehr gut selbst nachvollziehen. Zwischen Skype for Business Online und Teams gibt es ein Gateway, welche z.B. im UCCAPI-Log auch als Eintrag zu sehen ist:

09/27/2018|14:56:51.311 3290:3294 INFO  :: SIP/2.0 180 Ringing
Via: SIP/2.0/TLS 192.168.101.62:56536;ms-received-port=56536;ms-received-cid=6ED0C00
FROM: "Carius, Frank"<sip:frank@netatwork.de>;tag=xx;epid=xx
TO: <sip:fcdemo1@uclabor.de>;tag=97c14b45a8;epid=xx
CSEQ: 1 INVITE
CALL-ID: xxx
RECORD-ROUTE: <sip:sipedgeblu2a.infra.lync.com:5061;transport=tls;opaque=state:Ifi;lr>,
   <sip:sippoolblu2a18.infra.lync.com:5061;transport=tls;ms-fe=BLU2A18FES08.infra.lync.com;lr>,
   <sip:sipedgedm12a.infra.lync.com:5061;transport=tls;opaque=state:Ifi;lr>,
   <sip:sipfed.online.lync.com:5061;transport=tls;epid=CA1447ED92;lr;ms-key-info=xx-xxx-xxx>,
   <sip:nawsfbedge.netatwork.de:5061;transport=tls;lr>,
   <sip:NAWLYNC002.netatwork.de:5061;transport=tls;opaque=state:F:Ci.R6ed0c00;lr;ms-route-sig=xxx>
CONTACT: <sip:sip2.lgw.skype.com:50105;ms-fe=c-lgw-usea2-02.lgw.skype.com;transport=Tls>;isGateway;text;audio;video;image;application
CONTENT-LENGTH: 0
ALLOW: CANCEL
ALLOW: BYE
ALLOW: UPDATE
ALLOW: PRACK
P-ASSERTED-IDENTITY: ""<sip:fcarius.admin@fcarius.onmicrosoft.com>
SERVER: RTCC/7.0.0.0 LyncTeamsGateway/1.1.131.0
ms-lync-skype-gw-teams: true
ms-telemetry-id: 76EFA3D8-638C-51A6-92E1-3F44B1D83045
ms-edge-proxy-message-trust: ms-source-type=AuthorizedServer;ms-ep-fqdn=edge.netatwork.de;ms-source-network=federation;ms-source-verified-User=verifi

Das SIP-Paket verrät über die "Record-Route" gut, welchen Weg das Paket von einem On-Premises-User über Frontend Server und Edge zur Office 365 Cloud und dann weiter zum "LyncTeamsGateway" gelaufen ist. Allerdings ist dann nicht mehr zusehen, welche Stationen innerhalb von Teams noch involviert sind. Das "LyncTeamsGateway" hat die Rolle eines B2BUA (Back to Back User Agent) inne, der die beiden Welten wie ein SBC miteinander koppelt.  

Teams selbst ist ja generell in der Cloud. Also können wir und auf vier Fälle beschränken, von denen ein Fall noch gestrichen wird.

Skype for Business Teams Nutzung Beschreibung

Skype for Business On-Premises und Teams in der Cloud im SfB*-Mode

Damit fangen viele Firmen an, die Skype for Business lokal nutzen und mit Teams starten. Die Anwender bleiben für IM/Presence in Skype for Business

Skype for Business On-Premises und Teams in der Cloud im SfB*-Mode

Damit fangen viele Firmen an, die direkt mit Skype for Business in Office 365 gestartet haben oder einige Benutzer über den Skype for Business Hybrid Mode in die Cloud verschoben wurden. Die Anwender bleiben für IM/Presence in Skype for Business und nutzen von Teams die Collab-Funktion und ggfls. Meetings

Diese Funktion ist nicht sinnvoll möglich. Ein Benutzer der Skype for Business "On-Premises" nutzt, kann nicht gleichzeitig als "Teams Only"-Benutzer arbeiten. Dies kann zwar konfiguriert werden, aber funktioniert nicht, da das Bindeglied zwischen Teams in der Cloud und Skype for Business On-Premises nicht vorhanden ist.

Ein "Teams Only" User muss in der Office 365 Cloud sein.

Hinsichtlich Teams habe ich bislang keine Veränderungen im Code von Skype for Business On-Premises erkennen können. Damit aber so eine Konstruktion läuft, muss Skype for Business Online sicherlich einige Erweiterungen über sich ergehen lassen. Ein "TeamsOnly"-User hat ja quasi keinen Skype for Business-Account mehr. Aber irgend einen Platzhalter mit einem Verweis auf Teams, vergleichbar Mailusern mit TargetAddresse in Exchange wird es wohl schon noch geben, damit die Pakete geroutet werden können. Ein deutlicher Hinweis darauf ist ja auch die Aussage, dass ein TeamsOnly User auf jeden Fall auch Skype for Business Online nutzen muss und nicht mehr On-Premises liegen darf.

Skype oder Teams, wer weiß das schon?

Das bedeutet aber auch, dass das Gateway bei einem Paket irgendwo nachfragen muss, ob der Benutzer eine Instant Messages nun per Teams oder Skype for Business liest. Das stimmt so auch nicht ganz, wenn ein Skype for Business Server kennt ja "seine" Benutzer und wird die Daten dazu nicht erst an einen Edge-Server oder ein Gateway senden. Beim Skype for Business Hybrid Mode kenne Sie sicher das Feld "HostingProvider", in dem die Skype for Business Server reinschauen, ob dort ein "SRV:" für lokale User oder ein "sipfed.online.lync.com" für Office 365 drin steht. Dieses Feld wird in einer Hybrid-Umgebung auch zu Skype for Business Online repliziert. Ich habe aber noch keinen weiteren Indikator gefunden, der mir sagt, ob ein Benutzer nun in Teams ist. Wenn, dann gibt es das Feld ja eh nur in der Cloud. Also verrät vielleicht ein Get-CSOnlineUser etwas:

Get-CSOnlineUser fctest5@uclabor.de `
| fl sipaddress,hostingprovider,RegistrarPool,TeamsUpgradeEffectiveMode,UserRoutingGroupId,OriginalPreferredDataLocation,serviceinstance,InterpretedUserType

Ich habe also einen Benutzer einmal zum "SfBOnly"-Benutzer gemacht und nach 24h die Werte ausgelesen. Danach habe ich das ganze noch mal mit "Grant-CsTeamsUpgradePolicy fctest5@uclabor.de -PolicyName UpgradeToTeams" gemacht und nach 24h wieder ausgelesen. Folgende Felder haben sich dabei geändert:

Felder SfB Online UpgradeToTeams

SipAddress

sip:fctest5@UCLABOR.DE

sip:fctest5@UCLABOR.DE

HostingProvider

sipfed.online.lync.com

sipfed.online.lync.com

RegistrarPool

sippoolblu2a17.infra.lync.com

sippoolblu2a17.infra.lync.com

TeamsUpgradeEffectiveMode

SfBOnly

TeamsOnly

UserRoutingGroupId

78bf3e8a-6782-5884-a661-da2a34d28999

78bf3e8a-6782-5884-a661-da2a34d28999

OriginalPreferredDataLocation

$null

$null

ServiceInstance

microsoftcommunicationsonline/noam-2a-s6

microsoftcommunicationsonline/noam-2a-s6

InterpretedUserType

HybridOnlineSfBUser

DirSyncTeamsUser

Von allen Feldern, die mir interessant erschienen, hat sich also nur der "TeamsUpgradeEffectiveMode" und das Feld "InterpretedUserType" geändert. Alle anderen Felder, die sich vielleicht mit einem Umzug von SkypeOnly zu TeamsOnly ändern könnten, wurden nicht geändert.

Wer mit Wem und Wie

Alle Kombinationen habe ich aus Vereinfachungsgründen hier nicht aufgeführt aber drei Beispiele nutze ich als Startpunkt für eine Tabelle. Dass es ein "Skype2Teams-Gateway gibt, haben wir im SIP-Trace schon gesehen. Und die Federation läuft weiterhin über die Skype for Business-Systeme. Ich denke das wird noch lange so bleiben, da es ja kein Federation-Modell für Teams gibt. Hier ist ja eh alles in Office 365. Ich vermute aber mal, dass irgendwann Microsoft die Verbindung zwischen Teams-Teilnehmern direkt zwischen Teams routen wird. Nur wenn zwei TeamsOnly-Benutzer im gleichen Tenant sind, dürfte das Paket direkt im Tenant bleiben.

Auf dem folgenden Bild sehen sie links einen Benutzer 1, der Skype for Business lokal nutzt und Teams zusätzlich nutzen kann. Der Benutzer 2 ist schon mit Skype for Business in der Cloud aber auch noch kein TeamsOnly Benutzer. Erst der Benutzer 3 ist ein "TeamsOnly"-Benutzer, für den es so etwas wie ein Platzhalter in Skype for Business Online gibt. Er kann sich aber nicht an SfBO anmelden.

Entsprechend können Sie sich nun den Weg zwischen den Benutzern selbst herleiten.

Hinweis:
Wenn die Zielumgebung oder Quell-Umgebung eine Skype for Business Hybrid-Konfiguration nutzt, dann erinnern sie sich bitte an das Routing über Edge Server mit Hybrid. Alle eingehenden Pakete gehen einmal durch die On-Premises Umgebung (Edge-FE-Edge) zum Tenant und umgekehrt gehen auch ausgehende Pakete vom Tenant in die Welt über die On-Premises Topologie.

Die ganz einfachen Fälle, die schon Skype for Business bekannt sind, habe ich weg gelassen. Federation ist aber immer eine Funktion zwischen den einzelnen Personen. Natürlich mit jemand, der Skype for Business On-Premises mit Teams einsetzt, den Hybrid-Mode konfiguriert haben.

Sender Topologie Empfänger Ergebnis

Teams

gleicher Tenant

TeamsOnly

Bleibt in Teams

Teams

gleicher Tenant

SfBOnline

Über Teams/Skype Gateway in der Cloud zu SfB Online

Teams

Hybrid

SfB On-Premises

Über Teams/Skype Gateway in der Cloud zu SfB Online zum lokalen Edge

Teams

anderer Tenant

Teams

über SfB Online Federation, also zwei mal Gateway

Teams

anderer Tenant

SfB Online

Über Teams/Skype Gateway in der Cloud zu SfB Online

Teams

anderer Tenant

SfB On-Premises

Über Teams/Skype Gateway in der Cloud zu SfB Online zum lokalen Edge

SfBOnline

anderer Tenant

TeamsOnly

Über Skype Federation zum OnPre Edge und wie Office 365 Edge zum Gateway zum Ziel

SfBOnline

anderer Tenant

SfB Online

Über Skype Federation zum On-Premises Edge und wie Office 365 Edge zum Gateway zum Ziel

SfBOnline

anderer Tenant

SfB On-Premises

Wie gewohnt über Skype Federation zum Edge

SfB On-Prem

anderer Tenant

TeamsOnly

Auch der TeamsOnly-User hat einen "SchattenUser" in SfB Online über den die Anfragen zum Gateway geleitet werden

Es gibt Konstellationen, die nur in eine Richtung aufgebaut werden können. Eine Antwort ist möglich, solange die Session besteht und der "Record-Route" den Rückweg vorgibt. Diese Probleme gibt es aber nur im Island und Legacy-Mode, von dem Sie ja möglich schnell weg sollten.

Hinweis: Die Teams Media Relais nutzen neben Port 3478/UDP auch 3479-3481/UDP. Ihr On-Premises Skype for Business Edge muss diese ausgehenden Ports erreichen können.

Hier

Federation mit Hybrid

Wenn Sie überprüfen wollten, welchen Weg das Paket von einem Absender zu einem anderen Tenant geht, dann habe ich hier noch mal ein Übersichtsdiagramm

Update: Eine direkte Teams zu Teams Federation ist nun möglich, wenn die Teilnehmer "TeamsOnly" sind.

Wir starten links oben bei der (1):

Station Was passiert hier

1

Wir starten bei einem Benutzer in Tenant 1, der aktuelle mit "TeamsOnly" arbeitet und eine beliebige "SIP-Adresse eingibt.

2

Der eigene Teams-Service prüft, ob sich das Ziel im gleichen Tenant mit TeamsOnly oder Island befindet. Wenn dies der Fall ist, dann ist die Reise schon zu Ende, denn das Teams Backend sendet die Message direkt zum Teams User.

Ansonsten prüft Teams, ob das Ziel in einem anderen Tenant vorhanden und im "Teams Only"-Mode ist. Wenn ja, dann nimmt Teams die Abkürzung. Ina allen anderen Fällen geht das Paket dann weiter.

3

Wenn Teams den User nicht findet, dann geht es aktuell zum "Teams/Skype Gateway", welche die Brücke zwischen den beiden Welten im Tenant darstellt. Dabei wird auch die Teams-Adresse des Absenders auf eine SIP-Adresse umgesetzt. Jeder Teams User hat ja einen "Schatten" in Skype for Business. Das Paket geht dann einfach zum Skype Server

Ich bin sicher, dass irgendwann eine direkte Federation zwischen Teams möglich sein wird. Im April 2019 war das aber noch nicht so.

4

Skype for Business Online muss nun anhand der SIP-Domain entscheiden, was damit zu tun ist. Wenn es sich um einen SfBOnline-Benutzer im gleichen Tenant handelt, dann wird die Nachricht zugestellt. Ansonsten hängt es nun davon ab, wie es weiter geht. Wenn der Tenant einen Hybrid Mode hat, dann muss die Message zum On-Premises System geleitet werden. Der Edge in der Cloud kann nicht selbst per "_sipfederationtls" eine Gegenstelle suchen, da der _sipfederationtls-Eintrag des eigenen Umgebung im Hybrid-Mode immer auf den On-Premises-Edge verweist und die Cloud damit nicht autoritativ ist.

5

Das Paket landet also beim Edge-Server der lokalen Umgebung und da ein Edge-Server nur eine SIP-Proxy ist aber nicht routet, leitet er das Paket zum konfigurierten Frontend-Server weiter

6

Der Frontend Server der Firma1 entscheidet nun wieder, ob der Empfänger ein Nutzer der On-Premises Skype Umgebung ist oder ein Federation-Benutzer. Wie gehen davon aus, dass der Empfänger nicht lokal ist und der Frontend Server anhand der Federation Route das Paket weiterleitet.

7

Es geht also wieder über den Edge-Server zum Edge-Server der federierten Firma. Da auch das Ziel einen Hybrid-Mode fährt, landet das Paket dort beim Edge. Wenn das Ziel ein "Skype for Business Only"-System hat, dann geht es natürlich direkt zur Cloud.

8

Nun ist es am Frontend der Zieldomäne der Benutzer lokal zu finden und die Message direkt zuzustellen. Wenn der Empfänger in Skype for Business Online ist, dann leitet der Frontend Server das Paket über den eigenen Edge-Server zum Edge-Server in Office 365 und damit weiter zum Tenant.

9

Der SfB-Online Server sucht den Benutzer in SfB Online um die Nachricht an die angemeldeten Clients zu senden. Dabei beachtet er aber den "EffectiveTeamsUpgradeMode". Nur wenn das Ziel auf "TeamsOnly" konfiguriert ist, sendet der SfB Online Server zum Teams-Gateway.

10

Das Teams-Gateway des Ziel-Tenants leitet die Message an die Teams Services weiter.

11

Der Teams Service sucht den Anwender und angemeldet Clients um das Paket zuzustellen.

12

Der Client zeigt die Meldung an.

Der Rückweg ist nun nicht gesondert aufgezeichnet aber läuft im Grund den gleichen Pfad. In der SIP-Welt laufen die Pakete die gleichen Stationen wieder zurück, die im Header als Stationen verzeichnet sind. Zur Vereinfachung habe ich die Verbindung von Clients von den verschiedenen Standorten nicht weiter ausgeführt und beide Firmen mit einem Hybrid-Mode ausgeführt.

Federation und "Teams Trial Lizenz"

Bei meinem Tests zu Federation zwischen Tenants habe ich auch einen Benutzer ohne E3/E5 nur mit einem "Teams Trial"-Lizenz versehen.

Eigentlich sollte eine "Trial" nicht wirklich beschränkt sein oder es eine Auflistung dazu geben. In meinem Beispiel habe ich aber nur gesehen, dass der Anwender nicht per Federation aus Skype for Business erreichbar war. Aus meiner "On-Premises"-Erfahrung habe ich mich bei den Richtlinien auf die Suche gemacht und wurde auch relativ schnell fündig:

PS C:\> Get-CsOnlineUser fc* | ft sipaddress,ExternalAccessPolicy

SipAddress                                ExternalAccessPolicy
----------                                --------------------
sip:fctest1x@uclabor.de                    FederationAndPICDefault
sip:fctest5x@UCLABOR.DE
sip:fctest2x@uclabor.de                    FederationAndPICDefault
sip:fctest4x@uclabor.de                    FederationAndPICDefault
sip:fctest3x@uclabor.de                    FederationAndPICDefault

Der Anwender hatte gar keine "ExternalAccessPolicy". Damit wirkte die "Global" Policy, in der Federation und einiges andere deaktiviert ist. Mein Versuch dem Benutzer aber die passenden Policy zuzuweisen, wurde mit einem Fehler abgelehnt:

Grant-CsExternalAccessPolicy fctest5@uclabor.de -PolicyName Tag:FederationAndPICDefault
Das Cmdlet kann nicht ausgeführt werden: "Grant-CsExternalAccessPolicy". Ursache: Es ist auf die Kombination aus diesem Benutzerdienstplan: MCO_TEAMS_IW und diesem Land/dieser
Region: DE eingeschränkt.

Ich denke, dass "MS_TEAMS_IW" der Code für die TrialVersion und hier Federation nicht vorgesehen ist. Ich habe nicht alle Länder durchprobiert aber es betrifft nicht nur "DE"

Federation und Teams "Free"

Ein ganz anderes Verhalten habe ich dann im "Teams Free"-Tenant (Siehe Microsoft Teams ist kostenlos) gesehen. Hier konnte ich dem Benutzer gar keine Federation-Policy zuweisen, weil er bei "Get-CSOnlineUser" gar nicht sichtbar war. Bei einem "Teams Free"-Tenant ist also gar keine Federation vorgesehen und anscheinend auch kein Gateway möglich, welches die Daten aus dem AzureAD/SfBOnline-AD (Siehe auch Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr) auswertet.

Um das Bild komplett zu machen, liefert mir ein Get-CsExternalAccessPolicy gar nicht erst all die vier verschiedenen Policies, die ein normaler Tenant hat

C:\> Get-CsExternalAccessPolicy

Identity                          : Global
Description                       :
EnableFederationAccess            : False
EnableXmppAccess                  : False
EnablePublicCloudAccess           : False
EnablePublicCloudAudioVideoAccess : False
EnableOutsideAccess               : False

Schlimm finde ich das nicht, da ein Teams Free" natürlich für die Funktion "Zusammenarbeit" genutzt werden sollte und nicht als Plattform für "Spam over Instant Messaging" (SPIM) missbraucht werden darf. Vielleicht lockert sich diese Einschränkung in Zukunft einmal, wenn die Federation zwischen Teams direkt zwischen Tenants möglich ist.

Weitere Links