Stefan Plizga - Skype for Business

Partage d'expérience autour de Lync & Skype for Business

Désactiver la fonctionnalité de "Tagging" des contacts

Dans Lync et Skype for Business, il est possible de tagguer des contacts pour être notifié à chaque changement de statut, par exemple du passage de Hors ligne à Disponible, ou de Occupé à Disponible, et ainsi de suite...

Il peut arriver dans certains contextes qu'il soit demandé que la fonctionnalité soit désactivée. Et bien cela n'est pas possible nativement !

Cela dit, Lync Server et Skype for Business Server offrent des possibilités d'extensibilité côté serveur, grâce au MSPL (Microsoft SIP Processing Language), un language qui permet d'intéragir au niveau du proxy SIP directement et donc d'intercepter, de modifier ou même de rejeter des requêtes SIP. C'est d'ailleurs sur ce principe que toute la brique Lync Server / Skype for Business Server est bâtie. Pour les connaissance, je parle des "Server Applications" qu'il est possible de lister avec Get-CsServerApplication, il y en a déjà plusieurs nativement.

L'idée de ce billet est de montrer comment on peut bloquer cette fonctionnalité en utilisant le language MSPL afin d'intercepter les requêtes de tagging et les rejeter, tout simplement. Cela aura pour effet que le tagging ne soit pas fonctionnel.

Je vais faire court, je fourni directement le script en attachement, ContactTagBlocker.am. Grosso modo, voici ce qu'il fait :

  1. Il intercepte toutes les requêtes "SERVICE" et vérifie si le content-type "est application/SOAP+xml"
  2. Il cherche si le contenu XML contient la balise "contactSettings", et si celle-ci contient l'élement "tag"
  3. Si la valeur de l'élément "tag" est "true", c'est qu'il s'agit d'une requête de tagging d'un utilisateur, dans ce cas le script répond au client par un 403 (Forbidden / Interdit) et un petit message pour faciliter l'analyse des messages SIP côté client si nécessaire
  4. Dans le cas où toutes les conditions ci-dessus ne sont pas satisfaites, la requête continue son chemin dans le proxy SIP de Lync Server / Skype for Business Server

Le seul point à faire, c'est ajouter ce script dans les Server Applications du pool. Pour cela, il faut utiliser une commande de ce type :

$Priority = ((Get-CsServerApplication | ? {$_.Identity -match "UserServices"})[0]).Priority

New-CsServerApplication -Name ContactTagBlocker -Uri "http://blog.stefanplizga.net/ContactTagBlocker" -Enabled $True -ScriptName C:\MSPL\ContactTagBlocker\ContactTagBlocker.am -Critical $False -Priority $Priority -Parent (Get-CsService -Registrar)[0]

Rapides explications de ces 2 lignes PowerShell :

  1. La première ligne permet de récupérer la priorité de l'application User Services. C'est très important car le script en attachement doit s'exécuter avant User Services.
  2. La seconde ligne crée le Server Application. Il faut conserver toutes les valeurs telles qu'indiquées, et juste changer le chemin du script, qui dans mon exemple est dans le répertoire C:\MSPL\ContactTagBlocker

La création de ce Server Application se fait "à chaud", c'est-à-dire qu'elle ne nécessite pas de redémarrage du service Front End, le chargement se fait au bout de 1 à 2 minutes. On peut d'ailleurs voir un événement dans le journal d'événements Lync Server qui indique si le chargement s'est bien passé.

Quelques points d'attention cependant :

  • Les commandes PowerShell marcheront du premier coup dans le cas d'une infrastructure avec un seul pool. Il faudra un minimum adapter les 2 lignes pour récupérer la priorité de User Service du pool concerné et de changer le chiffre [0] après le Get-Registrar pour récupérer le pool souhaité.
  • Evidemment, ce script MSPL peut être installé sur tous les pools, qu'ils soient Standard ou Enterprise, en version Lync Server (dès la version 2010) ou Skype for Business Server 2015
  • Il faut copier le fichier .am sur tous les serveurs Front End du ou des pools sur lesquels le Server Application est créé
  • Le script ne rejette que les demandes de tagging, il laisse passer les demandes de suppression de tagging.
  • Tous les taggings déjà configurés resteront actifs jusqu'à ce qu'ils soient désactivés par l'utilisateur
  • Cette fonctionnalité n'est pas disponible dans Office 365


