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/

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

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 :

Plutôt sympa non? :-)

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

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

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.

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

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 :

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

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 :

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 :

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

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 :

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 :

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

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

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

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

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é.

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

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

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 :

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

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 :

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

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 :

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.

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

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 :

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 :

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

Acceptez la licence et cliquez sur Next :

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

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

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

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

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

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

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 :

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 :

Donnez un nom au conteneur et cliquez sur Next :

Cliquez sur Finish :

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

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 :

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 :

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

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 :

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

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

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

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

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

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 :

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 :

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

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.

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