Archive

Posts Tagged ‘Troubleshooting’

SCCM – Impossibilité de publier les images de boot sur un serveur, point de distribution, si celles-ci sont déjà présentes dans le PXE Et le répertoire SMSBoot\[x] reste vide)

septembre 30, 2012 1 commentaire

Bonjour à tous,sccm20124

Venant d’être confronté au problème, voici un post regroupant un ensemble d’actions qui m’ont permis de m’en sortir. A tester bien sûr !

Description du problème

1. Une fois les images boot marquées comme devant être utilisées et publiées sur le rôle PXE, il est impossible de les publier sur un serveur ayant le rôle de point de distribution.

clip_image002

2. Les répertoires x86 et x64 se trouvant dans le répertoire \RemoteInstall\ SMSBoot\ sont vides et ne possèdent pas les fichiers de démarrage, nécessaires au PXE.

Ce problème engendre un service PXE inopérant sur les postes de travail, rendant inopérant l’ensemble des déploiements de systèmes d’exploitation !

Actions de résolution

1. Supprimer vos images de boot du PXE
2. Supprimer vos images de boot de votre point de distribution (Même si la copie n’a pas fonctionné)
3. Décocher l’activation du « rôle » PXE sur votre point de distribution
4. Supprimer le rôle de point de distribution sur votre serveur
5. Désinstaller le rôle serveur WDS (Windows Deployment Service)
6. Redémarrer votre serveur (Anciennement DP\PXE)
7. Sauvegarder les répertoires suivants dans un endroit sûr sur votre serveur :

– SCCMContentLib
– SMSPKG*
– SMSSIG

    8. Une fois sauvegardés, supprimer les répertoires suivants de tous vos lecteurs :

– SMSPKG$
– SMSPKGx$
– S
MSPKGSIG
– SMSSIG$
– SCCMContentLib
– RemoteInstall

Vider le répertoire C:\Windows\Temp

    9. Bien vérifier bien que le fichier Tag : No_SMS_On_Drive.SMS est bien présent sur les lecteurs appropriés

Lire la suite…

Catégories :SCCM Étiquettes : , , , , , , , ,

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

SCCM – Troubleshooting in Microsoft System Center ConfigMgr 2007 and Overview of Software Distribution in Configuration Manager 2012 !

Bonjour à tous,

Pour finir en beauté !!!

… Arrivé tout droit du MMS 2011 de Stockholm : Deployment roadshow 2011

MMS 2011

Deux Vidéos, 2 thèmes :

Troubleshooting Configuration Manager 2007 OS Deployments
http://www.screencast.com/t/pgdgVVwBoGyF

– and –

Overview of Software Distribution in Configuration Manager 2012 
Sur YouTube avec Wally !

Part 1 : http://youtu.be/15wPybTZvjg

Part 2 : http://youtu.be/_kZf9gtUIkU

Source : http://www.deploymentresearch.com/Blog.aspx

Bonnes fêtes de fin d’année à toutes et à tous !! 🙂

Enjoy !

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

SCCM – Désinstallation de Microsoft WSUS, impossible !

logo-sccm-20072

Comment forcer la désinstallation un serveur WSUS récalcitrant ?

Suite à un disfontionnement du rôle Software Update Point sur un site secondaire SCCM, vous vous rendez compte que WSUS n’est pas en très bonne santé. Vous vous confirmez le problème en ouvrant la console MMC de WSUS. Impossible de se connecter à la base SUSDB et de contacter le serveur WSUS.

Après un certain nombre de vérifications, etc. (Cf. L’article suivant) vous vous rendez compte qu’il vous faut désinstaller WSUS. Après le retrait du rôle dans SCCM, vous lancez la désinstallation WSUS. Mais impossible d’aboutir ! L’assistant tombe sur une erreur fatale !

Il vous est donc impossible de continuer vos investigations de réparation. Même après un démarrage du dit serveur.

Lorsque vous consultez l’Event Log de Windows/Applications, vous constatez donc l’erreur 1001, et en consultant les fichiers de Logs, vous voyez l’erreur : 0x80070643

image

Deux actions sont à mener :

