Stefan Plizga - Skype for Business

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

Optimiser les performances de SQL Server Express sur les serveurs Front-End

Microsoft ne donne pas de bonnes pratiques particulières concernant les bases de données existantes dans SQL Server Express sur les serveurs Front-End. On dit toujours qu'il n'y a rien de particulier à faire, et ce n'est pas faux. Par contre, dans certains cas, on peut observer des temps de réponse de Lync Server / Skype for Business Server qui deviennent plus long sans raison apparente.

Dans SQL Server, on retrouve des indexes sur les tables, qui permettent à SQL d'accéder à l'information plus vite, et on observe que l'ajout de plan de maintenance qui gère les indexes et met à jour les statistiques peut améliorer les performances des serveurs Front-End.

Voici une petite procédure pour mettre en place ce type de plan de maintenance. Il existe d'autres méthodes pour arriver à la même opération mais celle-ci est simple compte-tenu du fait que l'Agent SQL ne fonctionne pas par défaut sur les serveurs Front-End, et que je cherche à éviter de faires des modifications qui pourraient disparaître lors d'une mise à jour.


Les étapes sont relativement simples :

SET @CreateJobs = 'N'
SET @LogToTable = 'N'

  • Se connecter depuis une machine distante qui a SQL Server Management Studio à l'instance RTCLOCAL de chaque Front-End. Si nécessaire pour cette opération temporaire, désactiver le pare-feu Windows ou créer une exception pour SQL Server Express
  • Lancer un New Query editor et exécuter le contenu du fichier MaintenanceSolution.sql
  • Faire la même opération avec l'instance LYNCLOCAL de chaque Front-End


A partir de ce moment, l'outillage est en place. Puisque l'Agent SQL n'est pas fonctionnel par défaut, on va utiliser une tâche planifiée sur chaque Front-End pour exécuter le plan de maintenance :

  • Créer un fichier IndexOptimize.sql avec le contenu suivant et le place dans le répertoire C:\Tools\IndexOptimize de chaque Front-End :

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y',
@PageCountLevel = 10

  • A l'aide du Task Scheduler de Windows, créer une tâche planifiée avec les paramètres suivants :
    • Tâche exécutée par : NT AUTHORITY\SYSTEM
    • Planification : Journalière, à 5h00
    • Action 1 :
      • Programme : osql.exe
      • Arguments : -E -S .\RTCLOCAL -i IndexOptimize.sql
      • Répertoire : C:\Tools\IndexOptimize
    • Action 2 :
      • Programme : osql.exe
      • Arguments : -E -S .\LYNCLOCAL -i IndexOptimize.sql
      • Répertoire : C:\Tools\IndexOptimize


