Kami memperhatikan bahwa Aturan Penerapan Otomatis untuk Pembaruan Perangkat Lunak gagal untuk mengunduh dan menerapkan tambalan bulan ini dari Microsoft secara otomatis meskipun tercantum dalam Katalog dengan benar.
Aturan Penerapan Otomatis mencantumkan Kode Kesalahan Terakhir sebagai 0X87D20417dan Deskripsi Kesalahan Terakhir sebagai "Pengunduhan Aturan Penerapan Otomatis gagal". Menjalankan kembali aturan secara manual mereproduksi kesalahan ini. Menghapus dan menciptakan kembali Aturan Penerapan Otomatis juga mereproduksi kesalahan yang sama.
Melihat log SMS_RULE_ENGINE menunjukkan kesalahan berikut:
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.
Jika saya melihat melalui ruleengine.log (yang mungkin merupakan file log di mana log SMS_RULE_ENGINE tingkat yang lebih tinggi dihasilkan dari SCCM) dan mengoordinasikan ID Paket untuk Paket Penyebaran yang relevan, sehingga Peraturan Penyebaran Otomatis seharusnya menempatkan pembaruan ini di I temukan yang berikut:
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)
Pada titik ini, saya memiliki tiga kesalahan berbeda yang saya yakin semuanya dihasilkan oleh peristiwa yang sama. Tentu saja, mungkin bukan itu sebabnya mereka semua termasuk di sini. Saya memang mengoordinasikan waktu dalam file log dan cukup yakin mereka semua terkait dengan masalah dengan Aturan Penerapan Otomatis.
0X87D20417- Dari Aturan Penerapan Otomatis Konsol SCCM8706- Dari log SMS_RULE_ENGINE Pemantauan Konsol SCCMError code = 4115- Dari log server situs SCCM dari [SCCMInstallationPath] \ Logs \ ruleengine.log
Sepertinya kami tidak dapat mengunduh pembaruan itu. Tampaknya tempat untuk memecahkan masalah semacam itu adalah PatchDownloader.log . Dan masih ada kesalahan lain yang tercatat di sana:
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)
Saya dapat mengoordinasikan ID Konten di PatchDownloader.log kembali ke Error: 4115entri yang dicatat di ruleengine.log jadi, seperti yang disebutkan sebelumnya, saya cukup yakin sedang melihat acara yang sama menghasilkan semua kesalahan yang berbeda ini tetapi jika seseorang tahu lebih baik tolong Betulkan saya.
Jika saya menggunakan alat CMTrace's Error Lookup, ini memberitahu saya hal berikut tentang hr = 0x80041013.
Provider load failure
Source: Windows Management (WMI)
-----
Dan tentu saja jika saya melihat namespace WMI yang terhubung ke Software Updates Patch Downloader, itu tidak terlihat benar:
\ SCCM.ad.example.com \ root \ sms \ site_REV
Kode Situs kami sebenarnya 004dan cukup lucu, tiga huruf pertama dari organisasi kami dimulai dengan REV. Kebetulan sekali jika Anda bertanya kepada saya. Lebih jauh lagi, ini bukan instalasi SCCM pertama yang ada di sini dan ternyata SCCM 2007 sebelumnya memiliki Batas, Koleksi, dan Paket yang ada dimigrasi ke instalasi baru kami. Pistol merokok? Tidak terlalu. Itu menggunakan kode situs yang berbeda juga. Mungkin kode situs REV digunakan untuk instalasi tes sementara SCCM 2012? Mungkin tidak. Pengetahuan institusional tidak memiliki catatan tentang REVitu dan migrasi yang kami lakukan sebelum saya dipekerjakan.
Namun - PatchDownloader.log lama kami dari instance SCCM 2007 menunjukkan Pengunduh Patch Pembaruan Perangkat Lunak yang terhubung ke site_$SITECODEnamespace WMI. Sayangnya, saya tidak memiliki log dari instalasi 2012 kami saat ini dari Mei di mana saya bisa mengkonfirmasi namespace WMI yang benar sedang direferensikan.
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)
BAIK. Itu benar-benar terlihat seperti masalah dengan ruang nama WMI. Di suatu tempat di kedalaman SCCM, sesuatu yang menceritakan Software Update patch Downloader untuk terhubung ke \\SCCM.ad.example.com\root\sms\site_REVbukannya \\SCCM.ad.example.com\root\sms\site_004.
Pada WAG, saya memeriksa kemungkinan tabel dalam database SQL untuk referensi yang REVtidak berhasil ..
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';
Untuk semakin memperumit hal-hal yang saya lihat penjelasan banyak 0x80041013kesalahan.
Tip Pemecahan Masalah WMI mengatakan bahwa gagal memuat penyedia WMI:
WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013
Kelas Pemecahan Masalah Acara Penyedia merupakan sumber yang bagus, tetapi mungkin sedikit berlebihan. Kelas MSFT_WmiProvider_LoadOperationFailureEvent adalah salah satu yang saya temukan berguna cukup sering. Sebagian besar Kegagalan Load Provider yang saya temui adalah akibat dari registrasi komponen yang buruk (baik dalam registri atau WMI), atau izin terkait.
Sedangkan Konstanta Kesalahan WMI dari MSDN mengatakan bahwa ini adalah masalah izin:
WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) Pengguna saat ini tidak memiliki izin untuk melakukan tindakan.
Satu-satunya informasi lain yang dapat saya temukan pada 0x80041013kesalahan tersebut adalah seorang rekan yang memposting di TechNet yang tampaknya memiliki masalah yang sama dengan saya, bahkan hingga ke masalah di mana ia memiliki instalasi SCCM sebelumnya yang mana namespace WMInya telah salah direferensikan ( misalnya, site_REVbukannya site_004). Dia akhirnya nuking seluruh namespace WMI serta bagian-bagian dari SMS_ProviderLocation. Saya tidak yakin ingin melakukannya.
Pada titik ini, ini adalah hari yang panjang, kita perlu memperbaiki server ini dan kepalaku sakit. Ada saran?
Jawaban:
Firasat ini benar. Saya menghubungi pendahulu saya dan tampaknya upaya pertama dan tidak berhasil untuk bermigrasi dari SCCM 2007 ke SCCM 2010 menggunakan
REVkode situs. Bagaimana ia bisa duduk diam di WMI selama ini dan mengapa itu "diaktifkan" adalah misteri yang lengkap bagi saya.Saya sangat hati-hati membaca kembali solusi di posting TechNet ini yang menyarankan menghapus ruang nama lama dan memutuskan untuk mencobanya. Saya agak ragu untuk menandai ini sebagai jawaban walaupun itu memang menyelesaikan masalah ini, ini menunjukkan bahwa saya secara implisit menyetujuinya, terutama karena saya tidak dapat meminta orang "resmi" di Microsoft untuk mengkonfirmasi apakah ini merupakan pendekatan yang aman atau tidak. atau apa konsekuensinya untuk melakukan ini. Yang sedang berkata, pastikan Anda memiliki cadangan lengkap dari server SCCM Anda atau setidaknya pengetahuan yang jauh lebih intim tentang WMI sebelum melanjutkan. Anda dapat dengan mudah menghancurkan semua yang melakukan ini, terutama jika seperti saya, Anda tidak terbiasa dengan WMI dan seberapa dalam SCCM memanfaatkannya.
Saya menggunakan wbemtest untuk terhubung ke
root\smsnamespace di server SCCM kami. Dari sana saya menggunakan tombol [Enum_Inances ...] dan mencari__NAMESPACEsebagai superclass. Saya menghapus entri untukREVkode situs. Saya kemudian melakukan Enum_Instances yangSMS_ProviderLocationsama dengan superclass dan menghapus kode situs lama dari namespace itu. Menjalankan kembali Aturan Penerapan Otomatis dan meninjauPatchDownloader.logmenunjukkan keberhasilan pengunduhan setiap Pembaruan Windows.Saya akan sangat menghargai informasi lebih lanjut tentang bagaimana ruang nama ini digunakan oleh SCCM dan bagaimana ini memperbaiki masalah jika ada yang memiliki informasi lebih rinci.
sumber