1 – Désinstallation manuellement la base MSDE
Passer en ligne de commande avec les droits d’administrateur Local, puis passer la ligne de commande en fonction de votre version d’OS (x86 ou x64)

Pour Microsoft Windows 2008 R2 x86
msiexec /x {CEB5780F-1A70-44A9-850F-DE6C4F6AA8FB} CALLERID=ocsetup.exe

Pour Microsoft Windows 2008 R2 x64
msiexec /x {BDD79957-5801-4A2D-B09E-852E7FA64D01} CALLERID=ocsetup.exe

2 – Modifier la clé de registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Update Services\Server\Setup
Mettre à 0 la valeur de la clé wYukonInstalled

Redémarrer la serveur si nécessaire…

Puis relancer la désinstallation de WSUS… Cela devrait passer !

Sources m’ayant aidé dans ma démarche :
http://support.microsoft.com/kb/920660
http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/9c565dbf-3c1f-4385-8daa-9cd049a5f322/

Enjoy !

PS : Je dédie ce post à mon amis et collégue, Gilles du Support d’EXAKIS

Michel PICOLLET | EXAKIS Paris
Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

Catégories :SCCM Étiquettes : , , , , , ,

SCCM – Rapports ACT 5.6, non-accessibles depuis la console SCCM (ACT Connector)

logo-sccm-20072

Bonjour à tous,

Voici un court post pour celles et ceux qui rencontreraient des problèmes pour visualiser les rapports ACT depuis la console SCCM :

image

Issue

Lorsque vous cliquez sur un rapport comme “Recommended System requirements”, une erreur de connexion à la base survient, stipulant un problème de droits et provoquant le message suivant :

‘The server principal "NT AUTHORITY\SYSTEM" is not able to access the database "[ACT]" under the current security context.’

Correction

Pour corriger ce problème, ouvrir une console SQL Management studio, cliquer sur New Query en ayant pris soin de sélectionner votre base ACT, puis exécuter la Query suivante et cliquer sur Execute :

GRANT CONNECT to guest
GRANT SELECT ON Application_Report_vw to guest
GRANT SELECT ON Applications_vw to guest
GRANT SELECT ON Machine_Installed_App_vw to guest
GRANT SELECT ON Machines_vw to guest
GRANT SELECT ON Deployment_OS_vw to guest

… Voici un screenshot pour vous guider

image

Le problème sera alors réglé !

Enjoy !

Michel PICOLLET | EXAKIS Paris
Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

Catégories :SCCM Étiquettes : , , , ,

SCCM – Impossible pour WSUS de synchroniser le catalogue des mises à jour Microsoft ou SUP inopérant

logo-sccm-20072

Bonjour à tous,

Vous avez des problèmes et constatez l’erreur suivante dans le fichier de Log : wsyncmgr.log

Sync failed: WSUS server not configured. Source: CWSyncMgr :: DoSync

Cependant, le fichier de contrôle WSUSCtrl.log vous indique que la connexion au service et à la base SQL s’est effectuée avec succès vous indiquant les messages suivants :

• Successfully connected to local WSUS server
• Successfully checked database connection on WSUS server <SUPServerName>

De plus, vous constatez des erreurs de connexion au site IIS de WSUS dans le fichier de log WCM.log avec le message suivant :

System.Net.WebException: The request failed with HTTP status 403: Forbidden.~~ at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)~~ at Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer(String serverName, Boolean useSecureConnection, Int32 portNumber)~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber

Step 1 – http://technet.microsoft.com/fr-fr/library/bb735874.aspx

Step 2 – http://social.technet.microsoft.com/forums/en-US/configmgrsum/thread/0c95dae5-97a2-4ae1-a5d4-12a52e2719ee/

Note : Si vous utilisez FEP (Forefront Enpoint Protection) dans sa version TMG, il se peut que celui-ci bloque le serveur SCCM pour communiquer avec le serveur WSUS (Et ceci même si les 2 rôles sont hébergés sur le même serveur physique). Il faut dans ce cas donner l’autorisation au serveur SCCM de piloter et donc de communiquer avec le serveur WSUS dans TMG via le protocole http

Une désinstallation du rôle SUP (software Update Point) et de Microsoft WSUS peut être la dernière solution.

Les étapes sont :

