Accueil > SCCM > SCCM – Troubleshooting avancé et la boule de Cristal

SCCM – Troubleshooting avancé et la boule de Cristal

sccm2012Bonjour à tous,

Je fais ce post, vite fait pour vous relater un problème que j’ai rencontré avec ConfigMgr 2007 (SCCM). Et notamment, avec le rôle Management Point versus PXE. Nous avons un serveur Central SCCM (hébergeant aussi la base SQL) et un serveur dédié pour les rôles de PXE, Distribution Point et State Migration Point.

Quant au Central, celui-ci possède les rôles habituels, et notamment le rôle de Management Point.

CONTEXTE/ISSUE
Nous avions déplacé temporairement, le rôle Management Point sur le serveur dédié (PXE, etc.), dans le but de corriger un problème IIS sur le serveur d’origine (Central). Et notamment, concernant la configuration de BITS sur le répertoire CCM_Incoming (Error 500 httpSendRequest)…

Au passage, je vous donne la procédure pour réinstaller Microsoft IIS sur SCCM :

http://blogs.technet.com/b/configurationmgr/archive/2009/08/12/configmgr-2007-how-to-properly-reinstall-iis-in-windows-server-2008-on-an-sccm-2007-site-system.aspx

Là, aucun problème, tous les services SCCM raccrochent les informations, et considèrent correctement le nouveau serveur Management Point comme acquis et fonctionnel sur le serveur dédié (PXE, etc.)

Une fois le problème IIS corrigé sur le serveur, nous avons, bien sûr voulu rebasculer le rôle MP sur son serveur d’origine. Et là problème ! Ce qui s’était bien passé la 1ère fois sur le serveur temporaire, s’est mal passé la deuxième fois (Apparemment), lorsque nous avons remis le rôle à sa place. nous nous sommes pas aperçu tout de suite :

La particularité de ce problème, c’est qu’une fois le rôle MP réinstallé sur le serveur d’origine (Central), le fichier de LOG : MPControl.log fait un Code Retour 200 OK dans son autocheck httpSendRequest !! Si on consulte les fichiers de LOG IIS, même chose ! Code Retour 200 !

Malgré tout impossible de déployer une Task Sequence de déploiement de Windows Seven !!

ANALYSES
Après avoir consulté le fichier Log : MPSetup.log, je ne vois aucune erreur, hormis l’installation du fichier MSI. Erreur que j’avais résolu par une réinstallation du rôle MP, pour corrigé le problème. Ceci avait d’ailleurs fonctionné, raison d’ailleurs pour laquelle je n’avais aucune erreur dans le fichier de Log : MPSetupl.log qui se terminait bien par : Installation Successfully.

Mais malgré tout, le rôle Management Point ne fonctionnait plus, et ceci malgré ce que pouvaient dire les fichiers de Logs d’IIS de SCCM (MPControl.log), etc. Je ne parle pas de la console qui reste muette sur le sujet … “Tout est vert, il fait beau, 25 degrés à l’ombre, bref ! Rien à signaler !

Donc je décide d’investiguer côté poste de travail : Le symptôme sur les postes de travail était le suivant : Les postes démarrent bien en mode PXE, chargent bien l’image de démarrage WINPE, mais redémarrent brusquement au bout de 60 secondes, voir moins (Et ceci malgré une console DOS (F8) ouverte). Malgré tout, nous arrivons a récupérer le fichier Log : SMSTS.Log et là l’erreur fait son apparition : No MP Certificates

Une rapide analyse m’envoie vers le fichier de Log : SMSPXE.log. Dans celui-ci, je vois que le serveur Management Point, ainsi que la clé de sécurité (le fameux Certificat) ne sont plus renseignés :

Loaded PXE settings from DB: Default MP: <empty>, Public Certificates: <empty>

ACTIONS DE CORRECTIONS
1 – Je décide donc, de redémarrer le service PXE Service Point (WDS) sur le serveur, afin de forcer le rôle PXE à lire dans la base, les informations concernant le Management Point, afin qu’il met à jour la nouvelle condition du dit rôle ! Rien à faire. Les données ne sont toujours pas renseignées !

2 – Je décide donc d’installer le Rôle PXE (Moins impactant que le rôle MP, sachant qu’on est en production). Même chose ! Aucun effet ! Les données restent vides ! Les services sont inopérants !

Donc par déduction, le problème, vient à coup sûr du Management Point ! De plus, entre-temps, on m’annonce que toutes les télédistributions d’applications sont arrêtées. Les clients n’ont plus accès aux publications !! Bonjour la pression ! Bref ! Quoi qu’il en soit, cela me conforte dans l’idée que le problème vient bien du Management Point sur le Central. Je décide donc de désinstaller celui-ci du serveur Central.

Mais avant… Une rapide recherche chez Microsoft, pour savoir si le problème est référencé ! Et je retrouve la KB et la procédure que j’avais faite pour corriger le problème d’installation du MSI : http://support.microsoft.com/kb/2419559/fr-fr

[… As of right now, the easiest way to resolve this issue is to remove and reinstall the BITS component. If the ConfigMgr 2007 Management Point role was already installed then it will also be necessary to remove and reinstall that role once you’ve done the same with BITS…]

3 – Je ré-applique donc la procédure, malgré que mon installation MP.MSI se soit bien passée la 1ère fois et que du point de vue de SCCM, le rôle Management actuel, fonctionne !

Sans surprise, la procédure se passe correctement, le Management Point revient en [Status 200 OK] dans MPControl.log, idem dans les fichiers de Logs de Microsoft IIS du Central… Le tout est de savoir ce que fait le PXE derrière ! Bah il fonctionne !!! Les champs sont renseignés. Je retrouve le nom FQDN de mon Management Point, ainsi que sa clé de Sécurité (Certificat).

Loaded PXE settings from DB: Default MP: SERVER.EVENT-HORIZON.FR, Public Certificates: 308201E63082014FA00302010202109326C3F7A4B9D2934497E…

Je repousse les boot images sur le serveur PXE (En conséquence de mes premières actions concernant PXE). Tout redevient comme avant ! Le déploiement OSD fonctionne à nouveau, ainsi que les publications d’applications !

Je voulais partager cette expérience avec vous, car cela vous donne un exemple de troubleshooting dans SCCM, dans lequel il n’est pas toujours évident de diagnostiquer un problème quand les logs ne reflètent par l’état réel des services SCCM, Et c’est encore moins facile quand la console SCCM reste muette comme un carpe !

Pour finir, dans l’histoire, je ne suis pas sûr que le réel problème vienne de Microsoft IIS. Je pense à quelque chose de plus profond, lié au socle et à un manque de stabilité du serveur. Je pense que le problème de Microsoft IIS n’est qu’un symptôme. Problème qui nous a d’ailleurs obligé à réinstaller IIS dès le début de l’incident ; Que part effet domino, le reste à suivi, provoquant le bug… Bienvenu dans le monde SCCM ! 🙂

Enjoy !

Michel PICOLLET | EXAKIS Paris
Solution Architect Microsoft [System Center]
mpicollet@event-horizon.fr

  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :