Fermer

septembre 25, 2019

Gestion de la coexistence et de l'interopérabilité dans les équipes Microsoft (partie 2)


Bienvenue à nouveau! Dans la partie 1 de ce blog nous avons couvert de manière approfondie la coexistence et l’interopérabilité entre Skype for Business et les équipes Microsoft concernées. Cette fois, nous allons encore plus loin en examinant la vue technique des scénarios d’interopérabilité que vous devez connaître pour pouvoir l’implémenter dans votre organisation. Cela dit, commençons par discuter de ce que vous devez savoir en tant qu'administrateur pour garantir la réussite de la mise à niveau!

Exigences techniques

Azure AD Connect

La première chose que vous voudrez examiner concerne Azure Active Directory Connect. Si vous avez actuellement Lync / Skype Entreprise Server sur site, la première chose à faire est de vous assurer qu'Azure AD Connect est opérationnel. C’est de loin l’élément le plus critique pour assurer la mise à niveau réussie d’équipes, car vous ne pourrez pas accéder aux équipes sans cela. Je soulignerai également qu'il s'agira de la première étape de votre processus de mise à niveau, car vous devrez vous assurer qu'une synchronisation correcte est effectuée entre votre répertoire AD local et Azure AD avant de pouvoir créer. Équipes utilisateurs. Sans cette étape, vous rencontrerez des problèmes d'entrées DNS en double, de comptes d'utilisateurs, d'expériences de routage interrompues et même d'affectations de stratégies non conformes. Cela inclura également la synchronisation des attributs "msRTCSIP" de l'environnement sur site vers Azure AD. Pour plus d’informations à ce sujet, je vous encourage à consulter la documentation de Microsoft ici .

Skype Entreprise Hybrid

La configuration de Skype Entreprise Hybrid / Split Domain à autoriser la coexistence entre Skype Entreprise Server sur site et votre client Office 365. Bien que la technologie hybride ne soit pas une exigence stricte, elle est vivement recommandée car l’interopérabilité entre Skype Entreprise et les équipes nécessitera sa mise en place. En résumé, si cela n’est pas configuré et que certains utilisateurs sont en mode Équipes uniquement alors que d’autres sont toujours sur Skype Entreprise Server sur site, ils ne pourront pas communiquer entre eux. En outre, si vous envisagez de migrer vos utilisateurs de Skype Entreprise sur site vers Skype Entreprise Online (ou directement vers des équipes Microsoft), vous aurez besoin d'un domaine hybride / divisé configuré pour y parvenir. Pour plus de détails à ce sujet, consultez la documentation de Microsoft ici .

Interop Flow Flowdown

Maintenant que nous savons quelles sont les exigences techniques, voyons sous quel capot Ces flux d'interopérabilité ressembleront à ceux qui vous permettront de déterminer plus facilement le scénario qui convient le mieux à votre organisation. Mais tout d’abord, quelques points à noter:

Le routage sera déterminé par:

  1. Mode du destinataire (Îles vs l’un des modes Sfb vs TeamsOnly)
  2. Le client de choix du créateur (Teams contre Skype for Business)
  3. Emplacement du client Skype Entreprise de l'expéditeur (sur site ou en ligne)

Après avoir déterminé ces 3 points, vous devriez être en mesure de déterminer si la communication sera possible ou non. Vous en trouverez un excellent exemple dans l'un des exemples ci-dessous:

SfBO ** et flux TeamsOnly (In-locataire)

Dans ce premier scénario, nous demander à un utilisateur Skype Entreprise Online (utilisateur A) d'essayer de parler à un utilisateur Teams uniquement (utilisateur B). Dans ce scénario, l'utilisateur A a un client Skype Entreprise Online mais le pas n'a le client Teams. À l’autre extrémité, l’utilisateur B s'exécute en mode de coexistence Équipes uniquement et, bien qu’il dispose du compte Skype Entreprise Online, il ne pourra pas l’utiliser car il est en mode «TeamsOnly». Comment savons-nous que l'utilisateur B dispose d'un compte Skype Entreprise Online? Eh bien, s’ils ne le faisaient pas, vous ne pourriez pas affecter l’utilisateur au mode TeamsOnly. Comme indiqué précédemment, il s'agit d'une des conditions requises pour le mode Équipes uniquement. Vous devez vous assurer que vos utilisateurs de serveurs Skype Entreprise sur site ont bien été migrés vers Skype Entreprise Online. En ce qui concerne la manière dont ces deux utilisateurs communiquent, ils tireront parti de la passerelle située à l'intérieur du service Teams d'Office 365, fournie par Microsoft, sans nécessiter de temps système supplémentaire. Lorsque l'utilisateur Skype Entreprise Online (utilisateur A) va parler à l'utilisateur Teams (utilisateur B), le client Skype Entreprise Online pense en réalité parler à un autre client Skype Entreprise Online. Toutefois, le service Teams déterminera qu’il est effectivement activé en tant qu’utilisateur Teams uniquement et redirige plutôt la conversation vers la passerelle. À partir de là, la conversation apparaîtra sur le client Teams de l’utilisateur B. C’est ainsi que l’interopérabilité entre les deux clients s’établit en coulisse.

