PI Services

Le blog des collaborateurs de PI Services

SCOM – MP Powershell par SquaredUp

Tous les admins SCOM vous le diront : créer des nouvelles règles dans la console classique peut s’avérer terriblement frustrant, en particulier par son manque de flexibilité et de liberté.

Un exemple particulièrement récurrent est l’impossibilité d’utiliser autre chose que le Visual Basic pour créer des règles ou moniteurs scriptés, alors qu’il est parfaitement possible d’utiliser Powershell en passant par des outils tiers (MP Author de Silect, voire VisualStudio).

Une première tentative de simplifier les choses avait été réalisée par Wei Lim, avec un management pack qui apportait un wizard permettant la création de moniteurs en powershell directement dans la console SCOM : https://blogs.msdn.microsoft.com/wei_out_there_with_system_center/2015/07/09/opsmgr-new-sample-wizard-to-create-powershell-monitors-in-the-ops-console/

Cela restait cependant assez limité, il n’était par exemple pas possible de passer de paramètres aux scripts au début (ce qui fut corrigé dans une release ultérieure) et seule la création de moniteurs à 2 états était possible.

Depuis peu, SquaredUp (société bien connue pour son excellente console web éponyme, nous en reparlerons surement un jour) propose également un management pack gratuit, qui apporte enfin à la console SCOM les fonctionnalités que nous étions en droit d’attendre : création de moniteurs à 2 et 3 états, de tous types de règles, de tâches… en powershell, à l’aide de wizards fort bien concus !

clip_image002

clip_image004

Le Management Pack est disponible ici : https://squaredup.com/free-powershell-management-pack/

Agent SCOM 2012 R2 UR12 (et ultérieur) sur Windows 2003

Lors de la finalisation d’une migration side by side SCOM 2007 vers SCOM 2012 R2, j’ai rencontré un problème assez inattendu : il ne restait alors plus que quelques agents Windows 2003 à déployer et quelques autres à mettre à jour avec le dernier UR, et je n’anticipais pas de problème particulier dans cette phase déjà réalisée à maintes reprises sur d’autres serveurs de cet environnement ainsi que sur d’autres environnements.

J’ai donc eu la mauvaise surprise de constater que ces agents s’arrêtaient dès leur démarrage, parfois sans aucun message d’erreur (arrêt « propre » matérialisé par les événements 103 puis 101), parfois avec un message d’erreur assez peu parlant (événement 1000 après l’événement 103) :

clip_image001

clip_image002

Faulting application healthservice.exe, version 7.1.10292.0, stamp 585161d0, faulting module unknown, version 0.0.0.0, stamp 00000000, debug ? 0, fault address 0x000c9ba0.