1. Désinstallation du rôle SUP dans ConfigMgr
2. Désinstallation de Microsoft WSUS 2.0 (SP1 ou SP2)
3. Redémarrage du serveur
4. Réinstallation de Microsoft WSUS 2.0 (SP1 ou SP2) avec les recommandations, plus bas dans ce post
5. Configuration de Microsoft IIS 6.0 ou 7.0 pour utiliser le SSL
6. Réactivation du rôle SUP (software Update Point) dans SCCM en spécifiant bien les ports de communication IIS

Consultation des fichiers logs dans cet ordre, se trouvant dans le répertoire Logs de ConfigMgr

SUPSetup.log : Fichier de log de l’installation du rôle SUP dans ConfigMgr (SCCM)
WCM.log : Fichier de log du composant WSUS
WSUSCtrl.log : Fichier de log de contrôle de rôle SUP
wsyncmgr.log : Fichier de log de synchronisation du catalogue des MàJ

Recommandations

Pour une utilisation de WSUS dans Microsoft SCCM, il est conseillé d’installer Microsoft WSUS sur un site web dédié : WSUS Administration. Contrairement à ce qui est indiqué dans l’interface d’installation de WSUS… (Voir la figure ci-contre…) Choix à faire lors de l’installation de WSUS pour une utilisation des SCCM 2007 : Create a Windows Server Update Services 3.0 SP2 Web Site

Configuration de Microsoft IIS 7.0

Voici la structure de Microsoft IIS 7.0 une fois l’installation de WSUS terminée. Les flèches indiquent les répertoires virtuels que vous devez configurer en SSL Require / Ignore pour l’utilisation en SSL (8531). Pour une utilisation de SSL, vous devez bien sûr configurer le Bindings comme suit avec un certificat valide et conforme pour SCCM (plus bas) (Ne pas spécifier d’adresse IP vous devez avoir *)

Commande WSUSUtil.exe pour utiliser le SSL et Proxy

N’oubliez pas de passer la commande suivante pour une utilisation de SSL avec WSUS :

C:\Program Files\Update Services\Tools\wsusutil.exe configuressl WSUSServerName.FQDN

Exemple :
C:\Program Files\Update Services\Tools>wsusutil.exe configuressl server2.domain.lab
URL : https://server2.domaine.lab:8531

Pour finir, si vous utilisez un compte Proxy, n’oubliez pas de passer la commande suivante:

C:\Program Files\Update Services\Tools> wsusutil.exe configuresslproxy <ssl_proxy_ip_or_name> <port> –enable

Activation du rôle Software Update Point dans Microsoft SCCM 2007

Dans SCCM, vérifier bien ou spécifier bien les ports de communication en fonction de votre configuration Microsoft WSUS et IIS. Dans le cas de l’utilisation d’un site Web IIS dédié à WSUS les ports à renseigner sont :

– http : 8530
– https : 8531

Bon courage !

Michel PICOLLET | EXAKIS Paris
Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

Catégories :SCCM Étiquettes : , , , , , , , ,

SCCM – Erreur “sans-fin” lors de l’installation de Microsoft Forefront stipulant dans l’assistant d’installation que votre serveur est en attente de redémarrage, alors qu’il n’en est rien en réalité !

logo-header-forefront-dg

Petit tips vite fait…

Issue

Il se peut que vous rencontriez une erreur “sans fin”, stipulant que votre serveur est en attente de finalisation d’une installation antérieure, alors qu’il n’en est rien, vous obligeant à redémarrer votre serveur, bloquant ainsi les prérequis et l’installation de FEP 2010 (Dernière ligne).

SCCM FEP Console

Contournement

Pour contourner le problème …

Lancer la console : Regedit.exe
Localiser la clé de registre suivante :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager
Localiser “PendingFileRenameOperations
Renommez celui-ci en “PendingFileRenameOperations2
Relancer l’installation ou l’assistant d’installation de FEP 2010… 

Les prérequis devraient cette fois passer…

PS : Cette astuce est valable pour la plupart des installations…

Enjoy !

Michel PICOLLET | EXAKIS Paris
Consultant Senior Microsoft [System Center]
mpicollet@event-horizon.emea.microsoftonline.com

%d blogueurs aiment cette page :