Note ** : Les scénarios ci-dessus couvrent tous les scénarios SfB (SfBOnly, SfBWithTeamsCollab et SfBWithTeamsCollabAndMeetings). ils fonctionnent tous de la même manière du point de vue du routage

Flux SfB sur site ** et flux TeamsOnly (locataire)

Ce scénario est un peu différent que celui ci-dessus, en ce sens qu’il s’agit maintenant d’un utilisateur Skype for Business sur site essayant de communiquer avec un utilisateur Teams uniquement. En supposant que nous ayons un domaine hybride / partagé configuré entre le serveur Skype Entreprise sur site et le client hébergé d'Office 365, l'utilisateur Teams Only (utilisateur B) fonctionnera de la même manière que dans le scénario précédent dans lequel l'utilisateur Skype Entreprise sur site (Utilisateur A) essaiera de parler avec l'utilisateur Teams Only (Utilisateur B). Le client de l'utilisateur A pense qu'il parle à un utilisateur de Skype Entreprise Online, alors qu'en réalité le destinataire est un client Teams. Comme auparavant, le service réalisera que ce client a été mis à niveau vers des équipes et à son tour enverra la demande à la passerelle qui la transmettra au client des équipes. Le thread interop sera alors établi avec succès! Une fois que tout est dit et fait, l'expéditeur (utilisateur A) voit une petite bannière jaune indiquant que la personne à laquelle il souhaite parler (l'utilisateur B) ne se trouve pas sur un client Skype Entreprise.

Note ** : Les scénarios ci-dessus couvrent tous les scénarios SfB (SfBOnly, SfBWithTeamsCollab et SfBWithTeamsCollabAndMeetings), car ils fonctionnent tous de la même manière dans la perspective du routage

Islands Online et TeamsOnly (In-locant). ) flow

Ce scénario est un peu différent des deux précédents. Dans ce scénario, l’utilisateur A serait en mode Îles, ce qui signifie que son compte Skype Entreprise est dans Skype Entreprise Online, ainsi que dans les équipes Microsoft. Par contre, l’utilisateur B sera un utilisateur de TeamsOnly, ce qui signifie qu’il aura un compte Skype Entreprise Online, mais le compte ne sera pas disponible pour cet utilisateur car il a été mis à niveau vers le mode de coexistence «TeamsOnly». Si l'utilisateur en mode Îles (utilisateur A) utilise son client Teams pour parler à l'utilisateur TeamsOnly (utilisateur B), cette communication se déroule de manière native au sein des équipes. Comme vous vous en souvenez peut-être dans notre dernier blog, Islands signifie que toutes les communications commençant par ce client se terminent par le même type de client du côté destinataire. Cela étant dit, si l'utilisateur souhaitait utiliser son client Skype for Business pour parler avec l'utilisateur TeamsOnly (utilisateur B), l'utilisateur de TeamsOnly disposera d'un compte Skype for Business Online. Toutefois, étant donné que ce compte sert uniquement de compte «fantôme» et ne peut pas être utilisé par l’utilisateur de TeamsOnly, la communication passera du compte Skype Entreprise Online de l’utilisateur A à l’ombre Skype Entreprise Online de l’utilisateur B, puis sera acheminée vers la passerelle. La passerelle le transmettra ensuite au client Teams, ce qui établira le fil conducteur entre l'utilisateur Îles (utilisateur A) et l'utilisateur TeamsOnly (utilisateur B).

Note : Les mécanismes de routage sont pilotés par le mode de coexistence attribué à l'utilisateur cible .

Flux sur le circuit Islands et sur le système TeamsOnly (locataire)

]

Le scénario précédent était-il trop facile pour vous? Eh bien, utilisons le scénario précédent, mais ajoutons une complexité supplémentaire. Supposons qu'au lieu que le compte de l'utilisateur A soit configuré dans Skype Entreprise Online, cet utilisateur sera créé sur site. Tout d’abord, rappelez-vous que nous avons besoin de connectivité hybride pour pouvoir accéder à un utilisateur Teams uniquement. Par conséquent, en supposant que la configuration hybride soit configurée dans votre environnement, si l'utilisateur en mode Îles (utilisateur A) utilise son client Teams pour parler à l'utilisateur TeamsOnly (utilisateur B), cela se produit de manière native dans Microsoft Teams. Désormais, si l'utilisateur en mode Îles (utilisateur A) tente de communiquer avec TeamsOnly avec son client local Skype for Business, cela fonctionnera de la même manière que dans le scénario précédent. En supposant que la configuration hybride soit correctement configurée, le client local Skype Entreprise tentera de communiquer avec le compte Skype Entreprise Online pour l'utilisateur B. Toutefois, l'utilisateur B étant en mode TeamsOnly et ne pouvant pas utiliser son compte Skype Entreprise Online, Ce compte "shadow" fera en sorte que le service transmette cette demande à la passerelle où il l'enverra au client Teams. Ainsi, le fil conducteur sera établi entre le client Teams et le client Skype Entreprise sur site. Vous pensez peut-être que «c’était plus facile que je ne le pensais»? Heureusement, Microsoft parvient à rendre ce processus transparent, non seulement pour l'utilisateur final, mais également pour l'administrateur!

