Le problème

Si vous demandez aujourd’hui à un utilisateur de SCOM quelles sont les plus grandes faiblesses du produit, grandes sont les chances qu’il vous cite au minimum la difficulté de créer des Management Packs avancés ainsi que la lourdeur et le manque d’ergonomie de l’interface utilisateur.

Cette dernière est en effet universellement connue pour être lente (même en ayant réalisé toutes les optimisations possibles) et pour offrir une navigation peu intuitive et assez datée, y compris dans les versions les plus récentes du produit.

En découlent donc une frustration et un manque d’efficacité pour les opérateurs de supervision et la quasi impossibilité de faire adopter le produit aux utilisateurs indirects qui pourraient pourtant en bénéficier : les autres membres des services informatiques préfèrent demander à l’opérateur de chercher les données dont ils ont besoin, et les responsables des applications métier n’ont pas de réelle solution pour bénéficier de dashboards synthétiques qui leur permettraient d’obtenir une vision rapide de l’état de santé de leur application.

Les solutions

Bien sûr, Microsoft tente depuis déjà de nombreuses versions d’améliorer ces points avec différentes propositions de dashboards censés développer les capacités de présentation du produit (plugin Visio, Widgets dans SCOM 2012, dashboards de la console web HTML 5 depuis la version 1801), mais le résultat de ces efforts est toujours resté très en deca des espérances des utilisateurs.

C’est pourquoi différents éditeurs tiers ont tenté d’apporter une meilleure réponse à ce besoin : historiquement, Savision LiveMaps puis plus récemment SquaredUp. C’est à ce dernier arrivé que nous nous intéressons aujourd’hui, car j’ai eu l’opportunité de le redéployer récemment pour un de mes clients.

A quoi ca ressemble ?

Trêve de bavardage, attaquons le sujet par son aspect le plus important : son apparence.

L’interface du produit est des plus moderne, en HTML5 entièrement responsif aussi efficace sur une TV que sur un smartphone et très épurée et efficace.

Chaque dashboard est constitué d’une série de tuiles, chacune contenant un widget parmi les différents types et formats disponibles (alertes, performance, état ;D sous forme de liste, de donut…) et ainsi présenter les informations pertinentes aux différente populations d’utilisateurs :

Décisionnel, avec l’affichage instantané de la disponibilité des SLA de toutes les applications métier :

Infrastructure, avec les indicateurs les plus importants pour une technologie donnée (ici pour SQL) :

Ou encore métier, avec les indicateurs clés de tous les systèmes qui composent un applicatif :

Comment ca marche ?

Très simplement ! L’installation ne prend que quelques minutes et est quasi entièrement automatisée. Le seul composant nécessaire est IIS, l’installeur se charge de son déploiement s’il n’est pas présent sur le serveur et il est parfaitement possible d’installer SquaredUp dans un IIS existant (par exemple sur un serveur hébergeant le role Console Web de SCOM).

La configuration ne nécessite ensuite qu’un accès à la base Datawarehouse de SCOM, aucune base additionnelle n’est nécessaire. Toutes les données affichées proviennent de cette base.

Comme quoi il est possible d’avoir un affichage rapide et efficace sans aucune modification des données ou de leur structure… Microsoft devrait en prendre de la graine !

La construction des dashboards se fait ensuite entièrement graphiquement, directement dans la console web. Ils sont en réalités construits en JSON, qu’il est possible de modifier manuellement au besoin.

C’est tout ?

Différentes éditions existent, et les plus avancées disposent d’options intéressantes : intégrer des données provenant d’une base SQL externe, d’une requête dans Log Analytics ou du résultat de la requête d’une API REST…

Le produit dispose même d’un module nommé VADA qui permet la construction accélérée d’Applications Distribuées complexes, en détectant automatiquement les connexions TCP entre les différentes couches applicatives (load balancer vers frontal web vers backed vers base de données vers…) à l’aide de netstat exécuté en direct !

Cela ne remplace pas une application distribuée construite à l’aide de découvertes dynamiques par un développeur SCOM chevronné, mais c’est incontestablement plus rapide et pratique que la construction visuelle classique.

Ca doit être cher !