-- Stefan

ContactTagBlocker.am (1.7KB)

SEFAUtil, gestion des délégations hazardeuse

SEFAUtil, outil du Resource Kit bien connu des administrateurs Lync Server et Skype for Business Server, rend bien des services pour gérer le paramétrage de délégation et de renvoi d'appel pour les utilisateurs activés pour Enterprise Voice.

J'ai rencontré un cas intéressant où la suppression d'un délégué ne fonctionnait pas, en regardant un peu j'ai fini par trouver pourquoi...

Pour commencer, j'exécute SEFAUtil de la manière suivante mais l'assistant admin@domain.com reste un utilisateur délégué :

SEFAUtil Boss@domain.com /server:pool.domain.com /removedelegate:admin@domain.com

Après plusieurs essais, toujours pareil... J'en viens à me demander si SEFAUtil fonctionne, je décide donc de regarder la configuration de l'utilisateur Boss avec DBAnalyze:

DBAnalyze.exe /report:user /user:Boss@domain.com /sqlserver:.\RTCLOCAL

Et je vois bien mon délégué toujours présent :

Delegates
---------
1
Delegate               : Admin@domain.com

J'en viens à me demander si l'outil SEFAUtil fonctionne bien, et comme c'est un exécutable .NET, je peux utiliser Reflector pour lire le code source et creuser un peu, ainsi je tombe sur ça:


Code qui supprime un délégué si l'URI est présente dans la liste des délégués. Et pourtant ça ne fonctionne pas. Ma question est alors: est-ce que la fonction Contains de la propriété delegates est sensible à la casse (case-sensitive en Anglais)? On aurait tendance à dire que oui, mais un test vaut mieux qu'une hypothèse, donc vérification via un petit programme C# :


Et là surprise, le Contains ne répond pas la même chose si je mets tout en minuscule ou pas !

Donc, pour faire fonctionner SEFAUtil et removedelegate, je dois spécifier Admin@domain.com et non pas admin@domain.com puisque l'adresse SIP enregistrée dans les délégué est avec un A majuscule, et là ça marche parfaitement !

Ca vous servira peut-être un jour...

-- Stefan

Contacts Skype avec "E-mail Not Verified"

J'ai rencontré un cas très particulier, qui doit arriver très peu, mais qui m'a impacté puisque ça a touché mon propre compte Skype.

Comme beaucoup de personnes, j'ai un compte Skype (grand public) qui a la particularité d'avoir une liaison entre le login Skype "historique" et un compte Microsoft, cela afin d'avoir un seul compte Skype. J'ai remarqué que les personnes qui étaient sur Lync Server ou Skype for Business Server/Online et qui avaient mon compte Skype dans leurs contacts ne voyaient pas mon nom "Stefan Plizga" mais voyaient mon email suivi de "(E-mail Address Not Verified)".

En fait, à l'époque de MSN Messenger, il fallait vérifier son email sinon la fédération avec OCS 2007 fonctionnait avec ce type de processus. Evidemment, à l'époque tout fonctionnait bien, c'est juste récemment que j'ai remarqué ce changement sur mon compte, mais cela dure peut-être depuis un temps plus long.

