PI Services

Le blog des collaborateurs de PI Services

SCOM – Les Management Packs HP

Si vous disposez de matériel Hewlette Packard/HPE (Proliant, BladeSystem) dans votre parc, vous avez probablement déployé le Management Pack qui va avec… ou peut-être avez-vous abandonné au vu de la difficulté pour trouver les bonnes versions, les bons liens, la bonne documentation etc.

Voici donc un résumé qui devrait vous simplifier la tâche !

Télécharger les Management Packs

Première étape de votre quête : télécharger les management packs ! Entre les liens corrompus, les fichiers sans rapport, les différentes versions… difficile de s’y retrouver.

Ne cherchez plus, les fichiers contenant les derniers management packs se trouvent ici : https://h20392.www2.hpe.com/portal/swdepot/displayProductInfo.do?productNumber=Z7500-63235

Une fois enregistré et connecté, téléchargez le fichier HP OneView for Microsoft System Center 8.0 ZIP - October 2015. Il contient beaucoup de choses inutiles pour ce qui nous intéresse, mais aussi et surtout le fichier hpscomkit-x64-3.2.1.exe avec tous les management packs et les consoles nécessaires (à exécuter en tant qu’administrateur pour éviter toute mauvaise surprise !)

clip_image002

Tableau de synthèse

Commençons par un tableau synthétique de ce qui est supporté à travers quel management pack, nous détaillerons par la suite les différentes possibilités :

clip_image003

Supervision Agentless

La supervision sans agent du matériel HP est distincte de la supervision sans agent au sens SCOM du terme : il s’agit ici de déployer le service Device Management Service (DMS) et sa console Device Management Console (DMC), puis d’y renseigner tous les matériels HP que vous souhaitez superviser sans agent.

Cette console DMC permet d’ajouter trois types de matériel :

- Le mode BladeSystem pour les chassis, via leur Onboard Administrator (v4.01 et supérieures)

- Le mode Linux (RHEL5-6-7, SLES10-11-12)/ESX 4.x (mais pas ESX 5.x et supérieurs !)

- Le mode Agentless Server, par défaut en quelque sorte, qui supporte tous les serveurs Gen8 et supérieurs via leur iLO quel que soit le système d’exploitation (Windows, Linux, ESX…).

clip_image005

Notez également qu’il est vivement recommandé d’installer le DMS sur un serveur qui n’est pas un serveur SCOM, ou au moins un serveur SCOM n’effectuant pas de supervision réseau car le service peut utiliser SNMP pour communiquer avec les différents matériels !

Il faut toutefois que le serveur qui héberge DMS dispose d’un agent SCOM.

clip_image006

Agentless Management Service

L’AMS est un module complémentaire qui permet d’obtenir plus d’informations en cas de supervision Agentless.

Son installation est détaillée dans le document suivant (pages 113 et suivantes) : http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c03334051

clip_image008

Cas particulier

Supervision ESX4 via le mode Linux/ESX, supervision tous OS à partir des Gen8 pour le mode Agentless Server… Mais alors, qu’en est-il des serveurs Gen6 ou 7 sous ESX5.x, que l’on retrouve parfois ?

Eh bien, ils ne sont tout simplement pas supportés, comme le confirme Stephan Roth qui a posé la question à HP Suisse : https://stefanroth.net/2012/11/04/scom-2012-hp-hardware-monitoring-on-vmware-esxi-servers/

Supervision de serveurs sous Windows :

La solution la plus simple pour superviser les serveurs (toutes générations) sous Windows est de d’abord déployer l’agent HP Insight, puis d’utiliser les MP Proliant SNMP et WBEM : la découverte se fera alors automatiquement, à la façon « SCOM » habituelle en quelque sorte.

Il n’est donc plus nécessaire dans ce cas d’ajouter chaque serveur dans la console DMC, ce qui simplifie grandement la gestion. De plus, ce mode permet de superviser toutes les générations de serveurs HP et pas uniquement les Gen8 et supérieurs.

Il s’agit donc clairement de la solution à préférer pour les serveurs Windows !

Pour aller plus loin

Les documents à jour concernant la supervision du matériel HP sont eux aussi assez compliqués à trouver.

En voici deux qui vous permettront de mieux cerner la problématique :

