Coexistence avec Skype Entreprise

La coexistence et l’interopérabilité entre les clients Skype Entreprise et Teams sont contrôlées par les modes de coexistence. Pour plus d’informations, consultez Guide de migration et d’interopérabilité pour les organisations qui utilisent Teams avec Skype Entreprise. Après la mise hors service de Skype Entreprise Online le 31 juillet 2021, les utilisateurs hébergés dans le cloud sont toujours des utilisateurs TeamsOnly. Il n’est plus possible d’attribuer un mode de coexistence autre que TeamsOnly à un utilisateur en ligne. Les modes de coexistence autres que TeamsOnly sont uniquement pertinents pour les organisations avec des déploiements locaux de Skype Entreprise Server ou Lync Server 2013. Dans cet article, toute référence à « Skype Entreprise Server » s’applique également à Lync Server 2013.

Détermination du mode de coexistence d’un utilisateur

Tous les utilisateurs des organisations sans déploiement local de Skype Entreprise Server sont en mode TeamsOnly, et le mode effectif du locataire est également TeamsOnly. Cela peut être confirmé en examinant la propriété TeamsUpgradeEffectiveMode sur le locataire ou l’utilisateur à l’aide de Teams PowerShell. Avant la mise hors service de Skype Entreprise Online le 31 juillet 2021, les organisations avaient la possibilité de modifier le mode de coexistence pour l’utilisateur ou le locataire. Cela n’est plus possible, sauf pour les organisations avec un déploiement local de Skype Entreprise Server, qui ne doivent pas avoir le mode TeamsOnly à l’échelle du locataire. Vous pouvez confirmer que le mode de coexistence ne peut plus être modifié si TeamsUpgradePolicyIsReadOnly = « ModeAndNotifications » sur l’utilisateur ou le locataire. (TeamsUpgradePolicyIsReadOnly sur n’importe quel utilisateur aura la même valeur que la valeur du locataire.)

//Check if Tenant is TeamsOnly and if mode is read only.
$t=Get-CsTenant
$t|fl TeamsUpgradeEffectiveMode, TeamsUpgradePolicyIsReadOnly

TeamsUpgradeEffectiveMode  : TeamsOnly
TeamsUpgradePolicyIsReadOnly: ModeAndNotifications

//Check if user is TeamsOnly and if mode is read only.
$u=Get-CsOnlineUser
$u|fl TeamsUpgradeEffectiveMode, TeamsUpgradePolicyIsReadOnly

TeamsUpgradeEffectiveMode  : TeamsOnly
TeamsUpgradePolicyIsReadOnly: ModeAndNotifications

Dans un organization avec un déploiement local de Skype Entreprise Server, la stratégie globale de locataire pour TeamsUpgradePolicy peut avoir n’importe quel mode autre que TeamsOnly. Les modes autorisés sont : SfBOnly, SfBWithTeamsCollab et SfBWithTeamsCollabAndMeetings. Les utilisateurs peuvent également se voir attribuer directement un instance de TeamsUpgradePolicy, qui remplacerait la stratégie globale du locataire. Les utilisateurs hébergés dans le cloud doivent être TeamsOnly, et les utilisateurs hébergés localement doivent être n’importe quel mode autre que TeamsOnly. Si un utilisateur ne reçoit pas de instance de TeamsUpgradePolicy, l’utilisateur reçoit la valeur de la stratégie globale du locataire.

Paramètres de routage

Le mode de coexistence du destinataire détermine le comportement des conversations, des appels et de la présence, à la fois au sein d’un locataire et entre les locataires fédérés. Si l’expéditeur utilise Teams, la décision de routage est prise lors de la création d’un thread de conversation. Une fois qu’un thread de conversation est créé, son routage ne change pas et il conserve la méthode de routage déterminée lors de la création du thread.

Les méthodes de routage des threads sont les suivantes :

• native pour une conversation Teams vers Teams dans le locataire
• interopérabilité pour qu’un Teams Skype Entreprise conversation dans le locataire
• fédéré natif pour une conversation fédérée entre les locataires lorsque les deux utilisateurs ont le mode TeamsOnly.
• interopérabilité fédérée pour une conversation fédérée entre les locataires qui s’appuie sur l’interopérabilité entre Skype Entreprise et Teams.

Lors de la création d’une conversation, les facteurs qui déterminent la façon dont le thread est routé sont les suivants :

• Mode de coexistence du destinataire
• Client utilisé par l’expéditeur
• Si la conversation est dans le locataire ou fédérée
• Si la conversation est possible. Si un utilisateur dispose d’un compte Skype Entreprise hébergé localement, cet utilisateur ne peut pas utiliser le client Teams pour l’interopérabilité dans le locataire ou pour la fédération. Cet utilisateur peut uniquement utiliser le client Skype Entreprise pour l’interopérabilité et la fédération. Notez que la communication entre Teams et Teams est toujours possible dans le locataire.

