Archive

Posts Tagged ‘Error’

SCCM – Inventaires et utilisation des politiques ou stratégies clients

logo-sc2012 Bonjour à tous,

Je vous poste rapidement ce message.

Inventaires et utilisation des politiques ou stratégies clients

Lorsque vous activez une nouvelle politique clients (Devices), vous devez d’abord configurer la politique : Default Client Settings (1000). Celle-ci sert de Template à toutes les autres politiques, de type Custom !

image

Lorsque vous créez une nouvelle politique pour une collection donnée, il vous est proposé, comme un calque, et par défaut, la Default Client Settings, que vous pouvez bien sûr modifiée.

Par conséquent, si dans votre Policy Custom vous activez des classes WMI supplémentaires concernant l’inventaire matériel, sans les avoir activées la politique Default Client Settings, vous risquez alors de bloquer vos inventaires !

image

image

Pour le vérifier, il suffit des ré-éditer votre politique Custom, d’accéder à la section : Inventaire Matériel, puis de lancer l’assistant WMI (Hardware Inventory Classes). Si celui-ci provoque un crash WMI, cela signifie que votre inventaire matériel  ne fonctionne probablement plus sur vos postes ! Vous pouvez pour cela consulter le fichier de log, InventoryAgent.log sur vos clients SCCM :

image

…Tout en déclenchant l’action, Hardware Inventory Cycle, si nécessaire :

image 

Vous pouvez également consulter le fichier de log, InventoryProvider.log !

image

Explication

Ce qui a été “demandé” dans votre politique Custom, n’est pas conforme à ce que vous avez en réalité, activé ou pas dans la Default Client Settings ! … pas bien !

Pour rectifier le problème

Dans cet ordre :
1 – Configurer une fois pour toute les classes WMI dans la Policy, Default Client Settings ;
2 – Supprimer la politique Custom qui pose problème ;
3 – Recréer la nouvelle politique Custom (en vérifiant bien que les classes WMI) ;
4 – Republier la nouvelle politique Custom et la faire télécharger par les clients SCCM :

image

Enjoy !

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

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

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 – 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 d’installation SCCM 2012 (beta2) sur la version de Microsoft 2008 utilisée !!

SCCM2012INSTALLErrorSQLR2

Cela se passe de commentaires, TOUT EST DANS LE MESSAGE !!

Donc attention à la version de SQL que vous utilisez, en attendant que Microsoft rectifie le tir dans les prochaines version …

Enjoy !

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

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

SCCM – Erreur de connexion au serveur ACT 5.6 dans la console SCCM en R3 avec le connecteur

logo-sccm-2007

Bonjour à tous,

Vous avez une erreur de connexion au serveur ACT 5.6 dans la console SCCM en R3 avec le connecteur ACT Connector de SCCM

Issue

Si vous rencontrez des problèmes avec le connecteur ACT dans la console SCCM comme suit, voici un script (plus bas) qui vous permettra de configurer le serveur ACT et de vous connecter au serveur ACT 5.6 depuis la console sans erreur…

clip_image002 

Le script

Le script suivant permet de créer le connecteur dans SCCM et de se connecter au serveur ACT :

Server = Wscript.Arguments.Item(0)
SiteCode = Wscript.Arguments.Item(1)
ActServer = Wscript.Arguments.Item(2)
ActDatabase = Wscript.Arguments.Item(3)

Set objWMIService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & Server & "\root\sms\site_" & SiteCode)
Set wbemObjectSet = objWMIService.InstancesOf("SMS_ActConfig")

‘domain\smsserver$
If LCase(Server) = LCase(ActServer) Then
MachineAcct = ""
Else
MachineAcct = Wscript.Arguments.Item(4)
End If
For Each wbemObject In wbemObjectSet
wbemObject.Server = ActServer
wbemObject.Database = ActDatabase
wbemObject.Put_
If MachineAcct = "" Then
wbemObject.AddLinkedServer ActServer, ActDatabase
Else
wbemObject.AddLinkedServer ActServer, ActDatabase, MachineAcct
End If
Next

Usage du script

ActConfig.vbs [Server] [Site code] [ACT Server] [ACT database] {Machine Account}

[Server]
Name of server where the SMS provider is installed

[Site code]
Three letter side code of ConfigMgr server where ACT Connector is installed

[ACT Server]
Name of SQL server where ACT is installed

[ACT Database]
Name of ACT database on SQL server (set during ACT install)

{Machine Account}
Optional parameter. If the ACT is installed on different server than the ACT Connector, then provide the machine account name the ACTC provider runs under (Domain\MachineAccount$) where the machine account name is the ConfigMgr server where the ACT Connector is installed.

Source

Support ConfigMgr Team

Note : Dans ce post la Support ConfigMgr Team traitait un problème lié à la version 5.5, mais apparemment cela concerne aussi la version 5.6 😉

Download

ACT Connector for SCCM

Enjoy !

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

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

SCCM – Comprendre et utiliser les logs SCCM ?

logo-sccm-2007

Microsoft SCCM 2007 étant parfois très obscure dans son fonctionnement (Surtout en cas de problème de fonctionnement). Je vous propose dans ce post de faire le tour d’horizon sur les fichiers Log de SCCM. Je vous expliquerais quels fichiers de logs à consulter pour tels ou tels problèmes.

Step 1 – Principe de base

Première chose à savoir : Chaque fichier de log est associé à un Threads ou service SCCM. Vous pouvez le voir à cet endroit dans la console SCCM…

image   image

Si vous consultez le fichier de log en question avec Trace32.exe, voici ce que vous y verrez :

image


Principe de résolution de problèmes pour Microsoft SCCM