Bref, le problème semblait venir du fait que j'avais mon compte Skype lié à mon compte Microsoft. La seule solution possible à mes yeux était d'essayer de délier mes comptes pour ensuite les relier ensemble : lorsqu'on se connecte sur le portail Skype grand public, on a la possibilité de délier son compte Microsoft, avec un avertissement qui dit que tous les contacts MSN Messenger seront perdus et que délier/relier un compte ne peut être réalisé qu'un certain nombre de fois. Pas vraiment une super nouvelle mais je n'avais pas vraiment le choix. Alors j'ai tenté le coup : j'ai donc délié mes comptes, puis je me suis reconnecté avec le client Skype avec mon compte Microsoft et j'ai indiqué souhaité lié ce compte Microsoft à un compte Skype existant pour relier le tout comme au début de l'opération. Et au final, le nom d'affiche est maintenant correct, il affiche bien Stefan Plizga et cerise sur le gateau, je vois encore mes contacts MSN Messenger dans Skype. Cela est peut-être lié au fait que j'ai fait l'opération de suppression de lien et de recréation du lien dans la foulée, il est impossible de le savoir réellement mais tel est le fait.

Cette expérience ne signifie pas que si vous rencontrez le même problème, vous aurez la même chance que moi, mais on peut estimer que l'expérience est plutôt satisfaisante et qu'un essai se tenterait même si un risque de tout perdre subsiste toujours.

-- Stefan

Role-Based Access Control et les groupes de sécurité CS*Administrator

Lorsqu'on a un déploiement Lync Server 2010/2013 ou Skype for Business Server 2015, il est possible de définir des droits granulaires pour la gestion de certaines parties de l'infrastructure ou des utlisateurs. Des groupes existent pour cela, par exemple CSUserAdministator, CSVoiceAdministrator et bien d'autres... Ils respectent tous le nommage CS*Administrator.

Chaque groupe donne la possibilité d'exécuter des commandes d'administration spécifiques, mais il s'avère que cela ne fonctionne pas lorsqu'on utilise Lync Server Management Shell ou Skype for Business Server Management Shell. Pourquoi ? Parce que ces Shells n'utilisent pas les groupes CS*Administrator qui permettent de bénéficier de RBAC mais utilisent uniquement les groupes RTCUniversalUserAdmins ou RTCUniversalServerAdmins au niveau de la vérification des droits.

Pour bien gérer la délégation de droits et profiter de RBAC, il faut bien utiliser les groupes CS*Administrator mais aussi se connecter à Management Shell en Remote PowerShell, de la manière suivante :

  1. Ouvrir une fenêtre PowerShell classique depuis n'importe quel PC (pas Lync Server Managment Shell ou Skype for Business Management Shell) et taper :
  2. $cred = Get-Credential "<Compte AD de l'administrateur>
  3. $session = New-PSSession -ConnectionURI “https://<FQDN d'un Front End>/OcsPowershell” -Credential $cred
  4. Import-PsSession $session
  5. Exécuter les commandes souhaitées
  6. A la fin, arrêter la session Remote PowerShell par Remove-PsSession $session

Dans la quasi-totalité des cas, cela suffira pour que les membres des groupes CS*Administrator puissent exécuter les cmdlets Lync Server / Skype for Business Server. Dans de très rares cas, il y aura quand même le message :

Active Directory operation failed on "<Domain Controller>". You cannot retry this operation: "Access is denied
00000005: SecErr: DSID-03152612, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Cela se produit notamment dans le cas où il manque des permissions, ce qui est rare mais c'est le cas lorsqu'on veut gérer les Common Area Phones, car les objets créés dans AD sont des contacts. En effet, par défaut RBAC ne s'applique pas aux objets Contact. Pour autoriser la gestion des Common Area Phones via les cmdlets en Remote PowerShell, il faut d'abord ajouter des droits sur l'OU qui contiendra les objets Contact représentant ces téléphones. La commande à exécuter est simple : Grant-CsOuPermission -OU "OU=Common Area Phones,DC=contoso,DC=com" -ObjectType "contact"

Une fois cette commande exécutée, la gestion des Common Area Phones en Remote PowerShell est possible.