Routage des conversations et des appels

Les tableaux ci-dessous indiquent quel client dans un mode donné reçoit un appel de l’émetteur (trois colonnes les plus à gauche). Le client qui reçoit l’appel dépend du mode d’origine, du client choisi et de l’emplacement où le compte Skype Entreprise est hébergé (local ou en ligne).

Dans les tables qui suivent :

• Skype Entreprise* représente l’un des modes suivants : SfBOnly, SfBWithTeamsCollab, SfBWithTeamsCollabAndMeetings.
• Le texte en italique met en évidence une conversation d’interopérabilité.
• Non possible représente une situation dans laquelle la conversation ou l’appel n’est pas possible. L’expéditeur doit utiliser Skype Entreprise à la place dans ces cas. C’est l’une des raisons pour lesquelles les recommandations normatives de Microsoft pour les clients locaux et hybrides sont d’utiliser un mode autre que Islands (généralement SfBWithTeamsCollab) comme point de départ de leur parcours de mise à niveau vers Teams.
• Les utilisateurs des îles qui utilisent Teams peuvent lancer des conversations de groupe fédérées.

Routage dans le locataire pour les nouveaux conversations ou appels

Les tableaux ci-dessous capturent le routage des conversations et des appels dans le locataire, et sont valides pour les nouveaux appels ou conversations qui ne sont pas démarrés à partir d’un thread préexistant. Il décrit le client qui recevra un nouvel appel ou une nouvelle conversation, s’il provient d’un utilisateur à gauche, à un utilisateur destinataire dans le locataire à droite. Les messages envoyés aux utilisateurs TeamsOnly sont toujours acheminés vers Teams. Les messages envoyés à Skype Entreprise utilisateurs sont toujours acheminés vers Skype Entreprise. Les messages envoyés aux utilisateurs islands sont toujours acheminés vers le client à partir duquel ils ont été envoyés.

Tableau 1a : routage d’une nouvelle conversation ou d’un appel dans le locataire vers un destinataire en mode TeamsOnly

Tableau 1b : routage d’une nouvelle conversation ou d’un appel dans le locataire vers un destinataire en mode îles

Tableau 1c : routage des nouveaux appels ou des conversations dans le locataire vers un destinataire en mode Skype Entreprise

Routage fédéré pour les nouveaux appels ou conversations

Les tableaux ci-dessous capturent le routage des appels fédérés et des conversations, et sont valides pour les nouveaux appels ou conversations. Ils décrivent le client qui recevra un nouvel appel ou une nouvelle conversation, s’il provient d’un utilisateur à gauche, à un utilisateur cible fédéré à droite. En résumé, si la conversation est possible comme décrit ci-dessus, les messages envoyés aux utilisateurs TeamsOnly arrivent toujours dans Teams ; les messages envoyés aux utilisateurs du mode Skype Entreprise arrivent toujours dans Skype Entreprise ; les messages envoyés aux utilisateurs des îles arrivent toujours dans Skype Entreprise quel que soit le client à partir duquel ils ont été envoyés.

Le routage pour les conversations et les appels fédérés diffère du routage dans le locataire, car les utilisateurs des îles reçoivent toujours une communication fédérée dans Skype Entreprise. Cela est dû au fait que le partenaire fédéré n’utilise peut-être pas encore Teams. Le routage vers Skype Entreprise pour n’importe quel destinataire en mode îles garantit que les messages seront toujours reçus. Le routage vers Teams peut potentiellement entraîner une absence de communication si le destinataire prévu n’utilise pas Teams.

Tableau 2a : nouveau routage de conversation ou d’appel fédéré vers un destinataire en mode TeamsOnly

Tableau 2b : routage fédéré d’une nouvelle conversation ou d’un appel vers un destinataire Islands

Tableau 2c : routage fédéré d’une nouvelle conversation ou d’un nouvel appel vers un destinataire en mode Skype Entreprise

Conversations et appels à partir de threads préexistants

À partir de Teams

Les appels ou conversations démarrés à partir d’un thread de conversation préexistant dans Teams sont routés de la même manière que ce thread. Si le thread préexistant dans Teams était un thread natif (c’est-à-dire routé vers Teams), les messages de conversation et les appels supplémentaires de ce thread sont envoyés à Teams. S’il s’agit d’un thread d’interopérabilité (c’est-à-dire routé vers Skype Entreprise), des messages de conversation et des appels supplémentaires sont envoyés à Skype Entreprise (en supposant que des options de routage sont disponibles).

À partir de Skype Entreprise

