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.
Hinweis: Seit 29. Jun 2024 werden "Trial Tenants" per Default geblockt. Als Administrator können Sie dies ändern
MC805200 Teams to Block Federated Communications with Trial Tenants
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.
- Coexistence with Skype for Business
https://docs.microsoft.com/en-us/MicrosoftTeams/coexistence-chat-calls-presence#federated-routing-for-new-chats-or-calls
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.
- Let your Teams users chat and
communicate with users in another Teams
organization
https://docs.microsoft.com/en-US/MicrosoftTeams/let-your-teams-users-communicate-with-other-people
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
- Vorbereiten des Netzwerks Ihres
Unternehmens für Microsoft Teams
https://docs.microsoft.com/de-de/microsoftteams/prepare-network
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
- Azure AD - Ein Verzeichnisdienst, oder zwei oder mehr
- Microsoft Teams ist kostenlos
- Lync Federation mit anderen IM-Systemen
- PIC mit AOL/AIM
-
Coexistence with Skype for Business
https://docs.microsoft.com/en-us/MicrosoftTeams/coexistence-chat-calls-presence#federated-routing-for-new-chats-or-calls -
Get Microsoft Teams for free
https://products.office.com/en-us/microsoft-teams/free -
Mit Microsoft Teams zum kostenfreien Office
365
https://www.lansco.de/blog-artikel/mit-microsoft-teams-zum-kostenfreien-office-365.html -
Teams to Block Federated Communications with
Trial Tenants
https://office365itpros.com/2024/06/27/federated-communications-block/ -
OPEN FEDERATION in Microsoft TEAMS
http://www.uclabs.blog/2020/02/teams-open-federation.html