Managing Mixed Environnements with HPE SCOM MP : http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5390822&docId=emr_na-c04347838&docLocale=en_US

HPE SCOM Integration kit : http://h20565.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=5390822&docId=emr_na-c04605146&docLocale=en_US

SCOM 2012 – Lister toutes les alertes provenant des serveurs d’un groupe

Selon le mode de fonctionnement de votre service informatique, il est possible que vous n’ayez pas une équipe de supervision dédiée mais plutôt que cette tâche incombe à chaque équipe pour son périmètre de serveurs donné.

Si en plus vous utilisez un Resolution State différent pour attribuer les alertes à chaque équipe, l’idée peut vite vous venir de scripter cette tâche !

A priori, rien de bien compliqué.

Commençons par récupérer le groupe :

$group = Get-SCOMGroup –Displayname “Nom du groupe”

Puis les instances présentes dans ce groupe. Cette fois-ci, pas de cmdlet natif, il faut utiliser la méthode GetRelatedMonitoringObjects du groupe :

$groupinstances = $group.GetRelatedMonitoringObjects('Recursive')

Et enfin les alertes non attribuées (Resolution State 0) provenant de ces instances :

$alerts = Get-SCOMAlert -instance $groupinstances -ResolutionState 0

Hélas, si le groupe visé est un minimum conséquent, on obtient l’erreur suivante :

The incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect. Too many parameters were provided in this RPC request. The maximum is 2100.