La première chose qu’un Administrateur SCCM doit faire en arrivant le matin, est d’ouvrir la console SCCM et de consulter les Messages Status depuis la console. Ceci afin de détecter des problèmes éventuels.

image

Pour consulter les messages d’un Service ou d’un thread donné, Sélectionnez-le –> Faire un Clique-droit –> Show Messages –> All

image


La fenêtre ConfigMgr Status Message Viewer for XXX, apparait :

image

Il suffit juste de double-cliquer sur une ligne en particulier pour consulter son contenu !

Généralement, une certaine logique se dessine pour aboutir à l’événement recherché (Erreur, Warning, etc.). En clair, les lignes précédentes peuvent vous renseigner sur l’erreur ou sur l’événement constaté. Raison pour laquelle, je préconise de choisir : Show Messages –> All, afin de saisir le début de l’action qui a échouée ou aboutie…

Autre chose, un service ou un Thread peut alimenter plusieurs logs en plus de celles indiquées dans la console SCCM (Cf. Plus haut)


Step 2 – Utilisation des fichiers Logs SCCM

Voici liste des logs (Non-exhaustif) à consulter pour chaque sujet :

Lien Microsoft : http://technet.microsoft.com/fr-fr/library/bb892800.aspx

Management Point
  • MPSetup.log (Installation rôle)
  • MPMSI.log (Installation rôle)
  • MPControl.log (Activité rôle)
  • MP_XXX.log (Installation rôle PMP)
PXE Service Point
  • PXESetup.log (Installation rôle)
  • PXEMSI.log (Installation rôle)
  • PXEControl.log (Activité rôle)
  • SMSPXE.log (Activité client)

Software Update Point
  • WSYNCMGR.log (Synchro SUP)
  • WCM.log (Connection WSUS)
  • Updates Deployment.log (Activité client)
  • ScanAgent.log (Activité client)

Reporting Point
  • RSetup.log (Installation rôle)
  • SMSReportingInstall.log (Installation rôle)

Fallback Status Point
  • FSPMSI.log (Installation rôle)
  • SMSFSPSetup.log (Installation rôle)
  • FSPMGR.log (Activité rôle)
 
Distribution Point (DP)
  • DISTMGR.log (Réplication des packages sur DP)
Hiérarchie de site SCCM
  • Despooler.log (Réplications SCCM)
  • HMAN.log (Activité Hiérarchique SCCM)
  • Sender.log (Accès réseau inter-sites SCCM)
  • ReplMgr.log (Gestion des objets à répliquer)
  • Schedule.log (Calendriers de réplications intersites)
Découvertes AD SCCM
  • ADSGDIS.log (Groupe Sécurité)
  • ADSYSDIS.log (Systems)
  • ADSYSGRP.log (Groupes AD)
  • ADUSRDIS.log (Utilisateurs AD)
  • NTSRVDis.log (Découverte NT4.0)
Installation client SCCM
  • CCM.log (Log d’accès et de copies vers le client)
  • CCMSETUP.log (Installation sur Client)
Collections (Console)
  • Colleval.log (Activé et MàJ des Collections)
Sauvegarde site SCCM
  • SMSBKUP.log (Sauvegarde Site SCCM)
  • SMSSQLBKUP.log (Sauvegarde DB SQL du site)
State Migration Point
  • SMSSMPSetup.log (Installation rôle)
  • SMPMSI.log (Installation rôle)
  • SMPMGR.log (Activité rôle)
Activité du site SCCM
  • HMAN.log (Activité site SCCM)
  • SMSDBMON.log (Activité SQL / SCCM)
  • SMSEXEC.log (Service SMS_EXECUTIVE)
  • StateSYS.log (Activité System de site SCCM)
  • StatMGR.Log (Gestion des messages States)

Console SCCM –> SQL
  • SMSPROV.log (Activité du SMS Providers)
    Console (DCOM) <–> SMSProviders (WQL)<–> SQL

NOTE : Il est peut-être intéressant de consulter les fichiers de logs de Microsoft IIS pour un complément d’informations pour certains rôles SCCM…

Step 3 – Exemple de démarches

(A titre d’exemple, sans vouloir donner une explication sur le problème de celui-ci… Mon but ici est de fournir un exemple d’une démarche avant tout…)

1 – Consultation Console SCCM

En ouvrant la console le matin, vous constatez des erreurs dans la console SCCM…

image

2 – Consultation des messages Status

En consultant les Messages Status, vous constatez des problèmes concernant le service WDS et les tâches de maintenances SCCM…

2.1. Lecture des messages et vérifications des composants

Pour les tâches de maintenance, le Warning notifie simplement qu’il n’a pas pu faire son action à l’heure et date prévue. Donc rien de grave si comme moi, vous venez de démarrer votre machine de test… Elle était simplement éteinte donc les tâches de maintenances n’ont pas pu être exécutées !

image

3 – Consultation des services Windows

Concernant le Service WDS, vérifiez que le services est bien démarré.

image

Vérifier que les services SQL sont bien démarrer (Si votre console SCCM ne se lance pas) – Ce qui n’est pas notre cas puisque nous venons de la console.

image

4 – Consultation des fichiers de logs associés

Pour vous assurez que tout va bien, consultez la log PXEControl.log pour voir si l’auto-check de SCCM s’effectue correctement. ce qui est mon cas :

image

5 – Conclusion / Rapports diagnostique

Conclusion pour WDS dans mon cas, les services et threads SCCM de manière générale, ont mis simplement du temps à démarrer, engendrant ce genres d’erreurs (Flottantes)


Bon courage !

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

Catégories :SCCM Étiquettes : , , , , , ,
%d blogueurs aiment cette page :