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