Je vous laisserai seul juge de ce point, mais il faut au moins reconnaitre que SquaredUp joue carte sur table en affichant publiquement ses tarifs, ce qui est excessivement rare dans le monde des extensions pour SCOM (plugins et Management Packs d’éditeurs tiers) :

A noter également la disponibilité d’une version d’essai au long cours « COVID19 » : 1 mois de fonctionnalités complètes (édition EAM) avec utilisateurs illimités, puis 6 mois d’édition spéciale avec 1 seul utilisateur nommé mais un nombre de dashboards OpenAccess (non cliquables) illimités. L’occasion parfait de tester le produit !

Des points négatifs ?

Oui, évidemment, il y en a.

SquaredUp n’a rien d’une solution magique : il ne fait qu’afficher de façon ergonomique et efficace les données collectées par SCOM.

Si votre SCOM est laissé à l’abandon depuis des années, mal ou pas tuné… vous aurez les plus grandes difficultés à obtenir un affichage pertinent. A noter que SquaredUp propose via sa société sœur Cookdown un produit tiers gratuit nommé EasyTune pour aider à résoudre ce point.

La construction des dashboard est parfois trop simple, au point que l’on se prend à regretter l’absence de certaines capacités qui nous semblent pourtant évidentes.

La documentation est claire mais pas toujours suffisamment détaillée.

Le support est par contre toujours très disponible pour vous débloquer et ouvert aux suggestions d’amélioration.

Conclusion

Selon moi, SquaredUp devrait être au minimum étudié dans le cadre de tous les déploiements SCOM. Il permet d’apporter à SCOM un point qui lui manque cruellement : la facilité d’accès, en particulier aux utilisateurs non techniques.

Une supervision ne sert à rien si personne ne se sert des données qui en sont issues, et SquaredUp fournit une réponse pertinente à ce manque flagrant dans le produit de base.

Dans Azure Stack, l’établissement d’une connexion au PEP (Privileged EndPoint), appelé également VM ERC (Emergency Recovery Console), est nécessaire pour mener certaines opérations de test de l’environnement (Test-AzureStack préalable à une mise à jour) ou pour déployer certaines ressources (Resource Providers…).

La mise à jour 1910 d’Azure Stack introduit deux nouveaux cmdlet Powershell accessibles depuis le PEP : Get et Set-AzsDnsForwarder.

Malheureusement, il semble que ce module n’apprécie pas beaucoup d’être chargé depuis un ordinateur exécutant un système non-anglais puisque l’ouverture de la sessions PEP ne fonctionne plus non plus depuis cette mise à jour, avec un message d’erreur laissant entendre l’impossibilité d’ouvrir la version francaise du module AzureStack DNS :

Cannot find the Windows Powershell data file « Microsoft.AzureStack.DNS.psd1 » in directory « C:\Program Files\WindowsPowerShell\Modules\Microsoft.AzureStack.DNS\fr-FR », or in any parent culture directories

Les VM ERC sont assez lourdement verrouillées, et il est impossible d’aller corriger l’installation de ce module.

Il est par contre possible de forcer une Culture différente lors de l’ouverture de la Remote-PSSession à l’aide du paramètre SessionOption :

New-PSSession -ComputerName $IP -ConfigurationName PrivilegedEndpoint -Credential $AzureCredential -SessionOption (New-PSSessionOption -UICulture en-US)

Voilà qui devrait suffire à contourner le problème en attendant que Microsoft apporte une correction plus définitive !

Le Resource Provider App Service d’Azure Stack nécessite l’utilisation de certificats, qui devront donc être remplacés avant d’arriver à expiration ou en cas de compromission. Notez d’ailleurs qu’aucune alerte n’est présente dans le portail pour prévenir de leur expiration…

Bien que cette opération doive par définition être effectuée assez régulièrement, elle n’est curieusement pas documentée sur Technet.

Heureusement, elle est très simple !

Ouvrez la blade App Service dans le portail d’administration, puis dans le menu Secrets, cliquez sur Rotate dans la partie Certificates :

Sélectionnez ensuite les fichiers .pfx des certificats renouvelés et entrez leurs mots de passe :

Une fois tous les champs remplis, cliquez sur OK.