RBAC dans Lync Server / Skype for Business Server est beaucoup plus poussé : en effet, depuis Lync Server 2013, il est possible de créer des rôles personnalisés pour être très ganulaire. Aussi, RBAC permet également de séparer l'administration des utilisateurs d'une OU de celle d'une autre, en créant des roles RBAC spécifiques qui s'appliquent à une OU en particulier. Je n'entrerai pas dans le détail de cela ici, mais peut-être une procaine fois.

Pour approfondir, on trouve de la lecture sur https://technet.microsoft.com/en-us/library/gg425917(v=ocs.15).aspx.

-- Stefan

Information d'inactivité erronée sur Skype for Business

Lorsqu'on utilise le client Lync ou Skype for Business, on voit en général le temps d'inactivité des personnes de sa liste de contacts, par exemple "Alice - Offline (2 days)".

Suite à une migration de Lync Server 2013 vers Skype for Business Server 2015, certains utilisateurs qui se connectaient régulièrement à Skype for Business apparaissaient avec un status "Offline (45 days)" lorsqu'ils étaient déconnectés, 45 days représentant le nombre de jours depuis la migration de Lync Server 2013 vers Skype for Business Server 2015.

Ce problème est plus ou moins décrit dans la KB http://support.microsoft.com/en-us/kb/3056287, qui indique toucher Skype for Business Online et Skype for Business Server (ce n'est pas très clair dans l'article mais c'est bel et bien le cas). D'après l'article, le problème a été solutionné dans Skype for Business Online mais pas encore dans Skype for Business Server.