Quelques notes :

  • Pour la simplicité, l'exemple ci-dessus utilise le compte NT AUTHORITY\SYSTEM mais il est possible d'utiliser un autre compte qui fait partie des administrateurs locaux (c'est le seul groupe qui a le role "sysadmin" dans les deux instances RTCLOCAL et LYNCLOCAL)
  • J'ai choisi 5h pour l'exécution de la tâche planifiée mais ça peut être à un autre moment en fonction de l'occupation des serveurs et des autres traitements.
  • Pour vérifier que le script fonctionne bien, il est possible d'ajouter la ligne @LogToTable = 'Y' (sans oublier une virgule à la fin de la ligne précédente) dans le fichier IndexOptimize.sql et ainsi voir le contenu de la table LogCommand de la base master de chaque instance. S'il y a des lignes,c'est que ça fonctionne, sinon il y a probablement un problème dans le fichier IndexOptimize.sql ou dans la ligne de commande exécutée par la tâche planifiée. Ne pas oublier de supprimer le @LogToTable après le test et de vider la table LogCommand car celle-ci ne se vide jamais automatiquement


Aussi, il ne faut pas oublier d'appliquer les Service Packs et les CU sur les instances SQL Express des serveurs Front-End !

-- Stefan

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

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

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

Petits impacts après la mise à jour d'avril pour le client Lync 2013

Dans l'article précédent, j'ai fait un focus particulier sur le contrôle de l'interface du client Lync/Skype pour éviter les mauvaises surprises, notamment au premier lancement du client Lync une fois la mise à jour d'avril installée.
Même avec cette manipulation, les utilisateurs doivent être prévenus du changement car certains changements ne sont pas contrôlables :
  • L'application se nomme Skype for Business 2015 (Skype Entreprise 2015 en français), et c'est ce nom qu'on retrouve dans le menu Démarrer/Windows, quel que soit le mode d'affichage du client Lync. L'icône est l'icône de Skype for Business par la même occasion.
  • Dans Outlook, une fois la mise à jour d'avril installée, l'utilisateur crée des Skype Meetings et plus des Lync Meetings. L'icône change dans Outlook et le nom aussi.

Ces deux points sont mineurs mais ils peuvent susciter des questions auprès des utilisateurs. Il est donc préférable de communiquer le changement en indiquant qu'une transition de Lync vers Skype Entreprise est en train de s'opérer et que le client Lync qu'ils connaissent va évoluer petit à petit pour devenir Skype Entreprise.

-- Stefan

Précisions sur la mise à jour du client Lync vers Skype for Business

L'article Configure the client experience with Skype for Business est apparu sur TechNet il y a peu de temps. On apprend quelque chose de très important qui peut avoir un impact sur les utilisateurs si la mise à jour du client n'est pas prepare un minimum.

Pour rappel, c'est la mise à jour du client Lync 2013 qui apporte l'interface Skype for Business. Il n'y a pas, pour le moment au moins, de client Skype for Business seul. La mise à jour du client concerne donc toutes les entreprises qui utilisent le client Lync 2013 !

Avant d'entrer dans le vif du sujet, un point TRES IMPORTANT : si vous déployez la mise à jour Lync 2013 d'avril 2015 sans preparation, les utilisateurs verront l'interface Skype for Business au premier lancement ! En effet, sur TechNet il est indiqué que "By default, when users launch Skype for Business for the first time, they will always see the Skype for Business user interface--even if you have selected the Lync client experience by setting the value of the EnableSkypeUI parameter to $False as described previously. After several minutes, users will then be asked to switch to Lync mode."

Il existe un moyen pour que les utilisateurs du client Lync 2013 ne soient pas du tout perturbés et ne voient pas l'interface Skype for Business au premier lancement : configurer la clé de registre HKEY_CURRENT_USER\Software\Microsoft\Office\Lync\EnableSkypeUI de type Binary avec la valeur 00 00 00 00. Attention, il s'agit d'une clé de register HKEY_CURRENT_USER, qui s'applique donc aux utilisateurs et non pas à la machine.

La bonne nouvelle est que la méthode pour créer une GPO qui place cette clé de registre est décrite dans le même article TechNet dans la partie "Create a Group Policy Object to modify the registry on a domain joined computer". En préparant cette clé de register, le déploiement de la mise à jour Lync 2013 d'avril 2014 devrait ensuite être transparent pour les utilisateurs qui se connectent sur Lync Server.

La petite question à se poser c'est pourquoi il faut positionner cette clé alors que la Client Policy EnableSkypeUI peut être mise à False dans Lync Server ? La réponse est simple : les paramètres de Client Policy s'appliquent au moment de la connexion de l'utilisateur à Lync Server, et donc il est déjà trop tard pour choisir le mode d'affichage du client en Lync ou Skype for Business. La GPO permet donc de pré-configurer le parameter à False et ensuite la Client Policy appliquera le choix indiqué dans le paramètre EnableSkypeUI, qui permettra ensuite à l'administrateur d'activer l'interface Skype for Business quand il le souhaitera.

Une autre ressource intéressante pour completer l'article TechNet est l'article Controlling the Client Experience with Skype for Business de Scott Stubberfield, du groupe produit Skype for Business, qui contient un PowerPoint expliquant les différents cas de figures possibles.

Bonne préparation et bon déploiement de la mise à jour d'avril 2014 du client Lync 2013 !

--Stefan

Disponibilité du client Skype for Business le 14 avril 2015

Microsoft a annoncé que le client Skype for Business va être disponible le 14 avril 2015 par le biais d'une mise à jour du client Lync 2013.

En effet, cela a déjà été évoqué dans des publications précédentes, le client Lync va devenir le client Skype for Business via l'application d'un Cumulative Update. Le client disposera dès lors des deux interfaces : Lync et Skype for Business. Par défaut, le choix de l'interface sera fait de la sorte :

  • Si l'utilisateur se connecte sur Lync Server, il aura l'interface Lync.
  • Si l'utilisateur se connecte sur Skype for Business Server, il aura l'interface Skype for Business.
  • Si l'utilisateur se connecte dans Office 365, il aura l'interface Skype for Business car la connexion à Lync Online / Skype for Business Online aura pour effet d'afficher l'interface Skype for Business.

Faut-il pour autant retarder l'application du Cumulative Update d'Avril pour Lync 2013 ? Pas forcément, car Microsoft met à la disposition des administrateurs la possibilité de forcer le client à afficher l'interface Lync ou l'interface Skype for Business :

Au final, pas de changement brusque pour les entreprises qui utilisent Lync Server puisque l'interface du client Lync restera celle qu'elle est. Par contre il est important de choisir le comportement à adopter pour Lync Online / Skype for Business Online.

-- Stefan

Focus sur In-Place Upgrade

Un point intéressant concernant la migration vers Skype for Business Server est qu'il est possible de mettre à jour son infrastructure Lync Server 2013 vers Skype for Business sans créer de nouveau pool mais tout simplement en faisant une mise à jour. L'objectif est multiple :

  • Conserver le matériel existant (les spécifications matérielles de Skype for Business Server 2015 sont identiques à celles de Lync Server 2013).
  • Réaliser la mise à jour rapidement sans repenser toute son architecture.
  • Réduire le coût de déploiement.
  • S'assurer au passage que l'infrastructure Skype for Business ainsi obtenue est au niveau de mise à jour le plus récent

Un détail très important est que cette mise à jour "sur place", où In-Place Upgrade en anglais, n'est possible que pour une infrastructure Lync Server 2013. Les entreprises qui ont une infrastructure Lync Server 2010 devront réaliser une migration "classique" en créant un nouveau pool Skype for Business Server et en déplaçant les utilisateurs vers ce nouveau pool. De même, les entreprises qui ont une mixité Lync Server 2010 et Lync Server 2013 devront, au préalable d'une quelconque évolution, rationaliser leur environnement pour avoir préférablement que du Lync Server 2013 qui permettra par la suite une mise à jour In-Place.


Scénarios de mise à jour

Ceci étant dit, passons maintenant aux possibilités de mettre à jour une infrastructure Lync Server 2013 vers Skype for Business Server 2015 :

  1. Mise à jour du pool avec interruption de service
  2. Mise à jour du pool avec déplacement d'utilisateurs et sans interruption de service


Dans le scénario "Mise à jour du pool avec interruption de service", le principe est très simple :

  1. Informer les utilisateurs de la maintenance qui introduit une interruption de service.
  2. Mettre à jour le pool Lync Server 2013 vers Skype for Business Server 2015.
  3. Vérifier que tout fonctionne.
  4. Informer les utilisateurs que la maintenance est terminée.


Dans le scénario "Mise à jour du pool avec déplacement d'utilisateurs et sans interruption de service", on ajoute quelques étapes pour éviter une interruption de service. Le principe est le suivant :

  1. Avoir au préalable 2 pools Lync Server 2013.
  2. Déplacer les utilisateurs du premier pool vers le second pool.
  3. Mettre à jour le premier pool Lync Server 2013 vers Skype for Business Server 2015.
  4. Vérifier que tout fonctionne.
  5. Déplacer tous les utilisateurs du second pool Lync Server 2013 vers le premier pool mis à jour vers Skype for Business Server 2015.
  6. Mettre à jour le second pool Lync Server 2013 vers Skype for Business Server 2015.
  7. Vérifier que tout fonctionne.
  8. Déplacer les utilisateurs qui étaient à l'origine sur le second pool Lync Server 2013 vers ce pool maintenant en version Skype for Business Server 2015.


Il y a aussi certains points d'attention :

  • Il n'est pas recommandé d'utiliser le Pool Failover pour faire la bascule des utilisateurs pour la mise à jour de Lync Server 2013 vers Skype for Business Server 2015.
  • Pour autant, il ne faut pas supprimer le Pool Pairing mis en place sur Lync Server 2013 avant de mettre à jour son environnement vers Skype for Business Server 2015.
  • Cela signifie que l'environnement Lync Server 2013 doit être sain avant de procéder à la mise à jour vers Skype for Business Server 2015.
  • Il est fortement recommandé de mettre à jour deux pools en Pairing dans un intervalle de temps court.


On a parlé jusqu'ici des pools mais une infrastructure Lync Server et Skype for Business Server ne se limite pas uniquement à ces composants. Pour la mise à jour, l'ordre à suivre est le suivant :

  1. Pools en premier (avec mise à jour de la topologie au préalable pour chaque pool à mettre à jour).
  2. Composants partagés ensuite.
    • Mediation Server
    • Director
    • Edge
    • CMS
    • Persistent Chat

A noter que tous les rôles se mettent à jour à l'exception des SBA puisque ceux-ci sont soumis à la mise à disposition d'une image par le fabriquant de la passerelle.

En termes de système d'exploitation, Skype for Business Server fonctionne de Windows Server 2008 R2 à Windows Server 2012 R2. Cependant, Microsoft recommande de déployer Skype for Business Server sur Windows Server 2012 ou Windows Server 2012 R2 car ces deux versions peuvent bénéficier de Windows Fabric v3 tandis que Windows Server 2008 R2 ne dispose que de Windows Fabric v2. Même si la v2 est supportée, il est plus que probable que Microsoft concentre ses efforts d'optimisation de Windows Fabric en v3.


Processus de mise à jour

Voici les étapes principales du processus de mise à jour d'un pool :

  1. Installer les prérequis : sans les lister à ce stade, il s'agit d'avoir le dernier CU de Lync Server 2013 installé, SQL Server 2012 SP1 pour les bases de données, quelques hotfixes...
  2. Mettre à jour et publier la topologie, puis mettre à jour les bases de données à l'aide du Topology Builder : il s'agit d'aller dans le Topology Builder, choisir le pool Lync Server 2013 à mettre à jour pour qu'il se retrouve dans la catégorie "Skype for Business Server 2015" et de publier la topologie qui va se charger de mettre à jour les bases de données du pool.
  3. Stopper les services sur tous les serveurs du pool à mettre à jour.
  4. Lancer le Setup pour qu'il exécute la mise à jour : le Setup de Skype for Business Server 2015 va détecter que le serveur doit être mis à jour vers Skype for Business Server 2015 grâce aux informations de la topologie publiée et va se charger de désinstaller les binaires Lync Server 2013 pour installer ensuite ceux de Skype for Business Server 2015. De plus, grâce à un mécanisme nommé Smart Setup par Microsoft, le Setup va vérifier auprès de Microsoft Update s'il existe des mises à jour de Skype for Business Server qui seront le cas échéant déployées en même temps que la mise à jour de Lync Server 2013 vers Skype for Business Server 2015.
  5. Démarrer les services sur tous les serveurs du pool en même temps: une nouvelle cmdlet Start-CSPool facilite cette étape.


Avec ces petites étapes toutes simples, il est possible de mettre à jour son infrastructure Lync Server 2013 vers Skype for Business Server 2015.

-- Stefan

Le client Skype for Business est disponible en Preview !

Grande nouvelle : le client Skype for Business est disponible en Preview depuis aujourd'hui. Il est téléchargeable sur https://technet.microsoft.com/en-gb/evalcenter/dn917485. Il s'agit d'une mise à jour du client Lync 2013, il faut donc que ce dernier soit au préalable installé.

La mise à jour est très rapide et bien évidemment elle permet de se connecter à des infrastructures Lync Server 2010, Lync Server 2013, Lync Online et Skype for Business Server.

Il s'agit actuellement d'une version Preview qui expirera le 1er mai 2015, installez-là avec précaution tout de même. Mais une chose intéressante est notée dans les FAQ : la mise à jour officielle de Lync 2013 vers Skype for Business arrivera avec la mise à jour d'Avril !

Bon téléchargement.

-- Stefan

Bienvenue !

Je m'appelle Stefan Plizga.

J'ai œuvré chez Microsoft en tant que Consultant Communications Unifiées pendant 8 années avant de me tourner vers un rôle d'Ingénieur Avant-Vente Office 365 pendant 1 an. J'ai quitté Microsoft fin 2014 pour rejoindre le côté "Client" et adresser de nouveaux challenges.

Cela dit, ce changement ne laisse pas en reste ma passion pour les technologies Microsoft qui gravitent autour d'Office 365, en particulier Exchange Server et Lync Server. Au cours de mon rôle de Consultant chez Microsoft, j'ai développé un fort niveau de compétences autour d'OCS et Lync Server, en témoignent d'ailleurs les certifications MCM (Microsoft Certified Master) sur OCS 2007 R2 et Lync Server 2010 et MCSM (Microsoft Certified Solutions Master) Communications.

Je compte donc faire profiter mes lecteurs de mon expérience acquise depuis Office Communications Server 2007 et je profite de l'arrivée de Skype for Business pour démarrer ce blog.

Bonne lecture.

-- Stefan