La procédure de rotation débute alors. Il est possible de suivre sa progression en cliquant sur le bouton Status :

Après environ 20 minutes, la procédure est terminée :

A noter : aucune interruption de service n’a été constatée pendant le déroulement de la rotation du certificat (avec un Resource Provider déployé en haute disponibilité)

Quelques temps après avoir déployé le Resource Provider App Service dans notre environnement Azure Stack, j’ai eu la mauvaise surprise de constater qu’il ne se chargeait plus et qu’il n’était plus possible de créer de nouvelles Web App :

Could not validate app name

Ni d'accéder aux propriétés de celles déjà créées :

La console de debug du navigateur (touche F12) permet d’observer un grand nombre d'erreurs 500 pour des requêtes vers https://management.<location>.<domaine> et vers https://api.appservice.<location>.<domaine> :

Dans le portail d’administration, le dashboard app service ne se charge plus non plus, et le message d’erreur donne un premier indice sur la cause du dysfonctionnement :

Failed to load App Service extension. Please check whether App Service resource provider and database is up and running

Allons donc voir du côté des VM « contrôleur » (CN0 et CN1) de l’environnement du Resource Provider. Il y est possible de s’y connecter en RDP à condition d’autoriser le port 3389 dans leur NSG.

Ces VM contiennent une console MMC Web Cloud Management (son raccourci se trouve sur le bureau) qui permet la gestion de tous les composants du RP (Front End, Workers…) et pourrait donc nous en apprendre plus, mais elle plante lors de son ouverture :

The Resource Metering Service has experienced an unhandled exception. Exception: 'Microsoft.Web.Hosting.WebHostingException: Login failed for user 'appservice_metering_Common'. ---> System.Data.SqlClient.SqlException: Login failed for user 'appservice_metering_Common'.)

Ce nouveau message d’erreur sembler confirmer un problème du côté de la base de données.

Cette dernière est hébergée sur un cluster Always On qui fait partie de l’environnement « backend » du Resource Provider : il a été déployé séparément, en utilisant le template « haute disponiblité » de référence Microsoft.

Il est possible de se connecter en RDP à un des nœud du cluster (aps-sql-0 ou 1) à partir d’une des VM « contrôleur » CN-VM sans modifier les règles NSG, à l’aide du compte admin du domaine utilisé pour déployer l’environnement backend.

Une fois connecté, on peut ouvrir SQL Management Studio sur les deux instances :

On constate alors qu'une seule des instance dispose des bases de données nécessaires au fonctionnement du Resource Provider.

La raison en est simple : c'est parce que le template de déploiement du backend fourni par Microsoft ne configure pas automatiquement l'availability group always on. C'est d'ailleurs rappelé dans les release notes du Resource provider, il faut le configurer manuellement… mais il est facile de manquer ce détail, et la procédure n’est pas détaillée.

Commençons donc par sauvegarder les bases, puis identifions le serveur qui est configuré comme « Primary » dans l’Availability Group Always On :

