Le blog technique

Les cumulatives updates sont les mises à jour dédiées à SharePoint qui sont publiées tous les 2 mois. Ces packages peuvent corriger des bugs apparus sur le produit SharePoint, comme ça peut être une évolution du produit, par exemple certaines commandes propres à SharePoint sont disponibles à la suite d’une publication d’un cumulative Updates.

Les cumulatives peuvent contenir des corrections mineures, elles peuvent aussi contenir des changements importants et dans ce cas on parle de Service Pack

Pour une bonne administration de SharePoint, il faut se tenir informé et consulter ces mises à jour tous les 2 mois sur le site officiel de Microsoft, bien prendre du recul par rapport aux mises à jour surtout lorsqu’elles sont importantes et surtout toujours les tester sur des plateformes de test avant de les déployer en production. Il faut valider leur interaction avec la plateforme déjà mise en place et personnalisée.

Format des packages Cumulatives Updates SharePoint

MOSS 2007 :

• CU pour WSS + CU pour MOSS 2007

SharePoint 2010 :

• CU SharePoint Foundation 2010
• CU pour SharePoint Foundation 2010 + SharePoint Server 2010
• CU pour SharePoint Foundation 2010 + SharePoint Server 2010 + Project Server 2010

Mode d’installation des packages de mises à jour :

1. MOSS 2007 :

• Plateforme à serveur autonome (unique) : installation et configuration du package CU pour WSS ensuite installation et configuration du package CU pour sharePoint.

· Plateforme multiserveurs :

• Les CUs pour WSS doivent être installés sur le serveur d’application qui héberge la console d’administration centrale en premier , il faut ensuite lancer le wizard de configuration, cette étape doit être mise en pause le temps de déployer les CUs pour WSS sur les serveurs frontaux, une fois ces CUs installés et configurés sur les serveurs frontaux, l’etape de configuration des CUs sur le serveur d’application peut être finalisée.
• Les CUs pour sharePoint doivent être installées à l’identique des CUs pour WSS expliqué ci-dessus.

2. SharePoint 2010

· Plateforme à serveur autonome (unique) :

Important : En raison du changement du mode de packaging, il n’est plus nécessaire d’installer les CU de SharePoint Foundation puis les CU de SharePoint Server.

• De ce fait et selon le package de CU choisi suivant le type de produit SharePoint déployé sur la plateforme SharePoint, il faut lancer l’installation ensuite la configuration du CU sur cette dernière.

· Plateforme multiserveur :

Comme expliqué ci-dessus, suivant le produit SharePoint déployé sur la plateforme, il faut installer les CUs correspondants dans l’ordre suivant :

• Installation des CU sur le serveur d’application qui héberge la console d’administration centrale en premier,
• Installation des CU sur le(s) serveur(s) d’application
• Vérifier que les mises à jours ce sont correctement installées
• Arrêter le load balancing entre les serveurs frontaux
• Installer les CUs sur les serveurs frontaux un par un
• Vérifier que les mises à jour ce sont correctement installées
• Lancer le wizard de configuration sur le serveur d’application qui héberge la console d’administration centrale
• Lancer le wizard de configuration sur le reste des serveurs d’application
• Lancer le wizard de configuration sur les serveurs frontaux un par un

Une fois les CUs installées et configurées, il faut vérifier que la version de SharePoint correspond à celle attendue et publiée par Microsoft.

Microsoft ayant pris la décision de ne pas assurer la compatibilité de la console “lourde” SCOM 2012 avec Windows XP, il n’est plus possible de l’installer sur des ordinateurs exécutant encore ce système.

Toutefois, il peut toujours s’avérer nécessaire d’accéder à une console SCOM 2012 depuis un de ces ordinateurs et pour ce faire, la console Web semble être une solution parfaitement adaptée.

Malheureusement, une nouvelle mauvaise surprise vous attend : après avoir installé l’extension Silverlight SilvelightClientConfiguration.exe (proposée automatiquement à la première connexion) et tenté d’ouvrir une session, le message d’erreur suivant vous accueille et la console ne se charge pas :

The procedure entry point LocaleNameToLCID could not be located in the dynamic link library Kernel32.dll.

Cette erreur se produit car l’API LocaleNameToLCID n’est présente dans Kernel32.dll qu’à partir de Windows Vista (cf. http://msdn.microsoft.com/en-us/library/windows/desktop/dd318711%28v=vs.85%29.aspx ). Décidemment, cette console refuse de s’ouvrir sous Windows XP…

A l’aide de l’outil Procmon, on constate que SilverlightClientConfiguration.exe doit normalement créer des entrées dans la base de registre, correspondant à des certificats propres à SCOM 2012 et SCOM 2012 UR1 respectivement.

Il est donc possible de contourner le problème en important directement ces entrées dans la base de registre via le fichier OM2012WebConsoleFix.reg (disponible ici : http://blogs.technet.com/b/mihai/archive/2012/05/08/making-the-om-2012-web-console-accessible-from-a-windows-xp-client.aspx ), sans passer par SilverlightClientConfiguration.exe.

Il est cependant vraisemblable que les futures mises à jour de la console Web induiront des certificats différents.
Afin de pouvoir les retrouver (sur un client Vista ou supérieur) pour les exporter et les réimporter sur vos clients Windows XP, il est intéressant de noter que la clé de registre utilisée est HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Silverlight pour les Windows 64bits et HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Silverlight pour le Windows 32bits ainsi que HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\TrustedPublisher\Certificates\19F8F76F4655074509769C20349FFAECCECD217D dans tous les cas.

Une fois cette modification apportée au registre, la console Web SCOM 2012 est accessible sans avoir besoin d’installer SilverlightClientConfiguration.exe ni nécessiter de redémarrage.

Suite au déploiement manuel de l’agent SCOM sur des contrôleurs de domaine Active Directory d’un domaine distant, les alertes de type “script based test failed to complete” suivantes peuvent apparaitre :

AD Lost And Found Object Count : The script ‘AD Lost And Found Object Count’ failed to create object ‘McActiveDir.ActiveDirectory’. This is an unexpected error.
The error returned was ‘ActiveX component can’t create object’ (0x1AD)

AD Replication Monitoring : encountered a runtime error.
Failed to create the ‘McActiveDir.ActiveDirectory’ object.
The error returned was ‘ActiveX component can’t create object’ (0x1AD)

Cette erreur se produit car il manque un composant de supervision spécifique aux Contrôleurs de Domaine, nommé AD Helper Object. Ce dernier s’installe automatiquement et de façon transparente lors du déploiement de l’agent via une installation « push », mais pas lors d’une installation manuelle (cas d’un serveur situé derrière un firewall par exemple).

Il est donc nécessaire d’installer ce composant à la main également, à l’aide du package oomads.msi disponible sur le média d’installation de SCOM dans le dossier HELPEROBJECTS :

Copier le package oomads.msi correspondant à l’infrastructure matérielle du contrôleur de domaine (I386 pour les Windows 32 bits ou AMD64 pour les Windows 64bits) sur le contrôleur de domaine qui remonte l’erreur, puis l’y installer.
L’installation ne requiert aucune intervention et affiche l’écran suivant une fois terminée :

L’alerte devrait alors cesser de remonter, sans nécessiter de redémarrage.