Flux en temps réel entre Islands Online et SfB **

Dans ce scénario, l'utilisateur A en mode Îles souhaite parler à l'utilisateur B qui se trouve dans l'un des modes SfB (SfBOnly, SfBWithTeamsCollab et SfBWithTeamsCollabAndMeetings). Par conséquent, l'utilisateur A est hébergé dans Skype Entreprise Online, mais dispose également d'un compte Teams et pourra utiliser toutes les fonctionnalités disponibles dans les deux clients. De son côté, l'utilisateur B aura un compte Skype Entreprise Online, mais pas un compte Teams, car il se trouve dans l'un des modes SfB répertoriés ci-dessus. Cela signifie que les fonctionnalités de conversation et d'appel ne seront pas disponibles pour cet utilisateur au sein des équipes. Désormais, lorsque l'utilisateur A (utilisateur du mode Îles) utilise son client Teams pour parler à l'utilisateur B (l'un des modes SfB), l'utilisateur B ne pourra recevoir de messages que dans son Skype for Business client . Du point de vue des clients, les équipes enverront cette communication à la passerelle qui pourra acheminer ce message via Skype Entreprise Online vers Skype Entreprise (Utilisateur B). Cela établirait ensuite l’interopérabilité entre le client Teams de l’utilisateur A et le client Skype Entreprise (utilisateur B).

Note ** : Les scénarios ci-dessus couvrent l’ensemble du SfB. scénarios (SfBOnly, SfBWithTollersCollab et SfBWithTeamsCollabAndMeetings) car ils fonctionnent tous de la même manière du point de vue du routage

Îles sur site et flux SfB ** (locataire)

]

Dans ce dernier scénario, nous aurons l’utilisateur A en mode Îles mais cette fois, son compte est référencé sur site . Comme ils sont en mode Îles, ils pourront utiliser les deux clients avec toutes les fonctionnalités disponibles. L'utilisateur B est configuré de la même manière que dans le scénario précédent, où il se trouve dans l'un des modes SfB, ce qui signifie qu'il ne sera pas en mesure d'utiliser le client Teams pour discuter et / ou appeler. Sous réserve que le domaine hybride / divisé soit correctement implémenté, lorsque l'utilisateur A (utilisateur sur site des îles) utilise son client Teams pour parler à l'utilisateur B (l'un des modes SfB), l'utilisateur A accède à la passerelle et la passerelle réalisera que l'utilisateur B est dans l'un des modes SfB et n'a pas la capacité d'utiliser le client Teams pour appeler / dialoguer. Ainsi, la passerelle tentera de rediriger cette information vers le client. Toutefois, étant donné que l'utilisateur A est hébergé sur site, le client ne pourra pas utiliser la passerelle d'interopérabilité et ne pourra donc pas communiquer avec l'utilisateur B. Le même concept est valable. n’importe quel type de fédération, car elle utilisera la même passerelle interop. Pour lutter contre cela, l'utilisateur A sera obligé d'utiliser son client Skype Entreprise afin de communiquer avec l'utilisateur B.

Note ** : Les scénarios ci-dessus couvrent tous les SfB. scénarios (SfBOnly, SfBWithTollersCollab et SfBWithTeamsCollabAndMeetings) car ils fonctionnent tous de la même manière du point de vue du routage

ATTENTION: Les utilisateurs du mode Îles installés dans leurs locaux ] Le client Teams ne pourra pas communiquer / fédérer avec les utilisateurs de SfBOnly, SfBWithTeamsCollab et SfBWithTeamsCollabAndMeetings. Pour communiquer dans ce cas d'utilisation, ils doivent utiliser leur client sur site Skype for Business .

Pour tout rapporter à la maison, Microsoft a si gracieusement fourni une table de routage des conversations / appels interop 1: 1. que vous pouvez référencer. En résumé, le routage sera toujours déterminé par le mode de coexistence attribué au destinataire / cible . Vous pouvez utiliser ce tableau pour déterminer où la conversation va atterrir. En tant que point de référence supplémentaire, vous pouvez visualiser «De l'expéditeur» en tant qu'utilisateur A et «À cibler» en tant qu'utilisateur B à partir des exemples ci-dessus.

Ceci conclut le blog de cette semaine sur la gestion de la coexistence et de l'interopérabilité dans les équipes Microsoft. Rendez-vous bientôt où je terminerai cette série de blogs en discutant en détail du routage d'accès externe / de fédération et résumant les enseignements clés tirés de cette série!




Source link