Nous avons remarqué que nos règles de déploiement automatique pour les mises à jour logicielles n'ont pas pu télécharger et appliquer automatiquement les correctifs de ce mois-ci auprès de Microsoft, bien qu'ils soient correctement répertoriés dans le catalogue.
Les règles de déploiement automatique répertorient leur dernier code d'erreur comme 0X87D20417et la dernière description d'erreur comme «Échec du téléchargement de la règle de déploiement automatique». La réexécution manuelle des règles reproduit cette erreur. La suppression et la recréation des règles de déploiement automatique reproduisent également la même erreur.
L'examen du journal SMS_RULE_ENGINE montre les erreurs suivantes:
Error Milestone 004 6/19/2013 3:42:21 PM SCCM.ad.example.com SMS_RULE_ENGINE 8706 Content download failed. Message: Failed to download one or more content files. Source: SMS Rule Engine.
Error Milestone 004 6/19/2013 3:42:07 PM SCCM.ad.example.com SMS_RULE_ENGINE 8706 Content download failed. Message: Failed to download one or more content files. Source: SMS Rule Engine.
Error Milestone 004 6/19/2013 2:45:44 PM SCCM.ad.example.com SMS_RULE_ENGINE 8706 Content download failed. Message: Failed to download one or more content files. Source: SMS Rule Engine.
Error Milestone 004 6/19/2013 2:43:29 PM SCCM.ad.example.com SMS_RULE_ENGINE 8706 Content download failed. Message: Failed to download one or more content files. Source: SMS Rule Engine.
Si je regarde le ruleengine.log (qui est vraisemblablement le fichier journal à partir duquel le journal SMS_RULE_ENGINE de niveau supérieur dans SCCM est généré) et que je coordonne l'ID de package pour les packages de déploiement pertinents à partir desquels les règles de déploiement automatique sont censées placer ces mises à jour dans I trouver les éléments suivants:
Contents 16821586 is already present in the package "0040000F". Skipping download. SMS_RULE_ENGINE 6/19/2013 3:41:58 PM 9068 (0x236C)
Downloading contents (count = 10) for UpdateID 16829711 SMS_RULE_ENGINE 6/19/2013 3:41:58 PM 9068 (0x236C)
List of update content(s) which match the content rule criteria = {16821659,16821660,16821661,16821662,16821663,16821664,16821665,16821666,16821667,16821668} SMS_RULE_ENGINE 6/19/2013 3:41:58 PM 9068 (0x236C)
Downloading content with ID 16821659 in the package SMS_RULE_ENGINE 6/19/2013 3:41:58 PM 9068 (0x236C)
Failed to download the update from internet. Error = 4115 SMS_RULE_ENGINE 6/19/2013 3:41:58 PM 9068 (0x236C)
Failed to download ContentID 16821659 for UpdateID 16829711. Error code = 4115 SMS_RULE_ENGINE 6/19/2013 3:41:58 PM 9068 (0x236C)
À ce stade, j'ai trois erreurs différentes qui, je crois, sont toutes générées par le même événement. Bien sûr, ils peuvent ne pas l'être, c'est pourquoi ils sont tous inclus ici. J'ai coordonné les heures dans les fichiers journaux et je suis raisonnablement convaincu qu'ils sont tous liés au problème avec les règles de déploiement automatique.
0X87D20417- À partir des règles de déploiement automatique de la console SCCM8706- Depuis le journal de surveillance SMS_RULE_ENGINE de la console du SCCMError code = 4115- À partir des journaux du serveur de site SCCM à partir de [SCCMInstallationPath] \ Logs \ ruleengine.log
Il semble que nous ne soyons pas en mesure de télécharger ces mises à jour. Apparemment, l'endroit pour dépanner ce genre de chose est le PatchDownloader.log . Et voilà, il y a encore une autre erreur enregistrée:
Trying to connect to the \\SCCM.ad.example.com\root\sms\site_REV namespace on the SCCM.ad.example.com machine. Software Updates Patch Downloader 6/19/2013 3:42:21 PM 9068 (0x236C)
Connected to \\SCCM.ad.example.com\root\sms\site_REV Software Updates Patch Downloader 6/19/2013 3:42:21 PM 9068 (0x236C)
GetContentFileInfoForDownload() failed for ContentID 16821994. hRes = 0x80041013 . Software Updates Patch Downloader 6/19/2013 3:42:21 PM 9068 (0x236C)
ERROR: DownloadContentFiles() failed with hr=0x80041013 Software Updates Patch Downloader 6/19/2013 3:42:21 PM 9068 (0x236C)
Je peux coordonner les identifiants de contenu dans PatchDownloader.log vers les Error: 4115entrées enregistrées dans ruleengine.log donc, comme mentionné précédemment, je suis presque sûr que le même événement générait toutes ces erreurs différentes, mais si quelqu'un sait mieux, s'il vous plaît corrigez-moi.
Si j'utilise l'outil de recherche d'erreur de CMTrace, il me dit ce qui suit à propos de hr = 0x80041013.
Provider load failure
Source: Windows Management (WMI)
-----
Et bien sûr, si je regarde l'espace de noms WMI auquel le logiciel de téléchargement des correctifs de mises à jour se connecte, il ne semble pas tout à fait correct:
\ SCCM.ad.example.com \ root \ sms \ site_REV
Notre code de site est en fait 004et assez drôle les trois premières lettres de notre organisation commencent par REV. Puissante coïncidence si vous me demandez. De plus, ce n'est pas la première installation SCCM qui existait ici et il s'avère que la précédente SCCM 2007 avait migré les limites, collections et packages existants vers notre nouvelle installation. Pistolet fumant? Pas assez. Il a également utilisé un code de site différent. Peut-être que le code de site REV a été utilisé pour une installation de test temporaire de SCCM 2012? Peut-être pas. Les connaissances institutionnelles n'ont aucune trace de REVcela et de la migration que nous avons effectuée avant mon embauche.
Cependant, notre ancien PatchDownloader.log de l'instance SCCM 2007 montre le logiciel de téléchargement des correctifs de mises à jour se connectant à l' site_$SITECODEespace de noms WMI. Malheureusement, je n'ai pas de journaux de notre installation 2012 actuelle de mai où je pourrais confirmer que l'espace de noms WMI correct est référencé.
Trying to connect to the root\SMS namespace on the SCCM07.ad.example.com machine. Software Updates Patch Downloader 8/3/2011 3:18:37 PM 25128 (0x6228)
Connected to \\SCCM07.ad.example.com\root\SMS Software Updates Patch Downloader 8/3/2011 3:18:37 PM 25128 (0x6228)
Trying to connect to the \\SCCM07.ad.example.com\root\sms\site_DOR namespace on the machine. Software Updates Patch Downloader 8/3/2011 3:18:37 PM 25128 (0x6228)
Connected to \\SCCM07.ad.example.com\root\sms\site_DOR Software Updates Patch Downloader 8/3/2011 3:18:37 PM 25128 (0x6228)
Download destination = \\SCCM07.ad.example.com\WSUSContent\be128fa4-0c6b-418a-893d-3450e38c658d.1\windows-kb890830-v3.21.exe . Software Updates Patch Downloader 8/3/2011 3:18:37 PM 25128 (0x6228)
Contentsource = http://download.windowsupdate.com/msdownload/update/software/uprl/2011/07/windows-kb890830-v3.21_2aba440b72071ff17cad1ca2a39f0e40aa85c76e.exe . Software Updates Patch Downloader 8/3/2011 3:18:37 PM 25128 (0x6228)
Downloading content for ContentID = 31068, FileName = windows-kb890830-v3.21.exe. Software Updates Patch Downloader 8/3/2011 3:18:37 PM 25128 (0x6228)
D'ACCORD. Cela ressemble vraiment à un problème avec les espaces de noms WMI. Quelque part dans les profondeurs de SCCM, quelque chose dit au logiciel de mise à jour des correctifs de se connecter au \\SCCM.ad.example.com\root\sms\site_REVlieu de \\SCCM.ad.example.com\root\sms\site_004.
Sur un WAG, j'ai vérifié les tables probables dans la base de données SQL pour les références à REVvain.
SELECT * FROM SysResList WHERE SiteCode = 'REV';
SELECT * FROM SiteControl WHERE SiteCode = 'REV';
SELECT * FROM SiteControlNotification WHERE SiteCode = 'REV';
SELECT * FROM Sites WHERE SiteCode = 'REV';
SELECT * FROM Sites_DATA WHERE SiteCode = 'REV';
SELECT * FROM SiteWork WHERE SiteCode = 'REV';
SELECT * FROM PkgServers WHERE sitecode = 'REV';
SELECT * FROM PkgStatus WHERE sitecode = 'REV';
Pour compliquer encore les choses, je vois plusieurs explications de l' 0x80041013erreur.
Conseils de dépannage WMI indique que le chargement d'un fournisseur WMI échoue:
WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013
Les classes de dépannage d'événements de fournisseur sont une excellente ressource, mais peuvent être un peu écrasantes. La classe MSFT_WmiProvider_LoadOperationFailureEvent est celle que j'ai trouvée assez souvent utile. La plupart des échecs de chargement de fournisseur que j'ai rencontrés sont le résultat d'un mauvais enregistrement des composants (dans le registre ou WMI) ou des autorisations liées.
Alors que les constantes d'erreur WMI de MSDN indiquent qu'il s'agit d'un problème d'autorisations:
WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) L'utilisateur actuel n'est pas autorisé à effectuer l'action.
La seule autre information que j'ai pu trouver sur l' 0x80041013erreur était un gars qui a posté sur TechNet et qui semble avoir eu le même problème que moi, même jusqu'au problème où il avait une installation précédente de SCCM, dont l'espace de noms WMI était référencé par erreur ( par exemple, site_REVau lieu de site_004). Il a fini par nuquer l'intégralité de l'espace de noms WMI ainsi que les parties de SMS_ProviderLocation. Je ne suis pas sûr de vouloir faire ça.
À ce stade, la journée a été longue, nous devons corriger ces serveurs et j'ai mal à la tête. Aucun conseil?
Réponses:
Cette intuition était correcte. J'ai mis la main sur mon prédécesseur et, apparemment, la première tentative infructueuse de migration de SCCM 2007 vers SCCM 2010 a utilisé le
REVcode de site. Comment il a réussi à rester en sommeil dans WMI pendant tout ce temps et pourquoi il a été "activé" est un mystère complet pour moi.J'ai relu très attentivement la solution dans cet article TechNet qui conseillait de supprimer les anciens espaces de noms et j'ai décidé d'essayer cela. J'hésite un peu à marquer cela comme une réponse même si cela a résolu ce problème, cela indique que je l'approuve implicitement, d'autant plus que je n'ai pu obtenir personne "officiel" de Microsoft pour confirmer si c'était une approche sûre ou non ou quelles en ont été les conséquences. Cela étant dit, assurez-vous d'avoir des sauvegardes complètes de votre serveur SCCM ou au moins une connaissance beaucoup plus intime de WMI avant de continuer. Vous pourriez très facilement tout casser en faisant cela, surtout si comme moi, vous n'êtes pas familier avec WMI et à quel point SCCM en tire parti.
J'ai utilisé wbemtest pour me connecter à l'
root\smsespace de noms sur notre serveur SCCM. À partir de là, j'ai utilisé le bouton [Enum_Instances ...] et j'ai cherché__NAMESPACEla superclasse. J'ai supprimé l'entrée duREVcode de site. J'ai ensuite fait les mêmes Enum_Instances pour laSMS_ProviderLocationque la superclasse et supprimé l'ancien code de site de cet espace de noms. La réexécution des règles de déploiement automatique et l'examen duPatchDownloader.logont montré que le téléchargement de chaque mise à jour Windows a réussi.J'apprécierais grandement plus d'informations sur la façon dont ces espaces de noms sont utilisés par SCCM et exactement comment cela a résolu le problème si quelqu'un a des informations plus détaillées.
la source