La procédure d’ajout des bases ne peut être réalisée que sur le nœud « primary », mais il doit aussi être celui qui possède les bases; ce n’est pas le cas ici (les bases sont sur le nœud « secondary », il faut donc commencer par réaliser un failover de l'availability group.

Nous pouvons ensuite y rajouter les bases :

Faites un clic-droit sur Availability Databases puis sélectionnez Add Database.

Cochez les bases à ajouter :

Cliquez sur connect pour ouvrir la connexion vers l'autre noeud

Sélectionnez une synchronisation « Full » puis terminez l’assistant.

Les bases sont très petites et la synchronisation est donc quasi-instantanée.

Une fois terminée, la MMC Web Cloud doit maintenant se lancer sans erreur et le Resource Provider est à nouveau fonctionnel!

Dans SCOM, les découvertes basées sur une clé de registre sont les plus communes. Il existe des dizaines de guides et tutoriaux qui détaillent la marche à suivre, je ne reviendrai donc pas sur les fondamentaux mais je me contenterai du rappel suivant : comme le montre l’extrait de code suivant, cette découverte nécessite la définition du chemin de la clé de registre à récupérer et il est possible de définir différents PathTypes et AttributeTypes :

<RegistryAttributeDefinition>

<AttributeName>##UniqueID##RegValueData</AttributeName>

<Path>##RegValuePath##</Path>

<PathType>1</PathType> <!-- 0=RegKey 1=RegValue -->

<AttributeType>2</AttributeType> <!-- 0=CheckIfExists (Boolean) 1=treat data as (String) 2=treat data as (Integer) -->

</RegistryAttributeDefinition>

PathType permet de préciser s’il faut récupérer un Clé ou une Valeur, et AttributeType permet de de préciser si le module doit se contenter de vérifier l’existence de l’entrée, de récupérer sa valeur sous forme de String (chaine de caractères) ou de la récupérer sous forme d’Integer (entier numérique).

Jusqu’ici, rien de bien particulier pour qui est habitué à travailler avec ces découvertes…

Un cas particulier s’est cependant présenté il y a quelques semaines : une application dont le numéro de version était stocké dans la valeur « Default Value » :

S’il s’agit manifestement d’une valeur plus que d’une clé, elle ne possède pas de nom… comment faire alors pour indiquer son chemin ?

Faut-il indiquer le chemin de la clé parente mais préciser PathType = 1 comme s’il s’agissait d’une valeur ?

Ou bien indiquer le chemin SOFTWARE\Appli\(Default) ?

Un très ancien article du blog de Marius Sutra (https://blogs.msdn.microsoft.com/mariussutara/2008/02/28/howto-registry-attribute-definition-explained/) indique qu’un PathType = 2 existerait pour ce cas précis, mais les tests ne sont pas concluants et aucune autre trace de cette possibilité ne semble exister, même pas dans la définition de la probe Registry sur MSDN.

Après quelques essais infructueux, la bonne réponse a finalement été trouvée directement par le client avec qui je travaillais :

Il suffit en réalité d’indiquer le chemin sous la forme SOFTWARE\Appli\\ (avec deux antislash à la fin, donc), et de conserver le PathType = 1

Encore une astuce à conserver dans un coin… Merci Jérémie !

L’utilisation d’Azure et d’outils qui s’appuient dessus (tels que Storage Explorer, Azure Migrate, Azure CLI, Visual Studio et VS Code…) est devenue presque banale et quotidienne pour beaucoup d’entre nous.

Cependant, dans un environnement d’entreprise, un problème récurrent se présente : la connexion d’un de ces outils à Azure échoue avec un message indiquant un certificat racine incorrect ou autosigné ; comme par exemple ici « Self-signed certificate in certificate chain » :

Une vérification dans les journal d’événement CAPI2 de la machine où s’exécute l’outil devrait permettre d’identifier quel certificat empêche la connexion et, bien souvent il s’agit du proxy d’entreprise qui fonctionne en mode « transparent », interceptant ainsi tous les flux sortants.

Deux solutions sont alors possibles : demander à l’administrateur du proxy de mettre en liste d’exclusion les flux nécessaires à l’application, ou récupérer le certificat racine du proxy afin de l’intégrer au magasin des autorités de confiance de votre machine ou dans les certificats de confiance de l’application, si elle le supporte (c’est le cas pour Storage Explorer).

C’est bien entendu le second cas qui nous intéresse ici. Pour récupérer le certificat, il est nécessaire de passer par l’outil OpenSSL qui n’est pas présent nativement sous Windows. Fort heureusement, il est possible de télécharger des binaires déjà compilées et de les exécuter directement depuis l’invite de commande : https://sourceforge.net/projects/openssl/

Une fois l’archive téléchargée et décompressée, la commande suivante permet de récupérer la chaine de certificats réellement reçus par le système lors d’une requête HTTPS :

s_client –showcerts –connect urldeconnexionauservice.test.com:443

On retrouve ici l’erreur « self signed certificate in certificate chain » ainsi que les certificats présents, inclus entre les lignes ----BEGIN CERTIFICATE---- et ----END CERTIFICATE---- :

Il ne reste plus qu’à copier cette chaine de caractères dans un fichier texte, à renommer ce fichier avec une extension .cer et à l’importer dans l’outil ou directement dans le magasin Windows des autorités de certification approuvées.

Bien que cela n’arrive pas souvent, il peut se révéler nécessaire d’extraire l’intégralité des variables dans Orchestrator ainsi que leurs valeurs, par exemple dans le cadre de la migration vers un autre outil d’ordonnancement.

Malheureusement, nativement cette extraction n’est possible qu’au format d’export Orchestrator, difficilement lisible.

L’outil communauté « Parse Orchestrator Export Tool » permet d’obtenir une version plus lisible de cet export, mais il ne permet malheureusement aucune sortie dans un format « universel » tels que des tableaux CSV ou Excel.

Nous allons donc nous appuyer directement sur la base de données SQL d’Orchestrator pour obtenir les valeurs qui nous intéressent :

with VariablePath as

(

select 'Variables\' + cast(name as varchar(max)) as [path], uniqueid

from dbo.folders b

where b.ParentID='00000000-0000-0000-0000-000000000005' and disabled = 0 and deleted= 0

union all

select cast(c.[path] + '\' + cast(b.name as varchar(max)) as varchar(max)), b.uniqueid from dbo.FOLDERS b

inner join

VariablePath c on b.ParentID = c.UniqueID

where b.Disabled = 0 and b.Deleted = 0

)

select O.Name,V.Value,VP.[Path]

from dbo.objects AS O

INNER JOIN VariablePath AS VP ON VP.UniqueID = O.ParentID

INNER JOIN Variables AS V ON V.UniqueID = O.UniqueID

Cette requête retourne le nom, la valeur et l’arborescence de la variable :

Notez cependant que la valeur des variables chiffrées (mots de passe…) reste illisible, puisqu’elles ne sont pas disponibles en texte clair dans la base.

Bref rappel : Azure DNS est un service PaaS qui propose d’héberger vos zones DNS sans que vous n’ayez besoin de vous préoccuper de la gestion de l’infrastructure sous-jacente.

De plus, comme tout service « cloud », il est possible de gérer ces zones et leurs entrées à l’aide d’une API REST, ce qui apporte une flexibilité certaine face au fonctionnement encore un peu archaïque du service Windows DNS dont la gestion passe nécessairement par la MMC DNS ou par Powershell, voire par l’utilisation de dnscmd.exe pour ceux d’entre vous qui lisent cet article en 1992.

Microsoft a introduit il y a quelques mois un type de zone « Private » à ce service, permettant ainsi d’héberger des zones qui ne seraient pas résolvables depuis l’extérieur de votre environnement ; mais ce mode souffrait de lacunes sérieuses, qui le rendaient inexploitable dans un contexte réel :

• Il n’était disponible qu’en Powershell
• Seules les requêtes provenant d’un unique VNet avaient le droit de créer des entrées dans une zone donnée
• Seuls 10 VNet avaient le droit de lire les entrées d’une zone donnée
• Ces VNet devaient être déclarés manuellement
• Ces VNet ne devaient contenir aucune ressource au moment de leur déclaration (!!)
• Les enregistrements étaient invisibles via powershell ou l’API REST, mais étaient bel et bien resolvables
• … etc.

Une mise à jour majeure est apparue la semaine dernière, et elle corrige la majorité de ces défauts :

• On peut désormais créer les zones privées directement dans le portail Azure
• On peut lier jusqu’à 1000 VNet à une zone privée, même si ces VNet contiennent déjà des ressources ; et les notions de VNet « enregistreur » ou « requêteur » disparaissent
• On peut désormais accéder aux enregistrements via l’API ou Powershell

Bref, on peut maintenant raisonnablement utiliser ce service dans un environnement réel… mais attention tout de même, il est toujours en Public Preview et susceptible d’évoluer n’importe quand !

Notez également que la résolution dans une zone Private DNS ne fonctionne par défaut que si votre VNet est configuré pour utiliser la résolution DNS native d’Azure.

Si vous utilisez une résolution « Custom » (un contrôleur de domaine déployé dans votre tenant par exemple), il faudra créer un conditional forwarder pour votre zone Private DNS, pointant vers l’IP d’Azure DNS (unique pour tous les tenant et toutes les régions) : 168.63.129.16

Enfin, comme la résolution dans une zone Private DNS n’est possible que depuis un VNet, il faudra également prévoir un forwarder différent sur les serveurs DNS de votre Lan si vous souhaitez pouvoir résoudre depuis cet emplacement !

L’occasion idéale pour mettre en place une partition DNS à réplication limitée…

Les partitions DNS intégrées à Active Directory, permettant ainsi leur réplication et leur gestion sur tous les contrôleurs de domaine disposant du rôle DNS, sont depuis longtemps la norme dans un environnement Windows.

Il existe cependant une possibilité moins connue de ce mécanisme : la partition DNS « custom », qui permet de définir un scope de réplication limité à seulement un ou quelques contrôleurs de domaine de votre choix.

J’ai eu recours à cette possibilité afin de résoudre un problème lié à l’utilisation de Conditional Forwarders que vous pourriez bien rencontrer dans votre propre environnement sans même le savoir : les Conditional Fowarders sont répliqués dans toute votre forêt de la même façon que les zones DNS « classiques » (foward et reverse), mais si vous en utilisez il est fort possible que seuls certains de vos contrôleurs de domaine soient réellement en mesure de les atteindre en raison de contraintes réseaux propres à votre environnement.

Il devient alors nécessaire de limiter la réplication de ces Conditional Forwarders aux seuls serveurs DNS qui y ont accès !

La création d’une partition DNS se fait uniquement en powershell (en tant qu’administrateur) :

Add-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition"

Il est ensuite nécessaire d’y ajouter les contrôleurs de domaine qui répliqueront cette partition :

Register-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition" -ComputerName "DC01.cogip.com"

Répétez cette opération pour chaque contrôleur pour lequel vous souhaitez activer la réplication sans trop prêter attention aux possibles erreurs que vous pourriez obtenir : ca marche quand même (… normalement !) ; puis vérifiez justement que les serveurs sont bien ajoutés à la zone :

Get-DnsServerDirectoryPartition -Name "ConditionalForwardersPartition"

Il est désormais possible de créer ou de déplacer un conditional forwarder dans cette partition, simplement à l’aide de la MMC DNS :

Attention : dans le cas du déplacement d’un forwarder existant déjà, assurez -vous qu’il n’est pas protégé contre la suppression ! Si c’est le cas, le déplacement échouera avec un message peu explicite, et toutes les tentatives successives échoueront également même si vous retirez la protection entre temps ! La seule solution sera ici d’utiliser ADSI Edit pour aller faire le ménage dans la partition DC=ConditionalForwardersPartition …

La création d’un conteneur Blob dans un compte Azure Storage est une opération devenue plutôt banale, mais qui peut toutefois encore donner lieu à des messages d’erreur assez cryptiques :

Failed to create blob container.

Details : This request is not authorized to perform this operation.

Le message d’erreur pourrait laisser penser à un manque de droits, mais l’utilisateur dispose bien de permissions suffisantes dans ce Storage Account.

Par contre, dans le cas qui nous intéresse ici, le filtrage par adresse IP est activé sur le Storage Account utilisé, et la VM qui tente d’accéder au Storage Account est déployée dans un tenant Azure différent ; le filtrage est donc réalisé à l’aide de l’IP publique de la VM :

Or, les connexions entrantes dans le storage account sont s-natées à l’intérieur d’un même Datacenter Azure, comme indiqué ici : https://github.com/MicrosoftDocs/azure-docs/issues/10359 . Ce n’est donc pas l’IP publique de la VM qui se présente en entrée du Storage Account, et cela explique le blocage rencontré…

Deux solutions sont toutefois disponibles :

• Déployer le Storage Account dans une région Azure différente de celle de la VM : ca sera alors bien l’IP publique de cette dernière qui se présentera en entrée du Storage Account
• Utiliser le filtrage par VNET à la place du filtrage par IP. Cette solution reste possible même si le VNET de la VM est dans un tenant différent de celui du Storage Account, mais il faudra que l’utilisateur qui réalise la configuration dispose de permissions spécifiques sur le VNET de la VM : https://docs.microsoft.com/en-us/azure/storage/common/storage-network-security#grant-access-from-a-virtual-network