PI Services

Le blog des collaborateurs de PI Services

SCOM - Du rififi dans la console Web

Une des principales nouveautés introduites lors du passage de SCOM au mode Semi-Annuel (SAC, versions 1801 et ultérieures) est la refonte complète de la console Web, intégralement en HTML5.

Malheureusement, cette innovation ne s’est pas faite sans quelques regrettables accrocs, aussi bien lors de son installation que lors de son utilisation quotidienne.

Concernant l’installation, les utilisateurs forums technet et uservoice font état de problèmes récurrents, mais néanmoins assez aléatoires puisque deux serveurs installés par la même personne, le même jour, sur des VM identiques peuvent ne pas présenter les même problèmes :

  • L’option « Enable SSL » lors de l’installation n’active pas SSL dans les paramètres de IIS
  • Si SSL est activé dans IIS avant l’installation de SCOM et que « Enable SSL » est coché pendant l’installation, la console web n’est pas accessible en utilisant « use windows credential », mais elle l’est en réentrant les credentials manuellement
  • Si SSL est activé dans IIS avant l’installation de SCOM et que « Enable SSL » n’est pas coché pendant l’installation, la console web est accessible aussi bien en HTTP qu’en HTTPS
  • L’authentification ne fonctionne pas directement, il est nécessaire de réentrer ses credentials à moins de modifier l’ordre des providers d’authentification dans IIS afin de mettre NTLM en premier à la place de Negotiate.

 

Par ailleurs, une partie du contenu tel que les Dashboards, les vues Event… créés dans les versions précédentes de SCOM n’est plus accessible dans la nouvelle console Web.

« Heureusement », il est toujours possible d’accéder à l’ancienne console Web silverlight à l’adresse suivante : http://nomduserveur/Dashboard

De la même facon, les liens directs vers des alertes renvoient systématiquement vers la page d’accueil de la console web…

Bref, il reste encore du travail mais à n’en pas douter, la console web finira par remplacer la console lourde…. Un jour.

SCOM – Contournements du bug APM

Si vous gérez au quotidien un environnement SCOM, ou si vous suivez un tant soit peu l’actualité de cet outil, vous avez forcément déjà entendu parler du bug APM : depuis la sortie de SCOM 2016, lors du déploiement de l’agent, le module APM (application monitoring) est susceptible de provoquer le plantage de certains webservices hébergés dans IIS, même lorsque la fonctionnalité APM est désactivée.

Cela peut évidemment avoir un impact conséquent lorsqu’il s’agit de webservices utilisés pour une application critique en production…

Jusqu’ici (et donc depuis presque 3 ans…), Microsoft s’est contenté d’indiquer avoir constaté le problème et l’avoir corrigé « en partie » au fil des mises à jour de SCOM 2016. Cette « partie » est manifestement insuffisante, puisque le problème persiste et oblige à la plus grande vigilance lors du déploiement d’un nouvel agent puisque seule l’installation manuelle avec l’option NOAPM=1 permet de se prémunir à coup sûr du problème.

Avec la sortie de SCOM 1807, Microsoft propose enfin un contournement industrialisable à défaut d’une correction : le changelog indique en effet qu’il est désormais possible de pousser l’agent sans le module APM, que ca soit via la console ou via powershell :

 

Install-SCOMAgent -DNSHostName “nomduserveur.local” -PrimaryManagementServer $PrimaryMS –NoAPM

 

Un second contournement est proposé sur certains blogs ( par exemple https://blogs.technet.microsoft.com/hybridcloud360/2018/06/29/scom-and-apm-the-simplest-workaround/ qui fournit de nombreux détails) :

Il semble en effet que cela ne soit pas le module APM de SCOM 2016 en lui-même qui pose problème, mais plutôt l’ajout du paramètre EnableRTIA Profiler à la règle Apply APM Agent configuration  contenue dans le Management Pack Microsoft.SystemCenter.Apm.Infrastructure ; ce qui explique d’ailleurs que le problème se produise également sur les serveurs disposant toujours d’un agent SCOM 2012 R2 lorsque le reste de l’environnement SCOM a été mis à jour en version 2016 ou ultérieure.

Il suffit donc d’overrider cette règle pour passer le paramètre EnableRTIA Profiler à False, et le problème disparait !

Prenez cependant bien le temps de tester ceci dans votre environnement, il est tout à fait possible qu’il ne s’agisse là encore que d’un contournement partiel…

SCOM - Déplacer le rôle Reporting

Lors du déplacement du rôle Reporting vers un nouveau serveur SSRS pour le compte d’un client, je me suis heurté à quelques problèmes et interrogations pour lesquelles les réponses n’étaient pas toujours très claires ou accessibles.

On retrouve par exemple un certain nombre de billets de blogs ou de posts sur les forums technet qui indiquent qu’il n’est pas possible de déplacer la base de données utilisée par SSRS, et donc pas possible de conserver facilement tous les rapports personnalisés et planifiés.
Il est en réalité parfaitement possible de procéder à une nouvelle installation de SCOM Reporting Services sur un SSRS vierge puis de restaurer la base du précédent SSRS, à condition de bien réaliser les opérations dans cet ordre :

  • Sur l’ancien serveur de reporting, sauvegarder les bases ReportServer et ReportServerTempDb (noms par défaut) ainsi que la clé de chiffrement de SSRS et le fichier config
  • Installer SSRS sur le nouveau serveur
  • Installer le rôle SCOM Reporting sur le serveur
  • Restaurer les bases ReportServer et ReportServerTempDb ainsi que la clé de chiffrement
  • Reconnecter SSRS aux bases restaurées
  • Reprendre les paramètres dans web.config

 

Un nouveau problème peut survenir dans la foulée : si le serveur SSRS d’origine exécutait une licence supérieure de SSRS (par exemple Datacenter alors que le nouveau serveur SSRS ne dispose que d’une licence Standard), un message d’erreur vous accueillera lorsque vous tenterez de vous connecter au portail :

 

La solution la plus logique serait de supprimer toute référence à l’ancien serveur dans l’onglet Scale-Out de la console SSRS, mais malheureusement cela ne fonctionne pas.

Il est alors nécessaire de passer directement par l’édition de la table dbo.Keys dans la base ReportServer pour en retirer toute référence à l’ancien serveur en supprimant la ligne correspondante :

DELETE FROM [ReportServer].[dbo].[Keys]

WHERE MachineName = 'AncienServeur'

Redémarrez ensuite SSRS, et confirmez que le portail fonctionne maintenant bien et que vous pouvez y retrouver toutes vos personnalisations antérieures !