Le point intéressant en diagnostiquant ce problème, c'est qu'on se rend compte qu'une partie de l'information d'inactivité, appellée LastActive dans Lync/Skype for Business, n'est pas répliquée correctement dans la base RTCLOCAL des serveurs Front-End qui hébergent le Routing Group de l'utilisateur. Pour ceux que ça intéressent, cela peut se voir simplement en utilisant l'outil DBAnalyze.exe, disponible dans les Resource Kit Tools de Lync Server 2013 (les RK Tools de Skype for Business Server 2015 ne sont pas encore disponibles mais l'outil en version 2013 fonctionne bien pour cet usage). Sur chaque Front End du pool, il faut donc exécuter la commande suivante:

C:\Program Files\Microsoft Lync Server 2013\ResKit>DBAnalyze.exe /report:user /user:<Adresse SIP de l'utilisateur> /sqlserver:.\RTCLOCAL

En analysant ce que l'outil donne, on peut voir que l'attribut LastActive n'a pas la même valeur sur tous les Front End.

Microsoft ne propose pas de solution à ce problème, alors voici la solution que j'ai utilisée. Elle est un peu violente mais fonctionne très bien : il s'agit de réinitialiser le contenu de la base RTCLOCAL, car l'information LastActive n'est pas synchronisée dans le Back End SQL. La procédure est très simple, à faire sur chaque Front End en prenant le temps d'attendre que l'opération soit complètement terminée sur un Front End avant de passer au suivant :

  1. Lancer Skype for Business Server Management Shell en tant qu'administrateur
  2. Stopper les services Skype for Business Server avec Stop-CsWindowsService
  3. Lancer la commande Install-CsDatabase -LocalDatabases -Clean (cela va supprimer les bases de l'instance RTCLOCAL et les recréer)
  4. Redémarrer les services Skype for Business Server avec Start-CsWindowsService
  5. Attendre quelques minutes, car ce démarrage revient au même qu'un premier démarrage d'un Front End après une installation fraîche, il doit donc récupérer de l'information depuis le Back End et Skype for Business Server va rebalancer les Routing Groups. Compter environ 5 minutes d'attente.

Cette technique permet de remettre les Front End dans un état initial et de récupérer le contenu "propre" depuis le Back End (liste de contacts, conférences planifiées...). Cette opération génère cependant une interruption de service car le mouvement des Routing Groups pendant l'opération peut faire tomber les utilisateurs connectés dans le mode "Résilience" où la liste de contact n'est pas disponible. Il est donc fortement recommandé de réaliser de type d'opération en dehors des périodes ouvrées.

Pour ma part, l'opération complète a pris environ 30 minutes pour "nettoyer" un pool composé de 4 serveurs Front End.

-- Stefan

Subtilité de fédération avec Office 365

Quand on dispose d'une infrastructure Lync Server 2013 ou Skype for Business Server 2015 et qu'on veut fédérer avec des sociétés qui sont hébergées sur Office 365 (Skype for Business Online - SfBO), il faut suivre l'article reference sur https://technet.microsoft.com/en-us/library/jj205126.aspx.

Cependant, il y a un cas de figure où la federation entre l'environnement interne et Skype for Business Online ne fonctionne pas, sans raison apparente... si les conditions suivantes sont réunies :

  • Votre entreprise dispose d'un "tenant" Office 365 (un environnement Office 365 sous la forme <Company>.onmicrosoft.com).
  • Le nom de domaine de votre entreprise a été ajouté à ce "tenant".
  • Skype for Business Online n'est pas utilisé dans ce tenant pour le nom de domaine de votre entreprise puisque vous utilisez Lync Server ou Skype for Business Server.
  • Par contre, dans les options de Skype for Business Online, la fédération est configurée en mode "External Access = On only for allowed domains", si vous souhaitez pas exemple que vos comptes Office 365 liés au domaine <Company>.onmicrosoft.com puissent profiter de Skype for Business Online et fédérer avec vos utilisateurs Skype for Business Server.

Lorsque ces conditions sont toutes réunies, les utilisateurs hébergés sur Lync Server ou Skype for Business Server ne peuvent pas fédérer avec les sociétés hébergées sur Skype for Business Online à moins que ces sociétés soient explicitement ajoutées dans la liste des domaines autorisés dans Skype for Business Online, tout cela indépendemment de la configuration de federation sur l'infrastructure interne qui peut autoriser la fédération avec toutes les sociétés.

En résumé, si vous avez un "tenant" Office 365 avec votre nom de domaine configuré dessus et que vous n'utilisez pas Skype for Business Online, le mieux est de configurer la fédération dans SfBO sur "Off completely" ou sur "On except for blocked domains". Ces deux paramètres autoriseront votre infrastructure Lync Server ou Skype for Business Server à fédérer avec les sociétés hébergées sur Skype for Business Online.

Pour aller dans le detail, voici un tableau qui récapitule les possibilités :


-- Stefan

PSTN Conferencing et Cloud PBX avec PSTN Connectivity en Preview sur Skype for Business Online

Depuis quelques temps, certaines fonctionnalités sont disponibles en Preview sur Skype for Business Online, dont notamment les fameux Large Meetings qui permettent de faire des conférences en mode présentation jusqu'à 10 000 personnes !

D'autres fonctionnalités étaient également en Preview depuis ce moment, et cela a évolué hier : la fonctionnalité PSTN Conferencing est ouverte à 11 nouveaux pays - dont la France - et n'est donc plus limitée qu'aux Etats Unis ! Cette fonctionnalité est très prometteuse puisqu'elle offer la possibilité à des utilisateurs qui n'ont ni PC ni smartphone (ou alors sans connexion de données) de joindre une conférence hébergée sur Skype for Business Online depuis un téléphone, à l'instar de ce qui existe déjà depuis OCS 2007 avec à l'époque le client Live Meeting.

Une autre nouvelle fonctionnalité, Cloud PBX with On-premises PSTN Connectivity, est intéressante puisqu'elle permet de migrer les utilisateurs vers Skype for Business Online tout en conservant la possibilité d'utiliser l'infrastructure Skype for Business Server interne pour les fonctionnalités de téléphonie - avec certes quelques limitations. Pour ceux qui s'en souviennent, il s'agit globalement du retour du scenario "Hybrid Voice" introduit avec Lync Server 2013 et qui avait été supprimé très peu de temps après la RTM de Lync Server 2013. Comme quoi, les choix évoluent dans le temps...

Plus d'informations et la possibilité de s'enregistrer dans le programme Preview sur http://www.skypepreview.com/.

Je ferai un petit retour sur mes tests dès que possible...

-- Stefan

LUMT 1.2.0.0 est disponible et supporte le groupe "Favoris"

LUMT, que je re-présentais dans un précédent post, est un outil destiné aux administrateurs Lync Server 2013. Il permet entre autres d'ajouter des contacts dans la liste de contacts des utilisateurs à leur place. Par exemple, lors de l'arrivée d'un nouvel employé, il est possible de pré-peupler sa liste de contacts avec des personnes et groupes définies.

Une personne m'a demandé via CodePlex, platform qui héberge le code et l'outil lui-même, s'il était possible d'ajouter des contacts dans le groupe special "Favoris", car cela ne fonctionnait pas ! En effet, ce groupe doit subir un traitement particulier, mais la modification était triviale je viens de mettre à jour LUMT en version 1.2.0.0 pour supporter ce cas de figure.

Si vous êtes intéressés par LUMT et cette nouvelle fonctionnalité, rendez-vous sur http://lumt.codeplex.com pour récupérer l'exécutable et surtout lisez bien la documentation pour l'installer et ajouter des contacts dans le groupe "Favoris" puisqu'il faut utiliser le nom technique "Pinned Contacts" pour que ça fonctionne.

-- Stefan

Supprimer un ancien Trusted Application Pool dans Skype for Business Server 2015

Dans le cas où un TrustedApplicationPool et une TrustedApplication ont été créé dans Lync Server 2010 historiquement et que l'infrastruscture a été mise à jour vers Lync Server 2013 puis vers Skype for Business Server 2015, la suppression du Trusted Application Pool peut poser problème.

Bizarrement, il est possible de supprimer en PowerShell, depuis Skype for Business Server 2015, l'objet TrustedApplication, mais l'objet TrustedApplicationPool ne peut pas être supprimé et l'erreur indiquant que l'objet est trop vieux est indiquée.

La solution pour supprimer proprement le TrustedApplicationPool est simple : le faire depuis le Topology Builder qui autorise la modification, puis republier la topologie.

-- Stefan

LUMT n'est pas mort...

... et moi non plus ! Ca fait un bon moment que je n'avais rien posté, tout simplement parce que j'écris ce blog sur mon temps personnel et que j'ai eu peu de temps jusqu'à maintenant. Revenons au sujet du post...

LUMT, qu'est-ce donc? Il s'agit de Lync User Management Tool, un outil destiné aux administrateurs Lync Server 2013. Cet outil permet entre autres d'ajouter des contacts dans la liste de contacts des utilisateurs à leur place. Par exemple, lors de l'arrivée d'un nouvel employé, il est possible de pré-peupler sa liste de contacts avec des personnes et groupes définis.

LUMT permet également de modifier les ACE (Access Control Entries) mais cela n'étant pas vraiment visuel dans Lync, il vaut mieux savoir ce qu'est une ACE dans les listes de contacts Lync avant de jouer avec. Et il permet aussi de modifier des petits paramètres par défaut tels que les préférences d'alertes ou de gestion de la visibilité de la présence.

J'avais développé cet outil en 2011 et je n'ai jamais fait de publicité sur son existence, mais il a du faire son chemin puisqu'à ce jour il totalise 3355 téléchargements. Quelques problèmes d'exécution m'avaient été remontés et je n'avais jamais eu le temps d'ajouter un peu de logging avancé pour comprendre d'où vient le problème. C'est maintenant chose faite, je viens de publier la version 1.1.0.0 de LUMT sur CodePlex.

Si vous êtes intéressés par LUMT, rendez-vous sur http://lumt.codeplex.com pour récupérer l'exécutable et surtout lisez bien la documentation pour l'installer !

-- Stefan

Réunions Skype for Business à 10 000 participants

Voici un post que j'avais commencé à écrire mais que je n'avais jamais posté. C'est chose faite !

Lors du Keynote de la conférence Ignite de Microsoft à Chicago en mai dernier, Microsoft a annoncé la possibilité d'avoir des réunions Skype for Business jusqu'à 10 000 participants ! Evidemment, cela implique certaines spécificités mais la fonctionnalité est bel et bien là.

Globalement, cela fonctionnera ainsi :

  • Les réunions au-delà de 250 participants pourront être étendues jusqu'à 10 000 dans un mode "broadcasting", c'est-à-dre que les participants pourront suivre la présentation depuis leur navigateur dans un seul sens : présentateur vers participants.
  • Les participants n'utiliseront pas Lync Web App mais une interface spécifique dédiée au broadcasting.
  • Pour permettre de gérer autant de participants, une infrastructure Skype for Business Server devra être configurée en mode hybride avec Skype for Business Online. Cela permettra en réalité de faire le pont Azure Media Services en back-end pour réaliser le "broadcasting".

La présentation faite à l'Ignite à ce sujet est disponible sur http://channel9.msdn.com/Events/Ignite/2015/BRK3198.

-- Stefan

Skype Directory Search

Maintenant que Skype for Business Server est disponible et que Skype for Business Online est également déployé, il est possible de profiter de la fonctionnalité Skype Directory Search qui permet de rechercher des utilisateurs dans l'annuaire Skype grand public depuis son client Skype for Business 2015.

Pour que ça fonctionne, il faut disposer d'une infrastructure Skype for Business Server 2015 ou Online et du client Skype for Business.

Il est possible de rechercher une personne à partir du nom, du nom et de la ville, de l'email, du numéro de téléphone ou de l'identifiant Skype.

Toutes les infos sont sur TechNet à la page http://technet.microsoft.com/en-us/library/dn705313.aspx.

-- Stefan

Skype for Business Server 2015 disponible au téléchargement

Skype for Business Server 2015 est disponible depuis le 1er mai sur MSDN et Volume Licensing. Il est d'ores et déjà possible de tester cette évolution de Lync Server 2013 en lab et de préparer son déploiement !

Pour rappel, la mise à jour depuis Lync Server 2013 peut se faire directement sur les mêmes serveurs. La documentation TechNet pour ce cas de figure est disponible sur http://technet.microsoft.com/en-us/library/dn951371.aspx.

-- Stefan

Documentation Skype for Business Server 2015 sur TechNet

TechNet commence depuis quelques jours à avoir des informations sur Skype for Business Server 2015. Ce n'est pas encore complet et il reste beaucoup à ajouter pour arriver au même niveau d'information sur Lync Server 2013 mais le contenu actuel permet déjà de bien démarrer : http://technet.microsoft.com/en-us/library/gg293124(v=ocs.15).aspx.
Il faut aussi conserver à l'esprit que la majorité du contenu Lync Server 2013 est valide pour Skype for Business Server 2015, ce qui peut dépanner en attendant d'avoir le contenu officiel de la version 2015.
-- Stefan

Poster Skype for Business Server 2015 Protocol Workloads

Le traditionnel poster "Protocol Workloads" qui existait depuis Lync Server 2010 est disponible pour Skype for Business Server 2015. L'infrastructure ayant subi peu de modifications depuis Lync Server 2013, les flux restent sensiblement similaires.
On peut tout de même noter les points suivants:
  • IM and Presence :
    • Nouveau flux HTTPS (TCP/443) depuis le Edge vers Internet pour la recherche dans l'annuaire Skype grand public
  • A/V and Web Conferencing :
    • Présence du VIS (Video Interoperability Server) avec les flux associés qui sont des trucs classiques SIP et RTP
Le poster est disponible sur http://technet.microsoft.com/en-us/library/dn594589.aspx
-- Stefan