Skype Entreprise threads ne sont pas conservés au-delà du délai d’expiration de session SIP de 10 minutes. Les conversations et les appels d’un thread existant dans Skype Entreprise avant l’expiration de la session SIP sont routés de la même manière que le thread. Les appels et conversations d’un thread existant dans Skype Entreprise au-delà du délai d’expiration de session SIP sont routés vers le Skype Entreprise de la partie distante, quel que soit le client d’où provient le thread d’origine du côté de l’autre partie.

Présence

Dans les situations où certains utilisateurs utilisent le client Teams et d’autres utilisent le client Skype Entreprise, il est possible que certains de ces utilisateurs utilisent les deux clients. Il est important de comprendre que la présence est publiée en fonction du mode de coexistence d’un utilisateur. Par exemple, si la conversation ou l’appel d’un initiateur doit se trouver sur le client Skype Entreprise de la cible, c’est la présence du client Skype Entreprise qui doit être affichée à l’émetteur. S’il doit atterrir sur le client Teams de la cible, c’est la présence du client Teams qui doit être affichée.

La présence est partagée en fonction du mode de coexistence d’un utilisateur, comme décrit ci-dessous :

• Si un utilisateur est en mode TeamsOnly, tout autre utilisateur (qu’il soit dans Teams ou Skype Entreprise) verra la présence teams de l’utilisateur TeamsOnly
• Si un utilisateur est dans l’un des modes Skype Entreprise (SfbOnly, SfbWithTeamsCollab, SfbWithTeamsCollabAndMeetings), tout autre utilisateur (que ce soit dans Teams ou Skype Entreprise) verra que Skype Entreprise présence Skype Entreprise de l’utilisateur
• Si un utilisateur est en mode Îles, la présence dans Teams et la présence dans Skype Entreprise sont indépendantes (les valeurs ne doivent pas correspondre) et les autres utilisateurs verront l’une ou l’autre présence de l’utilisateur Islands, selon qu’ils se trouvent dans le même locataire ou dans un locataire fédéré et le client qu’ils utilisent
  • À partir de Teams, tout autre utilisateur au sein du même locataire verra la présence de l’utilisateur Dans Teams. cette valeur est alignée sur la table de routage dans le locataire ci-dessus
  • À partir de Teams, tout autre utilisateur d’un locataire fédéré verra la présence Skype Entreprise de l’utilisateur islands ; cela est aligné sur le tableau de routage fédéré ci-dessus
  • À partir de Skype Entreprise, tout autre utilisateur verra la présence Skype Entreprise de l’utilisateur Islands (à la fois dans le locataire et fédéré). Cela est aligné sur les tables de routage ci-dessus

Présence dans le locataire

Les messages envoyés à TeamsOnly utilisateurs arrivent toujours dans Teams. Les messages envoyés aux utilisateurs du mode Skype Entreprise arrivent toujours dans Skype Entreprise, si la conversation est possible, comme décrit ci-dessus. Les messages envoyés aux utilisateurs des îles arrivent toujours dans le client d’où ils proviennent.

Le tableau décrit la présence du serveur de publication qui sera visible par un observateur, en fonction du mode du serveur de publication et du client de l’observateur (pour un nouveau thread).

Tableau 3 : présence dans le locataire (nouveau thread)

Présence fédérée

La présence fédérée est basée sur l’accessibilité fédérée indiquée dans le tableau 2. Le tableau ci-dessous décrit la présence du serveur de publication qui sera visible par un observateur, en fonction du mode du serveur de publication et du client de l’observateur (pour un nouveau thread). Dans la pratique, le client de l’Watcher ne fait aucune différence dans la fédération à ce stade.

Tableau 4 : présence fédérée (nouveau thread)

Présence dans des threads préexistants

Pour aligner la présence et l’accessibilité dans les threads préexistants, la présence de la cible exposée dans ce thread doit être alignée sur le routage du thread, en supposant que le routage est possible. En particulier, si un destinataire avec lequel vous aviez précédemment un thread de conversation d’interopérabilité persistant a été mis à niveau vers Teams, ce thread ne reflète plus la présence précise et ne peut plus être routable. Vous devez démarrer un nouveau thread.

Fédération et interopérabilité avec Office 365 gérés par 21Vianet

La fédération et l’interopérabilité entre les Office 365 multilocataires et les Office 365 gérées par 21Vianet sont prises en charge lorsque les utilisateurs multilocataires Office 365 sont en mode Teams uniquement. Dans ce scénario, Skype Entreprise utilisateurs en ligne dans Office 365 géré par 21Vianet pourront communiquer avec Les utilisateurs Teams uniquement dans des Office 365 multilocataires par le biais de conversations et d’appels. Le tableau suivant présente les scénarios pris en charge dans cette configuration :

Liens connexes

Guide de la migration et de l’interopérabilité pour les organisations qui utilisent Teams avec Skype Entreprise

Vidéo : Gérer la coexistence et l’interopérabilité entre Skype Entreprise et Teams