Architecture / Microsoft / Network / Security
Contrairement à SCCM 2007R2, SCOM n’accepte pas d’installer la base OperationsManager/Data Warehouse sur un SQL Server 2008 R2. La vérification des pré requis échoue, indiquant que SQL Server n’est pas installé:
Le moyen le plus simple que j’ai trouvé est d’utiliser DBCreateWizard, disponible sur le CD/iso dans \SupportTools\AMD64. Il permet de créer la base OperationsManager et Data Warehouse:
Une fois le RMS installé, je vous conseil de passer la Cumulative Update #2.
La supervision Microsoft permet souvent de sortir des problèmes planqués sous le tapis…
Alertes remontées par SCOM:
SCOM exécute des scripts. Il suffit donc de faire « comme le script » pour avoir le même problème, en l’occurence une requête WMI sur le DNS:
Voici une méthode un peu radicale pour corriger le problème, à savoir reconstruire le repository WMI:
FOR /f %s in ('dir /b /s *.dll') do regsvr32 /s %s
Net stop /y winmgmt
FOR /f %s in ('dir /b *.mof *.mfl') do mofcomp %s
Net start winmgmt
Winmgmt /verifyrepository
Confirmation que le problème est corrigé:
Quelle drôle d’idée vous allez me dire… Mais avoir une ou plusieurs VM dans le cloud ne justifie pas d’avoir une supervision « à part ». Cependant le défi est pas mal:
Lorsque SCOM détecte Fedora, il bloque directement: 
Pour détecter la version, SCOM exécute le script Shell qui se trouve ici: 
Par ailleurs, le dossier comprend aussi les RPM qui sont installés par la suite (démon). Arriver à notre fin va nécessiter de l’huile de coude à plusieurs endroits…
Pour vous encourager, voici le résultat: 
Vous l’aurez compris, il s’agit notamment de faire croire à SCOM que nous avons une Red Hat. Il y a en fait deux possibilités:
La première solution est la plus élégante, mais elle va être longue à mettre en place, et à maintenir ensuite. J’ai donc préféré la seconde, surtout qu’une Fedora n’est pas très éloignée…
dans /etc/ssh/sshd_config:
PasswordAuthentication yes PermitRootLogin no #Supprimer également la dernière ligne du fichier qui permet un logon root sans mot de passe
Il faut ensuite donner un mot de passe au compte root:
passwd root
puis recharger la configuration:
/etc/init.d/sshd reload
Puis créer un compte utilisateur pour SCOM:
useradd scom passwd scom
HOSTNAME=www.lotp.fr
Le package RPM de Microsoft a des dépendances, notamment sur deux librairies:
Si votre système a une version plus récente (so.8 …), il suffit de faire des liens symboliques (ln -s cible fichierquiexiste): 
Au final, j’ai les liens symboliques suivants:lrwxrwxrwx 1 root root 16 Feb 16 16:19 libssl.so.6 -> libssl.so.0.9.8k lrwxrwxrwx 1 root root 12 Feb 16 16:23 libcrypto.so.6 -> libcrypto.so
Je vous invite à copier le rpm (scx-1.0.4-248.rhel.5.x86.rpm), afin de valider la bonne installation. Sinon c’est SCOM qui le fera pendant le déploiement, et les messages de retour ne sont pas toujours explicite.
Par ailleurs, cela permet de voir le nom avec lequel le certificat est crée:
Il est toujours possible de le désinstaller:
rpm -e scx-1.0.4-248.i386
Il faut configurer le parefeu Amazon afin que ces deux accès soient possibles. Si le port 1270 n’est pas joignable, SCOM remonte une erreur de timeout pas explicite. Le trafic vers ce port est confirmé par une trace réseau: 
NB: si vous ne connaissez pas Wireshark, j’ai fait une vidéo/tutoriel dessus, elle est disponible ici.
Par défaut, Fedora crée un lien symbolique de /etc/fedora-release vers /etc/redhat-release. il faut casser ce lien symbolique, et créer le fichier redhat-release avec comme donnée Red hat…:
rm /etc/redhat-release echo "Red Hat Enterprise Linux Server release 5" > /etc/redhat-release
Les actions à mener seront les suivantes:
Ajouter la VM est passe comme une lettre à la poste si vous respectez bien les différents pré requis. Je vais donc m’attarder sur les problèmes que j’ai rencontré. Autoriser WinRM à faire une authentification basique: 
Si vous n’avez pas mis le bon hostname, le certificat est refusé au moment de le signer: 
Si vous ne déclarez pas de comptes, les workflow ne fonctionnent pas: 
Au départ, la VM n’est pas encore supervisée et marquée « unknown »:
Puis elle passe ensuite au vert:
Voilà, à ce stade, votre VM est supervisée par SCOM 2007 R2. Voici quelques écrans de SCOM 2007 R2 une fois tout opérationnel:
on m’a demandé de remettre sur pied une plateforme SCOM 2007, en commençant par une réinstallation. J’ai donc désinstallé SCOM du serveur, et supprimé les bases de données du serveur SQL distants.
Après l’installation, SQL indiquait que le service broker était déjà activé…Bonne surprise ou annonce d’autres problèmes ? J’ai eu droit à la deuxième hypothèse…
Suite à la réinstallation, j’ai eu quelques problèmes liés à SQL (An exception occured while enqueuing a message in the target queue):
Résolution:
declare @conversation uniqueidentifier
while exists (select 1 from sys.transmission_queue)
begin
set @conversation = (select top 1 conversation_handle from sys.transmission_queue)
end conversation @conversation with cleanup
end
Et voilà, le discovery fonctionne de nouveau aussi, car il dépend des messages passant via le broker.
J’ai récemment accumulé pas mal de problèmes liés aux paramètres régionaux (développeurs, si vous me lisez…). Avoir un OS en anglais ne suffit plus à priori à s’éviter les ennuis! Les nominés sont:
SCOM 2007:
MBSA: Certaines catégories sont reprises en français (depuis un XP FR), et les accents é;à… se transforment en caractèrent XML invalides. Solution: correction manuelle via un éditeur de texte…
Broadcom: problème de date comme évoqué dans un précédent billet
Pour Dell, voici la fonction incriminée (en rouge le problème):
Function CheckVBScriptEngine()
Dim bIsCompatV, var
Const VBSCRIPT_MIN_VERSION = 5.6
var = ScriptEngineMajorVersion & « . » & ScriptEngineMinorVersion
If (CInt(var)) < VBSCRIPT_MIN_VERSION Then
bIsCompatV = False
Else
bIsCompatV = True
End If
If Err <> 0 Then
CheckVBScriptEngine = Err.Number
Else
CheckVBScriptEngine = bIsCompatV
End If
End Function
Ma version :
Function CheckVBScriptEngine()
Dim bIsCompatV, var, sep, WshShell
Set WshShell = WScript.CreateObject(« WScript.Shell »)
sep = WshShell.RegRead(« HKCU\Control Panel\International\sDecimal »)
Const VBSCRIPT_MIN_VERSION = 5.6
var = ScriptEngineMajorVersion & sep & ScriptEngineMinorVersion
If (CInt(var)) < VBSCRIPT_MIN_VERSION Then
bIsCompatV = False
Else
bIsCompatV = True
End If
If Err <> 0 Then
CheckVBScriptEngine = Err.Number
Else
CheckVBScriptEngine = bIsCompatV
End If
End Function
Pour ISA, le workaround temporaire est de créer un compte dédié, se logguer avec, mettre les paramètres régionaux en anglais, et de l’utiliser en tant que Action Account dans SCOM.
Pour le MBSA, l’erreur se présente sous cette forme:
DSI++: Toujours utiliser les fonctions du langage ou Framework afin d’utiliser les paramètres régionaux. Ne pas hésiter à tester vos logiciels avec plusieurs langues s’ils ont une vocation internationnale.
Contexte:
Problème:
Il vous manque un certificat dans la chaîne. Votre compte Windows a bien toute la chaîne, mais pas le compte ordinateur local. Dans mon cas, il a fallu ajouter un certificat Verisign (Class 3) pour le compte ordinateur local:
….Et les alertes disparaissent! On aurait pu se contenter de décocher la vérification de la santé du SSL, mais c’est toujours mieux de corriger le problème à la source, et d’être prévenu quand son certificat a expiré 🙂