Comment savoir quel (s) client (s) est à l'origine de l'échec de ma mise à jour de distribution?


14

Cela arrive de temps en temps. Je mets à jour un package et dois mettre à jour le point de distribution. Nous avons plusieurs DP, et généralement tout se passe bien, mais de temps en temps, notre DP principal ne met pas à jour le package.

1 Capture d'écran DP échouée

Le journal d'état du contenu ne dit jamais grand-chose sur l'échec. Je n'ai pas accès au serveur principal aux points de gestion ou aux DP, je suis juste l'administrateur SCCM. Je peux vérifier tous les journaux dans SCCM, exécuter des rapports et tout, mais je ne sais pas où chercher.

Dans le passé, j'ai essayé de définir le paramètre "Déconnecter les utilisateurs du point de distribution" sur le package de problème, les deux sous-paramètres à 0, mais cela ne fonctionne pas vraiment pour nous. Le problème semble disparaître de lui-même après un certain temps, mais cela prend parfois plusieurs jours. Pour la majorité (vraiment tous, mais il y en a peut-être un ou deux que j'ai négligés), nous définissons les clients sur "Exécuter le programme à partir du point de distribution" Lors du déploiement du programme, je ne sais pas si cela a quelque chose à voir avec lui, ou ce que la racine la cause est.

Mise à jour

J'ai trouvé un peu plus d'informations dans les rapports, en particulier la All Status Messages for a Specific Package at a Specific Siterequête. En utilisant mon ID de package pour la requête, après l'échec de la mise à jour DP, j'ai vu une entrée qui se démarquait:

Distribution Manager n'a pas pu traiter le package «Mises à jour de configuration» (ID du package = SOM00013).

Cause possible : le gestionnaire de distribution n'a accès ni au répertoire source du package ni au point de distribution. Solution: vérifiez que le gestionnaire de distribution peut accéder au répertoire / package source du package.

Cause possible : le répertoire source du package contient des fichiers avec des noms de fichiers longs et la longueur totale du chemin d'accès dépasse la longueur maximale prise en charge par le système d'exploitation. Solution: réduisez le nombre de dossiers définis pour le package, raccourcissez le nom de fichier ou envisagez de regrouper les fichiers à l'aide d'un utilitaire de compression.

Cause possible : l'espace disque disponible est insuffisant sur l'ordinateur du serveur de site ou le point de distribution. Solution: vérifiez que l'espace disque disponible est suffisant sur l'ordinateur du serveur de site et sur le point de distribution.

Cause possible : le répertoire source du package contient des fichiers susceptibles d'être utilisés par un processus actif. Solution: fermez tous les processus qui utilisent peut-être des fichiers dans le répertoire source. Si cet échec persiste, créez une autre copie du répertoire source et mettez à jour la source du package pour qu'elle pointe vers celui-ci.

Je doute des deux causes du milieu pour des raisons simples

  • Le dossier source n'est pas si profond pour contenir des noms de fichiers longs pour NTFS, bien que je vais essayer de vérifier l'exhaustivité.

  • Je peux très bien ajouter des fichiers au DP, donc ce n'est pas un problème d'espace de fichier, d'autres packages peuvent être mis à jour très bien.

Ce à quoi je ne m'attendais pas, c'est que la troisième cause indique que le répertoire source est utilisé quelque part. Quelle différence cela ferait-il de toute façon? N'est-ce pas simplement copier les fichiers du partage de fichiers dans le partage SCCM DP? En me jetant pour une boucle, les clients b / c n'accèdent même pas au répertoire source, c'est à peu près juste un répertoire intermédiaire pour que sccm copie les fichiers.

Cela laisse juste la première cause, mais cela revient encore à la même chose: d'autres packages peuvent très bien se mettre à jour.


1
Je commencerais par passer en revue le rapport intégré sous trouvé dans la catégorie Mises à jour logicielles - Dépannage E.
Garth Jones

Avez-vous vérifié les journaux des clients eux-mêmes? Celui que je commence habituellement est $ env: windir \ ccm \ logs \ wuahandler.log Recherchez les lignes avec les drapeaux ERROR et WARNING. Une mise à jour ressemblera à ceci (je m'en vais; je n'ai pas de machine Windows pour couper-coller) 1) Dites qu'il est sur le point de commencer la mise à jour. Cette partie prend beaucoup de lignes car ils veulent la rendre jolie 2) Dites qui est le serveur SCCM qui obtient les fichiers 3) Mentionnez qu'il vérifie les fichiers et quels packages le cas échéant il obtient 4) S'il voit une erreur , il indiquera "Je ne peux pas obtenir de colis" ou "Je ne trouve pas le
raubvogel

-1, il s'agit d'un client à l'origine de ce problème plus que probable, mais parcourir individuellement 3000 clients pour les journaux indiquant quelque chose qui devrait déjà être connu du point de distribution est insensé. Je sais à quoi m'attendre, ce n'est pas une question qui nécessite une réponse vague, ni même une question qui peut bénéficier d'une réponse vague. C'est une question très précise.
MDMoore313

S'il dispose d'un accès administrateur SCCM, il devrait pouvoir accéder aux déploiements de surveillance->, puis y trouver l'entrée pour le progiciel. En cliquant dessus, vous verrez quels clients ont installé ce logiciel et lesquels ne l'ont pas fait. J'ai supposé que l'image qu'il avait obtenue provenait de cet écran.
raubvogel

Réponses:


3

Je doute que vous puissiez résoudre ce problème si cela est vrai "Je n'ai pas accès au serveur principal aux points de gestion ou aux DP".

Pouvez-vous accéder au distmgr.log sur le serveur de site? Sinon, vous devrez transmettre le problème à quelqu'un qui le peut.

Ce problème n'a rien à voir avec le client, donc j'ignorerais d'autres réponses conseillant de regarder les clients. Ce problème est dû au fait que le serveur de site ne peut pas copier les fichiers de votre dossier source vers le point de distribution.

Si vous ne pouvez pas accéder aux journaux de Site Server, vous pouvez essayer d'éliminer le fait que votre structure de dossiers est trop longue: compresser votre package, le déployer et décompresser avant de procéder à l'installation côté client.


+1 pour les informations du journal, mais le problème est que le serveur ne peut pas copier les fichiers oui, mais notre théorie de travail est qu'un client a un verrou en écriture sur les fichiers DP d'une manière ou d'une autre. La structure des dossiers n'est pas trop longue car ce paquet particulier avait les fichiers déjà zippés et le comportement n'est pas cohérent mais irrégulier.
MDMoore313 du

0

Obtenez la boîte à outils SCCM. Il dispose d'un analyseur de journaux et de kits d'outils de point de distribution qui peuvent vous aider à trouver le problème.

http://www.microsoft.com/en-us/download/details.aspx?id=36213


2
seriez-vous en mesure d'entrer dans un peu plus de détails sur la façon dont quelqu'un utiliserait la boîte à outils pour trouver un client qui tient toujours un paquet? Si ce n'est pas le cas, il s'agit en fait d'une réponse de lien uniquement, car j'avais déjà installé la boîte à outils.
MDMoore313
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.