J’ai alors décidé de prendre une trace de l’agent, afin d’obtenir un diagnostic plus poussé (cf. https://blog.piservices.fr/post/2017/09/30/SCOM-Prendre-une-trace-de-lagent1).

Fort heureusement le problème était très simple à reproduire (un simple démarrage de l’agent…), et m’a permis d’obtenir l’erreur suivante :

clip_image004

Unable to create self-signed certificate : -2146893816(NTE_BAD_ALGID).

L’agent échoue donc à créer un certificat auto-signé lors de son démarrage, et plante dans la foulée.

Mais pourquoi chercherait-il à générer un certificat ? Comme le précise Stefan Roth dans cet article très détaillé (https://stefanroth.net/2016/03/02/scom-how-data-is-encrypted/), ce certificat est utilisé lorsque le Management Server transmet un RunAs Account à un agent afin d’apporter un niveau de chiffrement supplémentaire.

Ce certificat est donc créé lors du premier démarrage de l’agent, ainsi que lorsqu’il expire (sa durée de vie est d’un an) :

clip_image006

Nous constatons sur la capture ci-dessus que le certificat est bel et bien présent dans le magasin.

Pourquoi l’agent cherche-t-il a le régénérer, et pourquoi échoue-t-il ?

La réponse à la première question se trouve (de façon assez peu claire il est vrai) dans les release notes de l’UR12 de SCOM 2012 R2 :

  • SHA2 support for certificates:  SHA1 is deprecated for the System Center 2012 R2 Operations Manager Agent and SHA2 is now supported.

Autrement dit, le certificat auto-signé de l’agent est maintenant signé avec l��algorithme SHA2 (SHA256RSA) et non plus avec SHA1.

Tant mieux pour la sécurité, SHA1 est aujourd’hui considéré comme déprécié et ne devrait plus être utilisé.

La réponse à la seconde question se trouve encore une fois chez Microsoft : Windows 2003 (et par extension Windows XP) ne supporte pas les algorithmes de la famille SHA2 sans un hotfix qui n’a jamais été intégré aux mises à jour régulières, comme l’indique la KB suivante : http://support.microsoft.com/kb/938397

Une fois le hotfix installé et le serveur redémarré, on constate que l’agent démarre sans encombre et qu’un certificat signé en SHA256 est généré :

clip_image008

Et voilà, problème réglé !

SCOM – Prendre une trace de l’agent

Il peut arriver qu’un agent SCOM rencontre un problème (plantage, supervision qui échoue…) sans raison identifiable dans les journaux d’événement.

Dans ce cas, il reste une dernière solution : prendre une trace de debug.

Les outils le permettant sont disponibles nativement sur tous les serveurs où l’agent est installé.

Préparation

Dans un premier temps, il est nécessaire de se connecter au serveur où se trouve l’agent pour lequel vous souhaitez réaliser une trace puis localisez le dossier d’installation de l’agent, normalement C:\Program Files\System Center Operations Manager\Agent\Tools pour un SCOM 2012 ou C:\Program Files\Microsoft Monitoring Agent\Agent\Tools pour un SCOM 2012 R2.

Ouvrez une ligne de commande cmd.exe en mode administrateur, puis rendez vous dans le dossier en question et exécutez la commande StopTracing.cmd afin de vous assurer que toutes les traces préalables sont bien arrêtées.

clip_image002

Profitez-en pour relever le dossier où se trouvent les logs, indiqué à la ligne Log Filename (ici C:\Windows\Logs\OpsMgrTrace ) et supprimez tous les fichiers qu’il contient, afin de faire place nette pour la nouvelle trace à venir.

Prise de la trace

Toujours depuis votre invite de commande, tapez StartTracing.cmd VER (respectez bien les majuscules pour VER) puis attendez que le problème se reproduise ou, mieux, essayez de forcer sa reproduction : plus la trace durera longtemps et plus elle sera longue à traiter et à analyser…

clip_image004

Une fois le problème survenu, arrêtez la trace (toujours avec Stoptracing.cmd).

Traitement et analyse de la trace

Les fichiers ETL de trace sont, à la base, totalement illisibles : il faut donc les convertir en quelque chose que vous puissiez analyser.

Pour ce faire, lancez la commande formattracing.cmd. Elle peut être assez longue à s’exécuter selon la durée de votre trace.

clip_image006

Une fois terminée, vous constaterez que des fichiers .log ont été créés dans le dossier de logs. Ce sont eux que vous allez pouvoir ouvrir pour tenter de comprendre les soucis rencontrés par l’agent.

Mais même s’ils sont lisibles dans un notepad, ils restent assez peu digestes :

clip_image008

Vous pouvez utiliser l’outil CMTrace, issu du toolkit de SCCM ( https://www.microsoft.com/en-us/download/details.aspx?id=50012 ), pour obtenir un résultat un peu plus facilement exploitable :

clip_image010

Ensuite, à vous de jouer et de repérer les lignes avec des erreurs (normalement signalées par une balise [ERROR]) pour identifier l’origine de votre problème.

Agent SCOM 2012 R2 UR12 (et ultérieur) sur Windows 2003

Lors de la finalisation d’une migration side by side SCOM 2007 vers SCOM 2012 R2, j’ai rencontré un problème assez inattendu : il ne restait alors plus que quelques agents Windows 2003 à déployer et quelques autres à mettre à jour avec le dernier UR, et je n’anticipais pas de problème particulier dans cette phase déjà réalisée à maintes reprises sur d’autres serveurs de cet environnement ainsi que sur d’autres environnements.

J’ai donc eu la mauvaise surprise de constater que ces agents s’arrêtaient dès leur démarrage, parfois sans aucun message d’erreur (arrêt « propre » matérialisé par les événements 103 puis 101), parfois avec un message d’erreur assez peu parlant (événement 1000 après l’événement 103) :

clip_image001

clip_image002

Faulting application healthservice.exe, version 7.1.10292.0, stamp 585161d0, faulting module unknown, version 0.0.0.0, stamp 00000000, debug ? 0, fault address 0x000c9ba0.

J’ai alors décidé de prendre une trace de l’agent, afin d’obtenir un diagnostic plus poussé (cf. https://blog.piservices.fr/post/2017/09/30/SCOM-Prendre-une-trace-de-lagent ).

Fort heureusement le problème était très simple à reproduire (un simple démarrage de l’agent…), et m’a permis d’obtenir l’erreur suivante :

clip_image004[5]

Unable to create self-signed certificate : -2146893816(NTE_BAD_ALGID).

L’agent échoue donc à créer un certificat auto-signé lors de son démarrage, et plante dans la foulée.

Mais pourquoi chercherait-il à générer un certificat ? Comme le précise Stefan Roth dans cet article très détaillé (https://stefanroth.net/2016/03/02/scom-how-data-is-encrypted/), ce certificat est utilisé lorsque le Management Server transmet un RunAs Account à un agent afin d’apporter un niveau de chiffrement supplémentaire.

Ce certificat est donc créé lors du premier démarrage de l’agent, ainsi que lorsqu’il expire (sa durée de vie est d’un an) :

clip_image006[5]

Nous constatons sur la capture ci-dessus que le certificat est bel et bien présent dans le magasin.

Pourquoi l’agent cherche-t-il a le régénérer, et pourquoi échoue-t-il ?

La réponse à la première question se trouve (de façon assez peu claire il est vrai) dans les release notes de l’UR12 de SCOM 2012 R2 :

  • SHA2 support for certificates:  SHA1 is deprecated for the System Center 2012 R2 Operations Manager Agent and SHA2 is now supported.

Autrement dit, le certificat auto-signé de l’agent est maintenant signé avec l’algorithme SHA2 (SHA256RSA) et non plus avec SHA1.

Tant mieux pour la sécurité, SHA1 est aujourd’hui considéré comme déprécié et ne devrait plus être utilisé.

La réponse à la seconde question se trouve encore une fois chez Microsoft : Windows 2003 (et par extension Windows XP) ne supporte pas les algorithmes de la famille SHA2 sans un hotfix qui n’a jamais été intégré aux mises à jour régulières, comme l’indique la KB suivante : http://support.microsoft.com/kb/938397

Une fois le hotfix installé et le serveur redémarré, on constate que l’agent démarre sans encombre et qu’un certificat signé en SHA256 est généré :

clip_image008[5]

Et voilà, problème réglé !

SCCM – Le déploiement du client sur un Management Point additionnel échoue

 

Lors du déploiement du client SCCM sur un serveur hébergeant déjà le rôle Management Point, l’installation échoue.

Une analyse du log c:\windows\ccmsetup\logs\ccmsetup.log révèle le message d’erreur suivant :

"MSI: Setup was unable to register the CCM_Service_HostingConfiguration endpoint
The error code is 80041002"

"File C:\Windows\ccmsetup\{72875A95-4007-4DAC-88D8-66366F9A5045}\client.msi installation failed. Error text: ExitCode: 1603
Action: CcmRegisterHostingConfiguration.
ErrorMessages:
Setup was unable to register the CCM_Service_HostingConfiguration endpoint
The error code is 80041002"

Une rapide recherche permet de trouver la KB suivante, qui indique de supprimer le rôle MP, d’installer le client puis de réinstaller le rôle MP : https://support.microsoft.com/en-us/help/2905359/installation-of-the-configuration-manager-client-agent-fails-with-error-code-80041002

Cette solution, bien que fonctionnelle, n’est pas très satisfaisante : d’autres clients SCCM peuvent dépendre de ce serveur MP, qui peut se trouver dans un réseau isolé etc.

Heureusement, une autre solution existe : il faut installer le client via la ligne de commande, en spécifiant manuellement le chemin vers le patch le plus récent disponible, copié manuellement dans un dossier de votre choix au préalable :

C:\SMS\Client\ccmsetup.exe /mp;SERVEURMP.LAN.LOCAL INSTALL="ALL" SMSSITECODE="XXX" CCMHTTPPORT="80" CCMHTTPSPORT="443" CCMHTTPSSTATE="480" FSP="XXX.LAN.LOCAL" CCMFIRSTCERT="1" patch="C:\SMS\Client\configmgr2012ac-sp2r2sp1-kb3100144-x64.msp"

Et le tour est joué !

WSUS – La synchronisation échoue pour un nouveau déploiement

Suite à un nouveau déploiement de WSUS, toutes les tentatives de synchronisation échouent :

clip_image002

SoapException: Fault occurred
at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at Microsoft.UpdateServices.ServerSyncWebServices.ServerSync.ServerSyncProxy.GetUpdateData(Cookie cookie, UpdateIdentity[] updateIds)
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.WebserviceGetUpdateData(UpdateIdentity[] updateIds, List`1 allMetadata, List`1 allFileUrls, Boolean isForConfig)
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.GetUpdateDataInChunksAndImport(List`1 neededUpdates, List`1 allMetadata, List`1 allFileUrls, Boolean isConfigData)
   at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

L’étude des fichiers de log Wsus et IIS montrent que l’appel au ServerSyncWebService échoue avec une erreur 500 :

clip_image004

clip_image006

Mais il s’agit d’une fausse piste.

En réalité, le problème provient d’une installation précédente de WSUS sur ce serveur. Bien qu’il ait été désinstallé proprement préalablement à la réinstallation (suppression du rôle Windows et de la base WID), le dossier C:\Windows\Softwaredistribution était toujours présent.

Après sa suppression (ou son renommage) et le redémarrage du service wuauserv, la synchronisation se lance.

 

clip_image009

clip_image007

clip_image011

SCOM – Approuver un agent absent de pending management

Lors de l’installation manuelle d’un agent SCOM (sans passer par l’assistant de la console SCOM), celui-ci doit, par défaut, être approuvé manuellement en passant par les Pending Management de l’onglet Administration de la console.

Dans de rares cas, il peut arriver que malgré une configuration correcte l’agent à approuver (ici nommé « 002 ») n’apparaisse pas et remonte les tant redoutées erreurs 21106 et 20070 indiquant que l’agent n’est pas autorisé à communiquer avec son serveur :

clip_image001

clip_image002

clip_image003

Par contre, l’agent apparait bien lorsqu’on utilise powershell :

clip_image004

Get-SCOMPendingManagement |where {$_.agentname –like ‘xxx’}

Il est alors possible de l’approuver également via Powershell :

Get-SCOMPendingManagement |where {$_.agentname -like ‘xxx’} | Approve-SCOMPendingManagement

Et le tour est joué, l’agent parvient maintenant à communiquer :

clip_image005

Une astuce bien utile, même si elle ne devrait pas vous servir tous les jours!

Direct Access : configurer Manage-Out dans un environnement réel

 

Lors du déploiement de Direct Access, le gros de l’attention est communément porté sur la configuration des accès de l’extérieur vers l’intérieur ; ce qui est tout naturel dans la mesure où il s’agit de l’utilisation principale de la solution.

Cependant, Direct Access peut également permettre les accès depuis votre LAN vers les clients connectés depuis l’extérieur, ce qui peut s’avérer extrêmement utile par exemple dans les scénarios d’assistance à distance de vos utilisateurs : il s’agit de la fonction dite de “manage out”

Une problématique peut alors vite émerger : comme vous le savez forcément si vous vous êtes déjà intéressés au sujet, Direct Access ne fonctionne qu’en IPv6 et repose sur des technologies de transition (IPHTTPS, 6to4, teredo… selon les scénarios, le premier étant de loin le plus utilisé) pour que les clients qui passent par internet (donc quasi systématiquement en IPv4) puissent dialoguer votre LAN (lui aussi très souvent en IPv4).
Par contre, la seule possibilité concernant les flux du LAN vers l’extérieur est le déploiement du routage ISATAP, avec tous ses inconvénients.
Par ailleurs, dans le cadre d’un déploiement multisite ou utilisant du load-balancing (très fréquent en entreprise pour des raisons de haute disponibilité), Microsoft ne supporte plus ce type de routage (cf. https://technet.microsoft.com/en-us/library/dn464274(v=ws.11).aspx#bkmk_isa ).

La seule solution restante est donc l’IPv6 natif.

Comme il n’est généralement pas envisageable d’entreprendre une migration complète de votre infrastructure réseau vers IPv6 simplement pour répondre à cette problématique, la solution d’un ou plusieurs serveurs « de rebond » dédiés à l’accès vers les clients externes reste la plus pratique, à défaut d’être la plus élégante. Il peut également tout à fait s’agir directement de vos serveurs SCCM ou de toute autre solutions de prise en main à distance dont vous disposeriez.
Ces serveurs seront configurés avec des adresses IPv6 statiques, leur permettant de communiquer avec votre infrastructure DirectAccess.

I Attribution des IPv6

Sur un des serveur Direct Access, lancez un shell powershell en tant qu’administrateur et exécutez la commande

(Get-DAServer).InternalIPv6Prefix

clip_image001

Le préfixe IPv6 interne de votre déploiement Direct Access est donc ici xxxx:yyyy:967b:1::/64

Nous allons l’utiliser pour définir arbitrairement les IPv6 statiques de vos différents serveurs Direct Access et serveurs Manage Out :

xxxx:yyyy:967b:1::1 (premier serveur Direct Access)
xxxx:yyyy:967b:1::2 (second serveur Direct Access)
[…]
xxxx:yyyy:967b:1::10 (premier serveur de Manage Out)
xxxx:yyyy:967b:1::11 (second serveur de Manage Out)
etc.

Il reste ensuite à les attribuer à chaque serveur, de facon tout à fait classique :

Ouvrez les propriétés de la carte réseau concernée (carte « LAN » ou unique sur vos serveurs DA) puis sélectionnez le protocole IPv6 et cliquez sur Properties :

clip_image003

Indiquez l’IPv6 du serveur, le prefix length 64 et cliquez sur OK.

clip_image004

II Création des routes

Afin que les serveurs de Manage-Out puissent communiquer avec les clients DirectAccess, il est ensuite nécessaire de leur ajouter des routes statiques. En effet, selon le serveur DirectAccess auquel un client est connecté, il obtiendra une adresse IPv6 avec un préfixe distinct et le serveur de ManageOut a besoin de savoir par quel serveur DirectAccess il doit passer pour pouvoir atteindre le client.

Il est possible d’obtenir ce préfixe en exécutant la commande suivante sur n’importe lequel des serveurs DirectAccess :

(Get-DAServer).ClientIPv6Prefix

clip_image005

On obtient ici le préfixe xxxx:yyyy:967b:1000::/59. Le préfixe client a une longueur de 59 bits.

Néanmoins ce dernier est subdivisé en préfixes de 64 bits et chacun d’entre eux est affecté à un serveur DirectAccess. Ainsi, selon l’exemple ci-dessus, les clients connectés au premier serveur DirectAccess obtiendront le préfixe xxxx:yyyy:967b:1000::/64, ceux connectés au second serveur auront le préfixe xxxx:yyyy:967b:1001::/64 etc.

Il est donc nécessaire d’ajouter autant de route que de serveur DirectAccess sur chaque serveur de Management.

Pour ce faire, on exécute les commandes suivantes :

Netsh int ipv6 add route xxxx:yyyy:967b:1000::/64 “Nom de la carte réseau” xxxx:yyyy:967b:1::1

Netsh int ipv6 add route xxxx:yyyy:967b:1001::/64 “Nom de la carte réseau” xxxx:yyyy:967b:1:: 2

clip_image006

III Ajout du serveur de Management à Direct Access

Le serveur de Manage-Out doit ensuite être ajouté aux serveurs de Management dans Direct Access.

Cela présente par ailleurs un intérêt majeur : il devient ainsi accessible même lorsqu’uniquement le tunnel infrastructure est monté, c’est-à-dire même si l’utilisateur n’a pas ouvert de session sur son PC.
Il devient alors envisageable de gérer à distance le déploiement de paquets, la synchronisation de console antivirus avec une gestion dans le LAN etc.

Pour réaliser cette opération, se rendre dans la console « Remote Access Management » puis dans le menu « DirectAccess and VPN » en ayant pris soin de sélectionner la ferme DirectAccess (« Load Balanced Cluster »). Ensuite, il est nécessaire de cliquer sur le bouton « Edit » de l’étape 3.

clip_image008

Dans l’onglet « Management », faites un clic-droit sur la liste de serveurs et sélectionnez « Add ».

clip_image009

Entrez le FQDN du serveur de manage-out et cliquez sur OK

clip_image010

Cliquez sur Finish.

Enfin, cliquez sur Refresh Management Servers :

clip_image012

Vous devriez maintenant pouvoir accéder à vos clients depuis le LAN, en utilisant leur nom DNS ou leur IPv6 directement.

Attention toutefois, les clients connectés via DirectAccess ont le profil de firewall Windows « public » actif, il peut donc être nécessaire d’ouvrir les ports dont vous aurez besoin pour ce profil !

SCOM - A read operation on a large objects failed while sending data to the client

Pour cet article, nous allons nous intéresser à un cas peu commun.

Une erreur passée inaperçue pendant plusieurs mois car visée par aucune règle ou moniteur se reproduisait très régulièrement, aléatoirement sur l’un ou l’autre des Management Servers :

clip_image002

Evénement 26319, An exception was thrown while processing GetObjectsFromReader for session ID uuid:2f0f5bab-011d-4002-98d1-4c500cc449a2;id=103303.
Exception message : A transport-level error has occurred when receiving results from the server. (provider TCP Provider, error 0 – The specified network name is no longer available).

La partie “provider TCP Provider, error 0 – The specified network name is no longer available” fait immanquablement penser à une erreur SQL, et le fait que la source de l’événement soit OpsMgr SDK Service est un indice supplémentaire en ce sens.

Une verification dans le journal d’événements Applications du serveur SQL de la base OperationsManager montre qu’effectivement, un événement 7886 est présent pour chaque événement 26319 sur les Management Servers :

clip_image004

A read operation on a large objects failed while sending data to the client. A common cause for this is if the application is running in READ UNCOMMITTED isolation level. This connection will be terminated.

« Une cause courante pour cette erreur est si le niveau d’isolation est READ UNCOMMITED »… Vérifions donc cela dans la base OperationsManager, à l’aide de la commande DBCC USEROPTIONS :

clip_image006

Manifestement, ce n’est pas le cas, elle est bien en committed…

Je me tourne donc vers mon moteur de recherche préféré, qui une fois n’est pas coutume ne m’aide qu’assez peu. Un lien retient cependant mon attention : https://scomblog.wordpress.com/2012/02/29/469/.

La plupart des informations abordées dans cet article n’ont rien à voir avec le cas qui nous intéresse aujourd’hui, mais le dernier point est des plus intéressant (malgré sa syntaxe assez douloureuse) : il nous apprend que cette erreur peut se produire lorsque une lecture d’une alerte dans la base de données survient au même moment que la mise à jour de cette même alerte (cas d’une alerte dont le RepeatCount s’incrémente), ce qui provoque un conflit.
Le cas de figure le plus évident serait donc celui d’une console SCOM ouverte sur une alerte qui s’incrémente très régulièrement lorsqu’un rafraîchissement de la console survient au moment de la mise à jour de l’alerte en base. En plus, cet environnement a effectivement quelques alertes dont le RepeatCount est élevé (plusieurs dizaines de milliers).

Sauf qu’après une petite enquête auprès des utilisateurs, aucun ne semble avoir de problème récurrent avec la console (popup d’erreur, déconnexions…) qui devraient pourtant se produire lorsque l’incident survient.

Pour en avoir le cœur net, une trace SQL est prise avec l’aide du support Microsoft. Elle révèle que les requêtes qui provoquent le problème sont toutes semblables à ceci :

clip_image008

Cette requête récupère les détails d’une alerte (source, description etc) ; elle est donc parfaitement légitime et il est normal d’en rencontrer un grand nombre. Elle cadre d’ailleurs avec l’explication préalablement analysée.
Un détail attire cependant mon attention : ici, la requête est effectuée pour TOUTES les alertes présentes dans l’environnement, puisque la variable @Id0, supposée contenir l’ID de l’alerte à récupérer, contient ici le caractère %, autrement dit le « joker » du langage SQL !
Il s’agit donc d’une requête particulièrement lourde, et qui n’a pas réellement de raison d’être effectuée par une utilisation normale de la console.

Peut-être est-il alors possible de retrouver par quel compte utilisateur cette requête est déclenchée ? Cela nous aiderait à comprendre comment elle survient…

Revenons donc à notre événement sur le Management Server SCOM. Ce n’est pas très lisible, mais il nous indique quelle session a rencontré le problème via l’information id=. Il s’agit donc ici de la session 103303.

clip_image010

En descendant un peu dans le journal d’événement, il doit normalement exister un événement 26328 qui correspond à la création de cette session et qui contient le compte l’ayant créé :

clip_image012

Voilà qui est intéressant ! Dans cet environnement, tous les utilisateurs se connectent avec leur compte nominal personnel. Le compte « SCOM2012_admin » n’est utilisé que pour l’exécution de scripts qui font appel à SCOM.

Il n’y a ici pas de moyen technique permettant de savoir quel est ce script ni à partir d’où il est exécuté, mais une bonne connaissance de l’environnement m’a permis d’avoir des soupçons sur un script en particulier qui s’exécutait très régulièrement et effectuait des traitements sur les alertes.

Une analyse du script a révélé qu’il exécutait le cmdlet Get-SCOMAlert | Where {blabla}, c’est-à-dire qu’il récupérait l’intégralité des alertes avec toutes leurs propriétés puis les filtrait à l’aide de la clause Where ; ce qui correspond parfaitement à ce qu’indiquait la trace SQL : nous tenons manifestement notre coupable !

Et la correction est en plus assez simple : il suffit de réaliser le filtrage dans la requête, ce qui a pour conséquence de l’alléger considérablement, en modifiant le cmdlet de la sorte : Get-SCOMAlert –Criteria {blablabla}.

Suite à cette modification, l’événement ne s’est plus reproduit et, pour ne rien gâcher, le serveur qui exécutait le script a vu son occupation CPU et RAM diminuer fortement :)

SCOM 2016 – Active Directory et contrôleurs de domaine

Pour commencer, une bonne nouvelle : le Management Pack Active Directory, connu des amateurs pour sa complexité et son manque de fiabilité, vient d’être en grande partie réécrit !

La nouvelle version ne nécessite plus OOMADS, la supervision de la réplication AD est entièrement nouvelle et simplifiée…

Attention ce nouveau MP ne met pas à jour l’ancien qui pourra donc être désinstallé avant de déployer le nouveau, ou conservé en parallèle. Par ailleurs, il n’est compatible qu’avec les contrôleurs de domaine sous Windows 2012 (R2) et 2016, quel que soit le niveau fonctionnel de votre AD.

Venons-en maintenant au problème qui nous intéresse : SCOM 2016 est sorti il y a quelques semaines, et avec lui son (petit) lot de nouveautés sur lesquels nous reviendrons probablement dans de prochains articles.

Une de ces nouveautés concerne le déploiement d’un agent sur un contrôleur de domaine : sans intervention de votre part, l’agent passera presque immédiatement en grisé et une alerte System Center Management Health Service Unloaded System Rule(s) est générée.

clip_image001

Une vérification sur le contrôleur de domaine concerné montre effectivement un très grand nombre d’événements 1102 dans le journal OperationsManager :

clip_image003

Mais il faut remonter plus loin, juste après le déploiement de l’agent, pour trouver l’événement qui nous intéresse :

clip_image005

Cet événement 7017 indique The health service blocked access to the windows credential NT AUTHORITY\SYSTEM because it is not authorized on management group <MG>. You can run the HSLockdown tool to change which credentials are authorized.

Ce message d’erreur rappelle une vieille KB Microsoft : https://support.microsoft.com/en-us/kb/946428

Et effectivement, il suffit d’exécuter l’outil HSLockdown (il se trouve dans le dossier d’installation de l’agent SCOM) pour, dans un premier temps, vérifier que le compte LocalSystem est bien bloqué :

clip_image007

Puis, dans un second temps, l’autoriser :

clip_image008

Ne reste plus qu’à redémarrer l’agent (HealthService), et tout rentre dans l’ordre.

Quant à savoir pourquoi ce comportement a changé depuis SCOM 2012, avec lequel LocalSystem n’était pas bloqué sur les DC… mystère !