Cette erreur provient directement de SQL et n’est pas propre à SCOM (cf. https://blogs.msdn.microsoft.com/emeadaxsupport/2009/09/01/how-to-fix-sql-error-too-many-parameters-were-provided-in-this-rpc-request/ )

De plus, le cmdlet Get-SCOMAlert est très lent à exécuter et il n’est donc pas envisageable de l’utiliser dans un script qui aurait vocation à s’exécuter régulièrement.

Heureusement, une autre méthode de $group existe :

$alerts = $group.GetMonitoringAlerts([Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive)

De cette façon, on n’a même plus besoin de récupérer les instances du groupe, on prend les alertes directement… et cette méthode est particulièrement véloce !

Attention toutefois, elle récupère toutes les alertes, y compris les alertes déjà attribuées ou déjà fermées. Il est donc nécessaire de les filtrer dans la dernière étape, celle de l’affectation de l’alerte à la bonne équipe à l’aide d’un ResolutionState :

$alerts | where resolutionstate -eq 0 | Set-SCOMAlert -ResolutionState xxx

On résume ? La solution n’était pas si évidente, mais au final 3 lignes suffisent :

$group = Get-SCOMGroup –Displayname “Nom du groupe”

$alerts = $group.GetMonitoringAlerts([Microsoft.EnterpriseManagement.Common.TraversalDepth]::Recursive)

$alerts | where resolutionstate -eq 0 | Set-SCOMAlert -ResolutionState xxx

A vous maintenant de les intégrer à vos scripts en fonction de vos besoins !

SCOM 2012 : créer un grand nombre de règles en quelques minutes

Lors de la création d’un nouveau Management Pack pour une application métier, il arrive qu’un grand nombre de règles ou de moniteurs similaires (alerte sur événement windows, collecte de compteur de performance…) doivent être ajoutées.

Il est bien sûr toujours possible de les créer les une après les autres à l’aide de la console SCOM, de l’outil MP Author ou d’un notepad, mais cela peut rapidement devenir très répétitif et inutilement consommateur en temps.

En effet, à l’aide de Visual Studio (qui est disponible en « community edition » gratuite depuis maintenant quelques années, plus d’excuses !) et des Authoring Extensions, il est possible d’automatiser en grande partie ce processus !

Commençez par créer un nouveau projet de type Management Pack 2007 R2 (nul besoin de sélectionner 2012 car nous ne ferons rien qui le justifie ici, et cela permet de conserver la rétrocompatibilité du MP) :

clip_image002

Dans l’explorateur de solutions, faites un clic-droit sur le nom de votre projet et sélectionnez ajouter > nouvel élément.

clip_image004

Sélectionnez Snippet Template, nommez-le et cliquez sur ajouter :

clip_image006

Un bloc de code pré-rempli apparaît (il s’agit du template par défaut, un règle de collecte de compteur de performance; mais rien ne vous empêche d’y substituer votre propre code comme nous le verrons plus loin) :

clip_image008

On remarque immédiatement que les balises les plus couramment modifiées lors de la création d’un MP (ID de la règle, cible, nom du compteur, fréquence de collection…) apparaissent surlignées en jaune, et que leur valeur est quelque peu inhabituelle : il s’agit en fait de variables, qui seront remplacées à la volée lors de l’étape suivante.

Ces variables sont de trois types : #text (une simple chaine de caractères), #choice (une liste déroulante) et #alias (elles permettent de résoudre automatiquement l’alias vers vos MP référencés).

Voyons donc maintenant comment alimenter ces variables.

Retournez dans ajouter > nouvel élément, mais sélectionnez cette fois Snippet Data :

clip_image010

Pour l’instant, cela ne crée rien de bien utile :

clip_image012

Cliquez sur Select snippet type et sélectionnez le Snippet Template préalablement créé :

clip_image014

Cette fois-ci, différentes colonnes sont présentes (elles correspondent aux différentes variables présentes dans le template), et deux possibilités nous sont offertes : ajouter des données manuellement (click here to add a new item) ou les importer depuis un fichier CSV (bouton Import from CSV file) :

clip_image016

Commençons par la première possibilité. En cliquant sur click here to add a new item, une ligne vierge apparait. A vous de renseigner les différents champs :

clip_image018

Imaginons maintenant que nous ayons des dizaines de compteurs à collecter via des règles différentes : les ajouter à la main l’un après l’autre de cette facon reste beaucoup plus pratique (et plus propre !) que de créer les règles les unes après les autres dans la console SCOM, mais on peut faire encore plus rapide à l’aide d’un fichier CSV :

clip_image020

Cliquez sur Import from CSV file et sélectionnez votre fichier CSV. Les valeurs qu’il contient sont automatiquement ajoutées à votre Snippet :

clip_image022

Une fois que vous avez entré les valeurs pour toutes les règles que vous souhaitez créer, cliquez sur enregistrer clip_image024 .

Ici, une erreur se produit car le MP System.Performance.Library est référencé dans le Snippet Template, mais pas dans le projet :

clip_image026

Il faut donc l’ajouter : clic-droit sur References > ajouter dans l’explorateur de solutions et sélectionnez le fichier .mp manquant. Vous pouvez le retrouver sur votre serveur SCOM, ou directement dans le dossier d’installation des VSAE pour les MP les plus communs (C:\Program Files (x86)\System Center Visual Studio Authoring Extensions\References\OM2007R2\Microsoft.Windows.Library.mp )

clip_image027

Répétez l’opération pour chaque MP référencé manquant, puis cliquez à nouveau sur Sauvegarder.

Un nouveau fichier doit apparaître dans l’arborescence de votre explorateur de solutions :

clip_image029

Ouvrez le : il contient le code correspondant à toutes vos règles, généré automatiquement en fonction de vos paramètres d’entrée :

clip_image031

Libre à vous maintenant de laisser libre cours à votre imagination pour créer vos propres Snippet Template correspondant à des moniteurs d’évènements, des scripts vbs etc…

Pour cela, rien de plus simple : recopiez vos bouts de codes en reprenant la nomenclature vue ci-dessus pour les variables, créez un nouveau Snippet de Data et alimentez-le à l’aide d’un fichier csv ou manuellement, comme nous venons de le voir.

clip_image033 Attention : si lors de vos développements, vous utilisez des colonnes contenant « true » ou « false » (par exemple si vous souhaitez définir si une règle ou un moniteur sera activé ou non par défaut), il faut obligatoirement que ces valeurs soient écrites en minuscules ; vous rencontrerez une erreur lors de la sauvegarde dans le cas contraire.

Une fois ces fragments de code obtenus, vous pouvez soit continuer votre développement dans Visual Studio et générer votre MP lorsqu’il est terminé, soit les intégrer par copier/coller dans le code XML d’un MP existant que vous souhaitiez enrichir.

Un grand merci au maitre SCOM Kevin Holman pour l’idée originale de cet article ainsi que pour l’ensemble de son œuvre :)

Powershell/Azure/Orchestrator : Formatage des volumes additionnels

 

Lors de la création d’une machine virtuelle, on ne se contente en général pas d’un seul « disque dur » (vhd/vmdk). Il est d’usage de conserver le volume principal pour le système, et d’ajouter un ou plusieurs volumes pour les données, les sauvegardes…

Lors de la création de la VM, ces volumes y sont bien rattachés mais ils sont dans un état « brut » : non initialisés, ni partitionnés, ni formatés, ni nommés, et ne disposant pas de lettre de lecteur.

Et si ces opérations peuvent s’avérer fastidieuses lorsqu’il s’agit d’un déploiement manuel, elles deviennent inacceptables lorsqu’il s’agit de VM déployées automatiquement via un portail self-service déclenchant un processus d’orchestration : la VM doit être livrée « prête à fonctionner » à l’utilisateur qui en a fait la demande.

Heureusement, le vénérable outil diskpart peut être scripté, automatisant ainsi le procédé.

Le script powershell que je vous propose ci-dessous doit être exécuté en tant qu’administrateur local, dès que la VM est démarrée. Il détecte tous les disques qui ne disposent d’aucune partition, les initialise, les partitionne (une seule partition primaire), les formate, les renomme DATAxxx et leur attribue la première lettre disponible.

$datadisks = get-wmiobject win32_diskdrive | where partitions -eq 0

$i = 1

foreach ($disk in $datadisks) {

$diskID = $disk.index

$diskname = "DATA" + $i

$dpscript = @"

SELECT DISK $diskID

ATTRIBUTES DISK CLEAR READONLY

CREATE PARTITION PRIMARY

FORMAT fs=ntfs quick label=$diskname

ASSIGN

"@

$i++

$dpscript | diskpart

}

Il ne reste plus qu’à intégrer ce script à votre processus de déploiement, qu’il s’agisse d’une tâche post-installation dans SCVMM ou d’un runbook Orchestrator :

clip_image002

Il s’agit ici d’un déploiement de VM dans Azure ne disposant que d’un compte administrateur local hors domaine. On commence par monter le disque D : de la VM (disque temporaire créé automatiquement) en tant que partage, puis on y crée le script proposé ci-dessus, on l’exécute à l’aide de la commande powershell.exe -ExecutionPolicy ByPass "& ""D:\diskpart.ps1"""  et on termine en démontant le partage réseau.

L’exécution du script ne prend que quelques minutes même avec plusieurs volumes à formater, et il s’adapte automatiquement quel que soit leur nombre.

Powershell/Azure : utiliser un proxy dans un script

 

Certains scripts powershell peuvent nécessiter un accès au Web, comme par exemple ceux utilisés pour piloter un tenant Azure.

Or, la majorité des organisations utilisent aujourd’hui des proxy pour contrôler ces accès à Internet et il est préférable d’éviter autant que possible les exceptions à cette règle, y compris lorsque c’est un script qui a besoin de se connecter.

Certains cmdlet ont en plus une facheuse tendance à ignorer les paramètres de proxy de l’utilisateur qui les exécute (c’est le cas des cmdlet Azure Powershell tels que Login-AzureRmAccount), et il n’est pas toujours possible ou souhaitable de définir un proxy au niveau du système, via la commande netsh winhttp set proxy…

Heureusement, il est possible de spécifier ces paramètres directement au sein du script !

Dans un premier temps, il est nécessaire de spécifier l’adresse du Proxy :

$proxyAddress = "http://1.2.3.4:8080"

$proxyUri = new-object System.Uri($proxyAddress)

[System.Net.WebRequest]::DefaultWebProxy = new-object System.Net.WebProxy ($proxyUri, $true)

Si le proxy accepte les connexions anonymes, cela peut suffire.

Autrement, il sera nécessaire de spécifier des credentials autorisés à s’y connecter. Dans ce cas, deux possibilité :

- Soit vous ré-utilisez les credentials de l’utilisateur qui exécute le script :

[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

- Soit vous utilisez les credentials d’un autre compte  :

$proxyAccountName = "domain\user"

$proxyPassword = ConvertTo-SecureString "PASSWORD" -AsPlainText -Force

$proxyCred = New-Object System.Management.Automation.PSCredential($proxyAccountName, $proxyPassword)

[System.Net.WebRequest]::DefaultWebProxy.Credentials = $proxycred

En plaçant ces quelques lignes avant toute exécution de cmdlet nécessitant un accès au Web, vous ne devriez plus rencontrer de problème!

Azure : Récupérer l’adresse IP d’une machine virtuelle

 

Il peut parfois s’avérer nécessaire dans un script de récupérer l’adresse IP d’une VM Azure alors que celle-ci n’est pas enregistrée dans le DNS.

Dans Azure « classic» (l’ancienne version), cette information était renvoyée directement à l’aide du cmdlet Get-AzureVM :

clip_image002

Malheureusement, pour les VM créées dans Azure Resource Manager (Azure RM, la « nouvelle » version), le cmdlet Get-AzureRmVM fonctionne différemment et ne renvoie plus directement cette information :

clip_image004

Il renvoie par contre une information intéressante : l’ID de la carte réseau associée à la VM, via la propriété NetworkInterfaceIDs :

clip_image006

La fin de cet ID représente le « display name » de la carte réseau, qui va nous permettre de retrouver les propriétés détaillées de cette carte à l’aide du cmdlet Get-AzureRmNetworkInterface :

clip_image008

Dans ces propriétés détaillées, une en particulier nous intéresse : IpConfigurationsText.
Comme son nom l’indique, elle contient le détail de la configuration Ip de la carte réseau, dont la PrivateIpAddress qui nous intéresse :

clip_image010

Afin d’automatiser ce processus, j’ai réalisé une fonction Get-AzureRmVMIP qui prend en entrée le nom de la VM et celui de son Resource Group, et qui renvoie le nom de la carte réseau et son IP :

clip_image012

Fonction dont voici le code source, que vous pouvez réutiliser ou adapter à votre guise dans vos propres scripts.

Function Get-AzureRmVMIP

{ param

(

[Parameter(Mandatory=$true,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]

[string]

$Name,

[Parameter(Mandatory=$true,ValueFromPipelineByPropertyName=$true)]

[string]

$ResourceGroupName

)

Process

{

$VM = Get-AzureRmVM -Name $Name -ResourceGroupName $ResourceGroupName

$NICs = get-AzureRmNetworkInterface -name $vm.NetworkInterfaceIDs.split("/")[-1] -ResourceGroupName $ResourceGroupName

$VMIPAddresses = @()

foreach ($NIC in $NICs) {

$VMIPAddresses += @{$NIC.Name = $NIC.IpConfigurations.PrivateIpAddress}

}

Return $VMIPAddresses

}

}

Orchestrator – Déployer des Integration Packs en DMZ

 

Dans le cadre d’un déploiement d’Orchestrator 2012 contenant des Runbook Servers dans un réseau isolé (DMZ) du reste de l’infrastructure, le déploiement des Integration Packs peut devenir problématique.

En effet, ces derniers sont normalement enregistrés dans le Management Server (Register IP) puis poussés vers les Runbook Servers et Runbook Designers (Deploy IP) à travers le réseau à l’aide de la console Deployment Manager, située sur le serveur hébergeant le rôle Management Server.

clip_image002

Lorsque les flux réseau sont bloqués, il n’est donc pas possible de pousser les Integration Packs vers leur destination

Deux solutions sont alors disponibles : installer les IP localement sur les serveurs en DMZ, ou ouvrir les flux nécessaires.

Installation locale

Prenons l’exemple de l’intégration pack pour Active Directory.

Il est dans un premier temps nécessaire de l’enregistrer (Register IP) tout à fait classiquement, je ne détaillerais donc pas cette étape ici :

clip_image004

Lors de ce processus, l’Integration Pack est copié sous forme de fichier MSI dans le dossier C:\Program Files (x86)\Common Files\Microsoft System Center 2012\Orchestrator\Management Server\Components\Objects :

clip_image006

Copiez ce fichier vers le Runbook Server ou le Runbook Designer de DMZ, puis exécutez-le.

L’installeur se déroule et se ferme sans aucune intervention de votre part, mais une fois terminé, l’Integration Pack doit être visible dans le Deployment Manager et ses activités doivent apparaitre dans le Runbook Designer (il est nécessaire de le relancer s’il était déjà ouvert) :

clip_image007

clip_image009

Ouverture des flux

Là aussi, il est tout d’abord nécessaire d’enregistrer l’Integration pack de façon classique (Register IP)

Lors du déploiement par la console Deployment Manager, les protocoles utilisés sont SMB et WMI, c’est-à-dire les habituels ports 135 et 445 en TCP, qu’il faudra donc ouvrir entre votre LAN et la DMZ où se trouvent vos Runbook Servers ou Runbook Designers.

Il est bien entendu également nécessaire d’ouvrir ces ports dans un éventuel firewall (Windows ou autre), ainsi que d’autoriser l’accès réseau à l’exécutable %SystemRoot%\SysWOW64\OrchestratorRemotingService.exe ; autrement le déploiement ne fonctionnera pas.

Le déploiement se fait ensuite via la console Deployment Manager de la même manière que si les serveurs cible étaient dans le LAN.

Complément

Attention toutefois, dans le cadre de l’utilisation d’un environnement Orchestrator disposant de serveurs Runbook à la fois dans le LAN et dans la DMZ : il devient alors primordial de bien déterminer quel Runbook devra tourner sur quel serveur, soit à l’aide des propriétés du Runbook à exécuter, soit via l’activité Invoke Runbook du runbook parent qui appelle le Runbook à exécuter (il est dans ce cas possible d’en indiquer plusieurs en les séparant par des point-virgules) :

clip_image011 clip_image013

Orchestrator - Changer les credentials des comptes de service

 

Il peut s’avérer nécessaire de changer les credentials des comptes de service utilisés par Orchestrator, lors d’incidents habituels dans le cycle de vie du produit (perte du mot de passe, politique de sécurité…).

Cependant, cela nécessite une reconfiguration à plusieurs niveaux :

Compte de service Orchestrator

Le premier niveau est le changement de credentials du compte utilisé pour exécutez les services Orchestrator (Management Service, Runbook Services…)

Dans un premier temps, il faut remplacer les mots de passe des services qui se trouvent sur chaque serveur hébergeant un rôle Orchestrator (Management, Runbook…).

Tout ou partie des services suivants peuvent être présents, en fonction des rôles attribués au serveur :

clip_image002

Pour modifier le compte utilisé par ces services, double-cliquez sur chacun d’eux et ouvrez l’onglet Log On :

clip_image004

Indiquez le nouveau login et/ou mot de passe puis cliquez sur OK.

Il est ensuite également nécessaire de modifier le compte utilisé par le pool d’application IIS :

Dans la console IIS Manager, ouvrez les Applications Pools et sélectionnez System Centez 2012 Orchestrator Web Features.

clip_image006

Faire un clic-droit et sélectionnez Advanced Settings.

clip_image008

Dans le champ Identity, cliquez sur l’icône « … »

clip_image010

Cliquez sur Set

clip_image012

Indiquez le nouveau login et/ou mot de passe du compte de service, puis cliquez sur OK dans chacune des fenêtres ouvertes.

Compte d’accès à la base SQL

Le second niveau concerne la modification des credentials du compte utilisé par Orchestrator pour se connecter à sa base SQL : il ne s’agit pas nécessairement du compte de service utilisé précédemment.

Lorsqu’il est modifié, la configuration d’Orchestrator doit être également modifiée sur l’ensemble des serveurs exécutant le rôle Runbook Server et/ou le rôle Web Service.

Runbook Server

Lancez la console Data Store Configuration :

clip_image014

Indiquez le nom du serveur SQL dans le champ Server et les credentials de connexion à l’instance SQL dans les champs Authentication Credentials., puis cliquez sur Next.

clip_image016

Cochez Use an existing data store et sélectionnez la base Orchestrator, puis cliquez sur Finish.

N’oubliez pas de répéter cette opération sur chacun des serveurs de Runbook.

Web Service

Le fichier de configuration du webservice est chiffré, il est donc nécessaire de le déchiffrer avant de le modifier.

Ouvrez un prompt de commande en mode administrateur et exécutez la commande

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pdf "connectionStrings" "D:\Program Files (x86)\Microsoft System Centez 2012 R2\Orchestrator\Web Service\Orchestrator2012"

clip_image018

Dans la console IIS Management, ouvrez l’arborescence Sites/Microsoft System Centez 2012 Orchestrator Web Service/Orchestrator2012.

Ouvrez la configuration des Connection Strings

clip_image020

Ouvrez Orchestrator Context et modifiez les informations de connexion à la base de données (serveur, instance, credentials…) en fonction du besoin.

clip_image022

Chiffrez à nouveau le fichier de configuration à l’aide de la commande C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "D:\Program Files (x86)\Microsoft System Centez 2012 R2\Orchestrator\Web Service\Orchestrator2012"

clip_image024

Enfin, redémarrez IIS à l’aide de la commande iisreset.exe

Ca y est, nous avons désormais fait le tour de cette procédure, assez fastidieuse il est vrai… et malheureusement pas automatisable sous forme de runbook Clignement d'œil

Azure - récupérer l’accès à une VM quand la carte réseau a été désactivée

 

Si vous utilisez Azure pour déployer des VM, vous n’êtes pas sans savoir qu’il n’existe aucun moyen de se connecter à une console « directe » (en mode KVM/Ilo/Idrac).

Les seules possibilités d’accès sont celles basées sur un protocole réseau, par exemple Remote Desktop sous Windows.

Mais alors, que se passe-t-il si vous avez désactivé la carte réseau ? Il n’existe à première vue plus aucun moyen de prendre la main sur votre VM…

Un simple redémarrage ne suffit évidemment pas.

Mais une astuce simple permet de se sortir de ce mauvais pas :

Ouvrez l’ancien portail azure ( https://manage.windowsazure.com ) (au moment de la rédaction de ce billet, la manipulation ne fonctionne pas avec le nouveau).

Ouvrez les propriétés de votre VM et modifiez sa taille (size) en choisissant un autre Tier que celle où elle se trouve déjà (Standard vers Basic, par exemple) :

clip_image002

Le redimensionnement prend quelques secondes et est suivi d’un redémarrage de la VM :

clip_image004

clip_image006

clip_image008

Patientez encore quelques minutes, le temps que la VM termine de démarrer et qu’elle installe les pilotes de la « nouvelle » carte réseau, puis qu’elle monte les services réseau etc.

Vous devriez maintenant pouvoir vous connecter via le Bureau à distance à votre VM, avec son ancienne IP !

On peut également retrouver dans le journal d’événements une trace de l’installation de cette nouvelle carte réseau :

clip_image010

SCOM – Utiliser un Run As dans un script

Dans un précédent billet, je décrivais comment Ajouter un Run-As profile à un moniteur ou à une règle, afin de les faire s’exécuter avec des credentials autres que Local System.

Je vous propose ici un complément sur le même sujet, qui vous permettra d’utiliser en paramètre d’un script un couple login/mot de passe stocké dans un Run-As account, vous permettant ainsi de ne pas coder ces credentials en dur dans le script pour plus de sécurité et de maintenabilité.

Tout le début de cette procédure est exactement identique à celle proposée dans le précédent billet, vous pouvez donc vous y référer si vous ne disposez pas encore d’un couple run as profile/run as account contenant vos credentials.
Notez toutefois qu’il faut ici créer un un run as account de type Simple Authentication et non pas un compte Windows.

Une fois ceci fait et en possession de l’ID du Run As profile, nous pouvons revenir à notre moniteur ou règle de type script.

Dans les paramètres passés au script, il est alors possible de faire appel à ce profil à l’aide la syntaxe

$RunAs[Name="Test.Monitors.RunAsProfile"]/Username$ pour le login et

$RunAs[Name="Test.Monitors.RunAsProfile"]/Password$ pour le mot de passe.

Le login et le mot de passe (automatiquement déchiffré et donc passé en clair au script) seront alors passés au script lors de son exécution.

clip_image002

Il ne reste alors plus qu’à les déclarer et les assigner à une variable dans le script, puis à les utiliser par exemple ici pour se connecter à un serveur SQL :

Dim Username, Password, sConnectString
Username = WScript.Arguments(0)
Password = WScript.Arguments(1)
[…]
sConnectString = "Driver={SQL Server}; Server=SQL\TEST; Database=TESTDB;uid=" & Username & ";password=" & Password
[…]

On le voit, le mot de passe n’est jamais codé en clair dans le script et pour le modifier, il suffit de modifier le Profil et non pas le script.