Zauważyliśmy, że nasze reguły automatycznego wdrażania aktualizacji oprogramowania nie pobrały i nie zastosowały łatek z tego miesiąca od firmy Microsoft, mimo że są one poprawnie wymienione w katalogu.
Reguły automatycznego wdrażania zawierają ich ostatni kod błędu jako 0X87D20417i ostatni opis błędu jako „Nie powiodło się pobieranie reguły automatycznego wdrażania”. Ponowne uruchomienie reguł ręcznie odtwarza ten błąd. Usunięcie i ponowne utworzenie Reguł automatycznego wdrażania również powoduje odtworzenie tego samego błędu.
Przeglądanie dziennika SMS_RULE_ENGINE pokazuje następujące błędy:
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.
Jeśli przejrzę regułęengine.log (która jest prawdopodobnie plikiem dziennika, z którego generowany jest dziennik SMS_RULE_ENGINE wyższego poziomu w SCCM) i koordynuję identyfikator pakietu dla odpowiednich pakietów wdrażania, od których reguły automatycznego wdrażania powinny umieszczać te aktualizacje w I Znajdź następujące:
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)
W tym momencie mam trzy różne błędy, które moim zdaniem są generowane przez to samo zdarzenie. Oczywiście mogą nie być i dlatego wszystkie są tutaj uwzględnione. Koordynowałem czasy w plikach dziennika i jestem przekonany, że wszystkie są związane z problemem z regułami automatycznego wdrażania.
0X87D20417- Z reguł automatycznego wdrażania konsoli SCCM8706- Z dziennika monitorowania SMS_RULE_ENGINE konsoli SCCMError code = 4115- Z dzienników serwera witryny SCCM z [SCCMInstallationPath] \ Logs \ rulesengine.log
Wygląda na to, że nie jesteśmy w stanie pobrać tych aktualizacji. Najwyraźniej miejscem do rozwiązania tego rodzaju problemów jest PatchDownloader.log . I tam jest jeszcze jeden zarejestrowany błąd:
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)
Mogę koordynować identyfikatory treści w PatchDownloader.log z powrotem do Error: 4115wpisów zapisanych wuleengine.log, więc, jak wspomniano wcześniej, jestem prawie pewien, że patrzyłem na to samo zdarzenie generujące wszystkie te różne błędy, ale jeśli ktoś wie lepiej, proszę Popraw mnie.
Jeśli korzystam z narzędzia do wyszukiwania błędów CMTrace, mówi mi on o hr = 0x80041013.
Provider load failure
Source: Windows Management (WMI)
-----
I na pewno, jeśli spojrzę na przestrzeń nazw WMI, z którą łączy się narzędzie do pobierania aktualizacji oprogramowania, nie wygląda to dobrze:
\ SCCM.ad.example.com \ root \ sms \ site_REV
Nasz kod witryny jest właściwie 004i zabawny, pierwsze trzy litery naszej organizacji zaczynają się od REV. Może to przypadek, jeśli mnie o to poprosisz. Co więcej, nie jest to pierwsza instalacja SCCM, która istniała tutaj i okazuje się, że poprzednia SCCM 2007 migrowała istniejące granice, kolekcje i pakiety do naszej nowej instalacji. Palisz broń? Nie do końca. Używał również innego kodu witryny. Być może do tymczasowej instalacji SCCM 2012 użyto kodu witryny REV? Może nie. Wiedza instytucjonalna nie ma na to żadnego zapisu REVani migracji, którą przeprowadziliśmy przed zatrudnieniem.
Jednak - nasz stary PatchDownloader.log z instancji SCCM 2007 pokazuje narzędzie do pobierania aktualizacji oprogramowania łączące się z site_$SITECODEprzestrzenią nazw WMI. Niestety nie mam dzienników z naszej bieżącej instalacji z maja 2012 r., W których mógłbym potwierdzić, że odwołuje się do prawidłowej przestrzeni nazw WMI.
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)
DOBRZE. To naprawdę wygląda na problem z przestrzeniami nazw WMI. Gdzieś w głębi SCCM coś mówi narzędziu Download Updates Patch Downloader do połączenia \\SCCM.ad.example.com\root\sms\site_REVzamiast \\SCCM.ad.example.com\root\sms\site_004.
Na WAG sprawdziłem prawdopodobne tabele w bazie danych SQL pod kątem odniesień do REVbezskutecznych.
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';
Aby jeszcze bardziej skomplikować rzeczy, widzę wiele wyjaśnień 0x80041013błędu.
Wskazówki dotyczące rozwiązywania problemów z WMI informują, że nie można załadować dostawcy WMI:
WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013
Klasy rozwiązywania problemów ze zdarzeniami dostawcy są świetnym zasobem, ale mogą być nieco przytłaczające. Klasa MSFT_WmiProvider_LoadOperationFailureEvent to taka, którą często uważam za przydatną. Większość napotkanych przez dostawcę awarii ładowania była wynikiem złej rejestracji komponentu (w rejestrze lub WMI) lub związanych z uprawnieniami.
Podczas gdy stałe błędu WMI z MSDN mówią, że jest to problem z uprawnieniami:
WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) Bieżący użytkownik nie ma uprawnień do wykonania akcji.
Jedyne inne informacje, które mogłem znaleźć na temat 0x80041013błędu, to osoba, która opublikowała w witrynie TechNet, który wydaje się mieć ten sam problem, co ja, nawet w przypadku, gdy miał wcześniejszą instalację SCCM, do której błędnie przywołano przestrzeń nazw WMI ( np. site_REVzamiast site_004). W końcu nukuje całą przestrzeń nazw WMI, a także części SMS_ProviderLocation. Nie jestem pewien, czy chcę to zrobić.
W tym momencie minął długi dzień, musimy załatać te serwery i boli mnie głowa. Jakakolwiek rada?
Odpowiedzi:
To przeczucie było poprawne. Złapałem swojego poprzednika i najwidoczniej pierwsza i nieudana próba migracji z SCCM 2007 do SCCM 2010 wykorzystała
REVkod witryny. To, jak udało się cały czas siedzieć w WMI i dlaczego zostało „aktywowane”, jest dla mnie całkowitą tajemnicą.Bardzo uważnie ponownie przeczytałem rozwiązanie w tym poście TechNet, który zalecił usunięcie starych przestrzeni nazw i postanowiłem spróbować. W pewnym sensie waham się, czy oznaczyć to jako odpowiedź, mimo że rozwiązało to ten problem, wskazuje jednak, że domyślnie się na to zgadzam, zwłaszcza że nie mogłem nikogo „oficjalnie” w firmie Microsoft potwierdzić, czy jest to bezpieczne podejście, czy nie lub jakie byłyby tego konsekwencje. To powiedziawszy, przed kontynuowaniem upewnij się, że masz pełne kopie zapasowe swojego serwera SCCM lub przynajmniej o wiele bardziej intymną wiedzę na temat WMI. Możesz bardzo łatwo zepsuć wszystko, robiąc to, szczególnie jeśli tak jak ja, nie znasz WMI i tego, jak głęboko SCCM to wykorzystuje.
Użyłem wbemtest do połączenia z
root\smsprzestrzenią nazw na naszym serwerze SCCM. Stamtąd użyłem przycisku [Enum_Instances ...] i szukałem__NAMESPACEjako nadklasy. Usunąłem wpis dotyczącyREVkodu strony. Następnie zrobiłem te same Enum_Instances dlaSMS_ProviderLocationsuperklasy i usunąłem stary kod witryny z tej przestrzeni nazw. Ponowne uruchomienie reguł automatycznego wdrażania i przeglądaniePatchDownloader.logpokazanego udanego pobierania każdej aktualizacji Windows.Byłbym bardzo wdzięczny za więcej informacji o tym, jak te przestrzenie nazw są używane przez SCCM i jak to rozwiązało problem, jeśli ktoś ma bardziej szczegółowe informacje.
źródło