PI Services

Quoi de plus frustrant pour reprendre le travail que de se retrouver face à son outil préféré devenu soudain inutilisable?

Si depuis quelques jours, votre console SCOM fait des siennes et plante à chaque fois que vous tentez d’accéder à une vue de type “état” (telle que Windows Computers par exemple), avec l’erreur suivante :

Et qu’en même temps, vous retrouvez un message d’erreur similaire au suivant dans votre journal d’évènements Application :

Faulting application name: Microsoft.EnterpriseManagement.Monitoring.Console.exe, version: 7.1.10226.1177, time stamp: 0x5697e092 Faulting module name: ntdll.dll, version: 6.3.9600.18438, time stamp: 0x57ae642e Exception code: 0xc0000374 Fault offset: 0x00000000000f1b70 Faulting process id: 0xfac Faulting application start time: 0x01d2254a42863351 Faulting application path: <C:\Program Files\Microsoft System Center 2012 R2 \Operations Manager\Console\Microsoft.EnterpriseManagement.Monitoring.Console.exe> Faulting module path: C:\Windows\SYSTEM32\ntdll.dll

Le coupable est tout trouvé, il s’agit des patchs de sécurité Windows du mois d’Octobre, en particulier MS16-118 et MS16-126 (concernant Internet explorer notamment), comme le confirme la KB suivante : https://support.microsoft.com/en-us/kb/3200006

Il ne vous reste plus qu’à appliquer sur les machines hébergeant vos consoles SCOM (serveurs SCOM, postes d’administration, serveurs Citrix…) le hotfix proposé.

Attention, ce hotfix n’est pas spécifique à SCOM et sa dénomination dans le catalogue Microsoft peut donc être trompeuse : il s’agit par exemple de “Mise à jour pour Internet Explorer 11 pour Windows Server 2012 R2 (KB3200006) “ dans le cas du hotfix pour Win 2012 R2.

L’installation de ce hotfix ne nécessite normalement pas de redémarrage, mais si le problème persiste après l’installation cela aidera à le résoudre définitivement.

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 !)

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 :

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…).

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.

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

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

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 !

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) :

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

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

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) :

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 :

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

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

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) :

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 :

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 :

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

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

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

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 )

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 :

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

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.

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 :)

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 :

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.

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!

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 :

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 :

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

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 :

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 :

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 :

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

}

}

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.

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 :

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 :

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) :

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) :

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 :

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

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.

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

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

Cliquez sur Set

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 :

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.

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"

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

Ouvrez la configuration des Connection Strings

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

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"

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

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) :

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

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 :