Blog de Florent Appointaire

Blog sur les technologies Microsoft (Windows Server, System Center, Azure, Windows Azure Pack/Azure Stack, etc;)
    • 29/5/2014

    [Azure] SAP est maintenant supporté

    windows-azure


    Microsoft a officiellement annoncé le 28 Mai la certification de Azure pour SAP ainsi que le support, pour le public.

    Vous pouvez continuer à utiliser vos licences SAP pour déployer SAP sur Azure.

    Plus d’informations ici : http://azure.microsoft.com/en-us/campaigns/sap/

    • 27/5/2014

    [VMM 2012 R2] Le déploiement bare-metal est lent lors de la copie des drivers

    SCVMM_logo

    Microsoft a publié un KB concernant la copie de driver qui peut prendre du temps lors d’un déploiement bare-metal avec System Center Virtual Machine Manager 2012 R2. Ce KB2965415 propose un work around en attendant la sortie d’un patch correctif :

    To work around this issue, reduce the number of driver packages that you're deploying to a minimum number of files. This may involve configuring the physical computer profile by setting the driver filter to Filter drivers with matching PnP IDs. By doing this, you make sure that only those drivers that match the Plug and Play (PnP) IDs on the target physical computer are used.

    Source : http://support.microsoft.com/kb/2965415/en-us

    • 26/5/2014

    [SCOM 2012 R2] Créer un Dashboard en incluant Google Map

    SCOM2012

    Tao Yang, un SCOM user, a publié un poste assez fun concernant la mise en place d’un Dashboard avec géolocalisation sur Google Map (la même chose est possible avec Bing). Ceci est possible uniquement avec la version UR2 de SCOM 2012 R2 car celui-ci s’appuye sur une nouveauté de l’UR2, le widget PowerShell Grid View. Au final, en suivant le tutoriel proposé, vous aurez un Dashboard semblable à celui-ci :

    image15

    Plutôt sympa non? :-)

    Le lien vers le poste : http://blog.tyang.org/2014/05/24/opsmgr-dashboard-fun-google-maps/

    • 21/5/2014

    [UPDATE][System Center 2012 R2] L’UR2 pour DPM n’est plus disponible

    SysCtrR2

    Microsoft a retiré l’update rollup 2 de System Center 2012 R2 Data Protection Manager du téléchargement. Pour cause, plusieurs problèmes ont été remontés, notamenet sur la partie sauvegarde et restauration sur un disque de type tape. Le problème a été trouvé, et il est en partie fixé, c’est pourquoi, Microsoft mettra à jour l’UR2 pour DPM rapidement.

    Si vous avez déjà installé cet update, il faut que vous contactiez le support Microsoft.

    L’annonce officiel : http://support.microsoft.com/kb/2958100/en-us

    UPDATE au 21 Mai 2014 : Microsoft a republié l’UR2 pour DPM 2012 R2. Vous pouvez le retrouver ici : http://support.microsoft.com/kb/2963543

    • 14/5/2014

    [System Center 2012] Script de déploiement de System Center 2012 R2 avec interface graphique

    SysCtrR2

    Je vous avais parlé au mois de Février d’un script de déploiement de System Center 2012 R2. Benedict Berger, MVP Virtual Machine, vient de publier un script PowerShell qui permet de configurer les variables via une interface graphique, qui est elle aussi en PowerShell.

    image

    Grâce à cette interface, vous allez pouvoir créer le fichier Variable.xml de façon très simple et rapide. Il y a également une vérification des fichiers de configuration, pour optimiser le déploiement.

    Vous pouvez télécharger ce script ici : http://gallery.technet.microsoft.com/PDT-GUI-for-Powershell-6908b819

    • 13/5/2014

    [SCO 2012] Valeur NULL dans les propriétés d’un lien

    sc-orchestrator-logo

    Si vous avez besoin dans un lien d’indiquer un valeur NULL, il vous suffit d’utiliser les 2 caractères suivants dans les propriétés du lien, qui signifieront NULL :

    ^$

    Dans mon cas, je devais passer à la condition suivante que si la propriété ComputerName n’était pas vide :

    image

    En espérant que Microsoft ajoute une valeur Is NULL dans les prochaines versions :)

    • 9/5/2014

    [SCO 2012] Sauvegarder vos Runbooks automatiquement

    sc-orchestrator-logo

    On m’a demandé de trouver une solution pour sauvegarder les Runbooks Orchestrator de façon automatique.

    Après quelques recherches, j’ai découvert que l’on pouvait sauvegarder les Runbooks de deux façons :

    • En PowerShell
    • Avec un IP spécial

    Je vais parler ici de la sauvegarde avec l’integration pack. Pour la sauvegarde PowerShell, je ferai un article une fois que j’aurai testé.

    Cette integration pack se nomme SCORCH Administration Integration Pack et il est disponible au téléchargement ici. Au moment où j’écris ce poste, c’est la version 2.2 qui est disponible.

    Une fois le module téléchargé et installé, vous devriez voir apparaître dans votre console Orchestrator l’integration pack, comme ceci :

    image

    Dans un premier temps, il faut configurer le compte qui fera l’export. Ce compte doit être administrateur local de la machine qui a le rôle Management Server (le Runbook doit être exécuté sur cette machine) et faire parti du groupe OrchestratorUsersGroup. Une fois ceci en place, cliquez dans le Runbook Designer sur Options > SCORCH Dev – Orchestration Administration. Vous devriez avoir ceci :

    image

    Ouvrez ensuite la connexion et remplissez avec l’utilisateur précédant ainsi que le mot de passe et le domaine :

    image

    Cliquez sur OK et Finish.

    Pour lancer l’export, dans un nouveau Runbook, insérez l’élément Export Runbook Folder et ouvrez le pour le configurer. Ici, 2 paramètres sont obligatoires :

    • Runbook Path, qui contiendra le chemin du/des Runbook à sauvegarder
    • Save Path, qui contiendra le chemin où sera sauvegarder le fichier d’export

    Vous pouvez ajouter les paramètres optionnels si bon vous semble. Pour ma part, j’ai rajouter le fichier Overwrite Existing Export File pour écraser les sauvegardes. Rien de vous empêche de faire du versioning en modifiant le nom du fichier d’export avec la date par exemple. J’arrive donc au résultat suivant :

    image

    Pour information, la partie Runbook Path commencera toujours par Policies\ et ensuite, vous devez préciser le chemin du dossier à sauvegarder. A noter qu’il est impossible de sauvegarder la partie root et tous les dossiers descendants pour le moment. Une fois ceci fait, exécutez le Runbook. Pour ma part, j’ai rajouté un objet de type Schedule qui se lancera une fois par jour :

    image

    On peut voir que l’export s’est bien déroulé. Vérifions maintenant dans le dossier C:\Temp :

    image

    Votre export est fini, vous pouvez le réimporter quand vous le souhaitez. Bon courage.

    • 8/5/2014

    [SCOM 2012] Auto-signer ses certificats Unix

    SCOM2012

    Si au moment de la découverte d'un objet de type Unix vous rencontrez l'erreur suivante :

    Certificate signing operation was not successful
    Task invocation failed with error code -2130771918. Error message was: The SCXCertWriteAction module encountered a DoProcess exception. The workflow "Microsoft.Unix.Agent.GetCert.Task" has been unloaded.
    Module: SCXCertWriteAction
    Location: DoProcess
    Exception type: ScxCertLibException
    Exception message: Unable to open root store
    ; {Access is denied.
    }

    Additional data: -----BEGIN CERTIFICATE-----
    MIIDVjCCAj4CAQEwDQYJKoZIhvcNAQEFBQAwZzEYMBYGA1UEAxMPU0NYLUNlcnRp
    pMq4Opta+a51/NAigZ02p1SEUGYIpbfpyiR1HVmBpg58ECqw1uh4X6RWyUvqj2AO
    cuEVRTt2axEMLyn/W80mm/svWIqSLwY1I9Sl7gbdDwh6NlWdwA7JGy0MvqaYJ+rv

    26u/5gXcYRpU1emwg4JlcpfwdpRCLjllG9tcUO50bjq3mo2LyI3oDvXo+o9AnLe1
    0A/C6g/4X0ZmokUEsDfP0jZm+fourkS1v0cItWLDUH1ATG4nhqpZ3fpl

    -----END CERTIFICATE-----

    Management group: XXXXXXXX
    Workflow name: Microsoft.Unix.Agent.GetCert.Task
    Object name: All Management Servers Resource Pool
    Object ID: {4932D8F0-C8E2-2F4B-288E-3ED98A340B9F}

    Vous pouvez auto-signer votre certificat pour pouvoir resynchroniser l’agent avec votre serveur.

    Pour faire ceci, téléchargez le certificat du serveur en question qui se trouve dans /etc/opt/microsoft/scx/ssl et qui se nomme scx-host-hostname.pem. Pour ma part, j’ai téléchargé le certificat du nom de scx-host-jee01.pem avec WinSCP.

    Transférez ensuite ce certificat sur votre serveur SCOM. Ouvrez ensuite une invite de commande et déplacez vous dans C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server, lieu où se trouve scxcertconfig.exe, logiciel qui va nous permettre de signer notre certificat. Tapez ensuite la commande suivante :

    scxcertconfig.exe –sign C:\Temp\scx-host-jee01.pem c:\Temp\new-certificate-jee01.pem

    image

    image

    Renommez le nouveau certificat avec le nom de l’ancien certificat et transférez le sur le serveur Unix.
    Redémarrez ensuite le service scxadmin sur le serveur Unix pour que le nouveau certificat soit pris en compte :

    scxadmin –restart

    image

    Vous pouvez maintenant relancer l’installation de l’agent SCOM sur le serveur Unix depuis SCOM. Vous ne devriez plus avoir de message d’erreur et votre serveur doit maintenant être supervisé.

    • 7/5/2014

    [SCSM 2012] Le self Service portal supporté sur Windows Server 2012 et 2012 R2

    1222.SCSM_2012

    Microsoft vient d’annoncer que SharePoint 2010 SP2 est maintenant supporté sur Windows Server 2012 et Windows Server 2012 R2. Ceci est dans le KB 2724471 :

    Before the release of Service Pack 2 (SP2) for Microsoft SharePoint Server 2010, Microsoft did not support SharePoint Server 2010 in a Windows Server 2012 or Windows Server 2012 R2 environment.
    However, SharePoint Server 2010 with SP2 has now been released, and this configuration is supported in Windows Server 2012 and Windows Server 2012 R2.
     

    Ce qui signifie que le Self-Service Portal de System Center Service Manager SP1 et System Center Service Manager R2 peut maintenant être installé sans aucun souci sous Windows Server 2012 et 2012 R2. Pratique pour les entreprises qui veulent se débarrasser de Windows Server 2008 R2 et moins.

    Pour télécharger le SP2 de SharePoint 2012, c’est ici pour la version Foundation et ici pour la version complète.

    Source : http://blogs.technet.com/b/servicemanager/archive/2014/05/05/service-manager-now-supports-sharepoint-2010-service-pack-2.aspx

    • 7/5/2014

    [SCOM 2012 R2] Déplacer la base de données

    SCOM2012

    Il y a peu de temps j’ai du déplacer les bases de données de SCOM d’un serveur à un autre. Le nom du nouveau serveur de la base de données était différent de l’ancien (SQL01 pour l’ancien et SQL02 pour le nouveau). Pour informations, cette migration a été effectuée sous SCOM 2012 R2, il se peut donc qu’il y ait quelques changements suivant votre version.

    J’ai trouvé cette procédure sur TechNet qui permet d’effectuer l’opération pour la base de données opérationnelle et celle-ci pour la Data Warehouse.

    Dans un premier temps, il faut arrêter les services SCOM suivants pour SCOM 2012 SP1 :

    • System Center Data Access Service
    • System Center Management
    • System Center Management Configuration

    Dans mon cas, SCOM 2012 R2 :

    • Microsoft Monitoring Agent
    • System Center Data Access Service
    • System Center Management Configuration

    Pour plus d’informations sur les différences de nom entre les service : http://stefanroth.net/2013/07/01/quick-post-scom-2012-r2-new-windows-service-names/

    Il faut ensuite créer une sauvegarde FULL des bases de données à migrer (OperationsManager & OperationsManagerDW). J’ai effectué ces sauvegardes avec SQL Server Management Studio (http://technet.microsoft.com/en-us/library/ms187510.aspx). Une fois les sauvegardes terminées, il faut les déplacer sur le nouveau serveur de base de données, dans mon cas SQL02. Il faut ensuite restaurer ces bases, sur le nouveau serveur. J’ai de nouveau effectué cette opération avec SQL Server Management Studio (http://technet.microsoft.com/en-us/library/ms177429.aspx).

    Il faut maintenant retourner sur le serveur SCOM pour modifier la base de registre. N’oubliez pas d’effectuer une sauvegarde de la clé que vous allez modifier. Dans la console éditeur de registre, déplacez-vous jusqu’à la clé suivante :

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Setup

    Ici, il faut modifier les clés suivantes avec le nouveau nom de votre serveur. Attention, si votre serveur contient plusieurs instances, vous devrez nommer sous la forme ServerName\Instance :

    • DatabaseServerName
    • DataWarehouseDBServerName

    image

    Modifiez également la clé Reporting avec le nom DWDBInstance.

    Il faut maintenant modifier le fichier ConfigService.config qui se trouve dans %ProgramFiles%\Microsoft System Center 2012 R2\Operations Manager\Server\ sur chaque management serveur. Une fois ce fichier ouvert, cherchez <Category Name="Cmdb">  et modifiez la valeur du premier Setting avec le nouveau nom de votre serveur :

    image

    Faites de même avec le paramètre suivant, <Category Name="ConfigStore"> :

    image

    Une fois ceci fait, nous allons mettre à jour la base de données avec le nom du nouveau serveur. Vous avez 2 façons, soit en SQL, soit avec l’interface graphique de SQL. J’aborderai ici les 2 méthodes.

    Avec interface graphique :

    Dans SQL Server Management Studio de votre nouveau serveur, ouvrez Databases > OperationsManager > Tables et cherchez la table suivant, dbo.MT_Microsoft$SystemCenter$ManagementGroup et faites clique droit dessus, puis Edit Top 200 Rows. Vous devriez avoir ceci :

    image

    Changez le nom du serveur de la colonne SQLServerName_43FB076F_7970_4C86_6DCA_8BD541F45E3A avec le nouveau nom :

    image

    Sauvegardez et faites de même avec la table dbo.MT_Microsoft$SystemCenter$OpsMgrDB$AppMonitoring et la colonne MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A.

    Pour la base OperationsManagerDW, modifiez la table dbo.MT_Microsoft$SystemCenter$DataWarehouse et la colonne MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F mais aussi la table dbo.MT_Microsoft$SystemCenter$DataWarehouse$AppMonitoring avec la colonne MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A, la table dbo.MT_Microsoft$SystemCenter$DataWarehouse$AppMonitoring_Log avec la colonne Post_MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A et la table dbo.MT_Microsoft$SystemCenter$DataWarehouse_Log avec la colonne Post_MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F avec le nom de votre nouveau serveur SQL.

    En SQL :

    USE OperationsManager
    GO
    UPDATE dbo.MT_Microsoft$SystemCenter$ManagementGroup
    SET SQLServerName_43FB076F_7970_4C86_6DCA_8BD541F45E3A = 'SQL02'
    WHERE SQLServerName_43FB076F_7970_4C86_6DCA_8BD541F45E3A = 'SQL01'

    USE OperationsManager
    GO
    UPDATE dbo.MT_Microsoft$SystemCenter$OpsMgrDB$AppMonitoring
    SET MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A = 'SQL02'
    WHERE MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A = 'SQL01'

    USE OperationsManager
      GO
    UPDATE dbo.MT_Microsoft$SystemCenter$DataWarehouse
      SET MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F = 'SQL02'
      WHERE SMainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F = 'SQL01'

    USE OperationsManager
      GO
      UPDATE dbo.MT_Microsoft$SystemCenter$DataWarehouse$AppMonitoring
      SET MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A = 'SQL02'
      WHERE MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A = 'SQL01'

    USE OperationsManager
      GO
    UPDATE dbo.MT_Microsoft$SystemCenter$DataWarehouse$AppMonitoring_Log
      SET Post_MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A = 'SQL02'
      WHERE Post_MainDatabaseServerName_5C00C79B_6B71_6EEE_4ADE_80C11F84527A = 'SQL01'

    USE OperationsManager
      GO
      UPDATE dbo.MT_Microsoft$SystemCenter$DataWarehouse_Log
      SET Post_MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F = 'SQL02'
      WHERE Post_MainDatabaseServerName_2C77AA48_DB0A_5D69_F8FF_20E48F3AED0F = 'SQL01'

    Modifiez maintenant la table dbo.MemberDatabase de la base OperationsManagerDW. Changez la valeur de la colonne ServerName avec le nom du nouveau serveur SQL.

    USE OperationsManagerDW
    GO
    UPDATE dbo.MemberDatabase
    SET ServerName = ‘SQL02’
    WHERE ServerName = ‘SQL01’

    Il faut maintenant appliquer les sécurités SQL sur les bases. Dépliez Security > Logins et ajouter le compte écriture de données, dans mon cas svc-omwrite et celui en lecture, dans mon cas svc-omreader. Mapper ces 2 comptes avec les 2 bases de données. Ajoutez le compte d’action, dans mon cas svc-ommgmt. Ajoutez aussi le compte ordinateur qui a le service Data Access Service (SCOM01 dans mon cas) et ajoutez lui les droits suivants dans SQL sur la base OperationsManager :

    • ConfigService
    • db_accessadmin
    • db_datareader
    • db_datawriter
    • db_ddladmin
    • db_securityadmin
    • sdk_users
    • sql_dependency_subscriber

    Et sur la base OperationsManagerDW :

    • db_datareader
    • OpsMgrReader
    • apm_datareader

    Exécutez maintenant les commandes SQL suivantes sur la base de données OperationsManager :

    sp_configure ‘show advanced options’,1
    reconfigure
    sp_configure ‘clr enabled’,1
    reconfigure

    Exécutez ensuite la commande suivante :

    SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'

    Si la valeur retournée de is_broker_enabled est égale à 1, alors ignorez l’étape suivante, sinon, faites ceci :

    image

    ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    ALTER DATABASE OperationsManager SET ENABLE_BROKER
    ALTER DATABASE OperationsManager SET MULTI_USER

    Vous pouvez maintenant redémarrer les services SCOM que vous aviez arrêter et vérifier que tout fonctionne correctement, notamment en vous rendant dans la partie Administration et en regardant l’étant de votre ou vos management serveur.

    Si vous avez des questions, n’hésitez pas.

    • 5/5/2014

    [SCVMM 2012 R2] Créer un cluster VMM

    6215_scvmm2012_logo.png-550x0

    Aujourd’hui, je vais vous présenter comment créer un cluster de System Center Virtual Machine Manager.

    Dans un premier temps, je vais créer 2 VMs (Windows Server 2012 R2), qui me serviront à créer ce cluster. Une fois que les VMs sont déployées, il faut créer le cluster Windows. Je n’aborderai pas cette partie dans ce tutoriel. Une fois que le cluster est créé, installez le Windows ADK 8.1 que vous pouvez télécharger ici avec les options suivantes :

    • Deployment Tools
    • Windows Preinstallation Environment

    image

    Une fois ceci fait, il vous faut un serveur qui hébergera la base de données. Dans mon cas, j’ai créé une VM SQL où la base de données sera hébergée. Attention, pour que le cluster soit efficace, n’hébergez pas la base de donnée en local sur l’une ou l’autre des VMs du cluster.

    Pour résumer, j’ai 3 VMs et un cluster :

    • SQL01
    • VMM02
    • VMM03
    • VMMCL01

    Nous pouvons commencer l’installation de notre cluster VMM. Insérez le CD de VMM 2012 R2 dans une VM et ouvrez le setup :

    image

    Cliquez sur Install. Une nouvelle fenêtre apparaît. Cochez la case VMM management server. VMM détecte que l’installation est lancée sur un Cluster. Cliquez sur Yes pour créer le cluster VMM puis Next :

    image

    Donnez un nom et une clé produit et cliquez sur Next :

    SNAGHTMLa0f6c9

    Acceptez la licence et cliquez sur Next :

    image

    Choisissez si vous souhaitez participer au CEIP et cliquez sur Next :

    image

    Choisissez si vous souhaitez installer les mises à jour automatiquement ou non et cliquez sur Next :

    image

    Choisissez où vous souhaitez installer VMM et cliquez sur Next :

    image

    Vérifiez qu’il n’y a pas de prérequis qui vous bloque et cliquez sur Next :

    image

    Choisissez ensuite où la base de données va être stockée et cliquez sur Next :

    SNAGHTMLa5a064

    Donnez ensuite un nom à votre cluster ainsi qu’une adresse IP et cliquez sur Next :

    SNAGHTMLa72bb7

    Ici vous n’avez d’autre choix que de fournir un compte de domaine. Ceci est normal, car si une machine du cluster s’éteint, le service doit pouvoir continuer à tourner. Attention, le compte de service doit être administrateur local des serveurs VMM du cluster :

    SNAGHTMLa8780d

    Pour la partie Distributed Key Management, il va y avoir quelques manipulation à effectuer sur l’AD. En effet, pour créer un cluster VMM, il faut stocker la clé d’encryption dans l’AD pour qu’elle soit accessible par tous les serveurs du cluster VMM. Pour configurer le stockage de cette clé, nous sommes renvoyés vers un article Technet. Pour commencer, il faut créer un conteneur dans l’AD. Ouvrez ADSI Edit sur votre DC et connectez-vous à votre Default naming context. Naviguez ensuite jusqu’à l’endroit où vous voulez stocker le conteneur et faites clique droit, New > Object. Ici, choisissez container et cliquez sur Next :

    image

    Donnez un nom au conteneur et cliquez sur Next :

    image

    Cliquez sur Finish :

    image

    Cliquez droit sur le conteneur que vous venez de créer et sur Properties. Allez dans l’onglet Security :

    SNAGHTMLb1cd55

    Il faut donner les droits suivants au compte qui a lancé l’installation de VMM, dans mon cas, mon utilisateur est Florent :

    • Read all properties
    • Write all properties
    • Create all child objects

    Cliquez sur Advanced > Add et sélectionnez l’utilisateur. Attribuez les permissions citées précédemment et cliquez sur OK 3 fois :

    SNAGHTMLb627e5

    Retournez sur le serveur VMM où l’installation est lancé, et donnez le DN du conteneur que l’on vient de créer et cliquez sur Next :

    SNAGHTMLb90480

    Choisissez les ports à utiliser pour VMM et cliquez sur Next :

    image

    A l’étape suivante, il est dit que nous devrons créer la librairie VMM après que l’installation soit terminée. Cliquez sur Next :

    image

    Vérifiez les informations que vous avez fourni, et si tout est bon, cliquez sur Install :

    SNAGHTMLbd68e4

    L’installation s’est bien déroulée :

    image

    Pour vérifiez, connectez-vous à la console depuis le serveur qui a reçu l’installation :

    SNAGHTMLd49db

    Vous pouvez également voir qu’un rôle est apparu dans la console Failover Cluster :

    SNAGHTMLe48fb

    Et que dans la console ADSI Edit, des nouveaux conteneurs ont été créés :

    SNAGHTMLf8880

    Si vous essayez de migrer le rôle sur l’autre nœud, vous aurez une erreur. Ceci est normal, il faut installer le management serveur sur ce deuxième serveur. Insérez le CD dans le deuxième serveur et lancer le setup pour ajouter ce serveur en temps que possible propriétaire du nœud. Sélectionnez VMM management server. Un message apparaît pour vous dire que VMM est déjà installé, et que vous pouvez ajouter ce serveur comme nœud. Cliquez sur Yes :

    image

    Complétez l’installation jusqu’à la fin. Une fois l’installation terminée, il nous reste à tester le Failover. Pour tester, je vais bouger le rôle sur mon serveur secondaire et je vais arrêter le troisième serveur :

    SNAGHTML29dc6e

    SNAGHTML2aa29c

    Depuis le deuxième serveur, je peux continuer à travailler sur VMM, sans perdre aucune donnée :

    SNAGHTML2bc16a

    Préférez l’utilisation du nom du cluster pour vous connecter à la console VMM.

    Ce tutoriel est terminé, si vous avez des questions, n’hésitez pas.

    • 1/5/2014

    [SCOM 2012] Le management pack de SQL Server 2014 est disponible

    SCOM2012_3B971CA9

    Microsoft vient de publier le Management Pack de SQL Server 2014 pour SCOM 2007 R2, 2012 et 2012 R2. Il est compatible avec Windows Server 2008 R2 SP1 et plus.

    Pour retrouver la liste complete de ce qui est superviser et pour télécharger ce Management Pack, vous pouvez vous rendre ici : http://www.microsoft.com/en-us/download/details.aspx?id=42573