SCCM 2012 SP1 - DownloadContentFiles () không thành công với hr = 0x80041013


15

Chúng tôi nhận thấy Quy tắc triển khai tự động cho các bản cập nhật phần mềm không thể tự động tải xuống và áp dụng các bản vá trong tháng này từ Microsoft mặc dù chúng được liệt kê chính xác trong Danh mục.

Cập nhật phần mềm SCCM được liệt kê trong danh mục


Quy tắc triển khai tự động liệt kê Mã lỗi cuối cùng của họ 0X87D20417và Mô tả lỗi cuối cùng là "Tải xuống quy tắc triển khai tự động không thành công". Chạy lại các quy tắc thủ công tái tạo lỗi này. Xóa và tạo lại Quy tắc triển khai tự động cũng tái tạo lỗi tương tự.

Nhìn vào nhật ký SMS_RULE_ENGINE cho thấy các lỗi sau:

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.   


Nếu tôi xem qua ruleengine.log (có lẽ là tệp nhật ký mà nhật ký SMS_RULE_ENGINE cấp cao hơn trong SCCM được tạo từ đó) và phối hợp ID gói cho các Gói triển khai có liên quan mà Quy tắc triển khai tự động được cho là sẽ đặt các cập nhật này trong I Tìm theo dưới đây:

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)


Tại thời điểm này, tôi có ba lỗi khác nhau mà tôi tin là tất cả được tạo ra bởi cùng một sự kiện. Tất nhiên, họ có thể không phải là lý do tại sao tất cả chúng được bao gồm ở đây. Tôi đã phối hợp thời gian trong các tệp nhật ký và tin tưởng một cách hợp lý rằng tất cả chúng đều liên quan đến vấn đề với Quy tắc triển khai tự động.

  • 0X87D20417 - Từ Quy tắc triển khai tự động của Bảng điều khiển SCCM
  • 8706 - Từ nhật ký SMS_RULE_ENGINE của Bảng điều khiển của SCCM
  • Error code = 4115 - Từ nhật ký máy chủ trang web SCCM từ [SCCMInstallationPath] \ Logs \ ruleengine.log


Có vẻ như chúng tôi không thể tải xuống các bản cập nhật đó. Rõ ràng là nơi để khắc phục sự cố loại đó là PatchDoader.log . Và 'lo có chưa một lỗi ghi có:

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)


Tôi có thể phối hợp ID nội dung trong PatchDoader.log trở lại các Error: 4115mục được ghi trong ruleengine.log vì vậy, như đã đề cập trước đây, tôi khá chắc chắn đang xem xét cùng một sự kiện tạo ra tất cả các lỗi khác nhau này nhưng nếu ai đó biết rõ hơn sửa tôi.

Nếu tôi sử dụng công cụ Tra cứu Lỗi của CMTrace, nó sẽ cho tôi biết những điều sau về hr = 0x80041013.

Provider load failure

Source: Windows Management (WMI)
-----

Và chắc chắn nếu tôi nhìn vào không gian tên WMI mà Trình cập nhật bản vá cập nhật phần mềm đang kết nối, nó có vẻ không đúng lắm:

\ SCCM.ad.example.com \ root \ sms \ site_REV

Mã trang web của chúng tôi thực sự 004và đủ vui là ba chữ cái đầu tiên của tổ chức chúng tôi bắt đầu bằng REV. Mạnh mẽ trùng hợp nếu bạn hỏi tôi. Hơn nữa, đây không phải là bản cài đặt SCCM đầu tiên tồn tại ở đây và hóa ra SCCM 2007 trước đó đã có Ranh giới, Bộ sưu tập và Gói hiện có được chuyển sang bản cài đặt mới của chúng tôi. Súng hút thuốc? Không hẳn. Nó đã sử dụng một mã trang web khác nhau là tốt. Có lẽ mã trang web REV đã được sử dụng để cài đặt thử nghiệm tạm thời SCCM 2012? Có lẽ không. Kiến thức thể chế không có bất kỳ hồ sơ nào về REVnó và việc di chuyển chúng tôi đã thực hiện trước khi tôi được thuê.

Tuy nhiên - PatchDoader.log cũ của chúng tôi từ phiên bản SCCM 2007 hiển thị Trình tải xuống Bản cập nhật Phần mềm kết nối với site_$SITECODEkhông gian tên WMI. Thật không may, tôi không có nhật ký từ bản cài đặt 2012 hiện tại của chúng tôi từ tháng 5, nơi tôi có thể xác nhận không gian tên WMI chính xác đang được tham chiếu.

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)


ĐỒNG Ý. Nó thực sự trông giống như một vấn đề với không gian tên WMI. Ở đâu đó trong chiều sâu của SCCM, một cái gì đó đang nói với Trình cập nhật bản vá cập nhật phần mềm để kết nối \\SCCM.ad.example.com\root\sms\site_REVthay vì \\SCCM.ad.example.com\root\sms\site_004.

Trên WAG, tôi đã kiểm tra các bảng có khả năng trong cơ sở dữ liệu SQL để tham khảo REVkhông có kết quả ..

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';


Để làm phức tạp thêm những điều tôi đang thấy nhiều lời giải thích về 0x80041013lỗi.

Mẹo khắc phục sự cố WMI nói rằng không thể tải nhà cung cấp WMI:

WBEM_E_PROVIDER_LOAD_FAILURE - 0x80041013

Các lớp khắc phục sự cố của nhà cung cấp là một tài nguyên tuyệt vời, nhưng có thể hơi quá sức. Lớp MSFT_WmiProvider_LoadOperationFailureEvent là lớp mà tôi thấy hữu ích khá thường xuyên. Hầu hết các lỗi tải nhà cung cấp mà tôi gặp phải là kết quả của việc đăng ký thành phần xấu (trong sổ đăng ký hoặc WMI) hoặc các quyền liên quan.

Trong khi các hằng số lỗi WMI từ MSDN nói rằng đó là vấn đề về quyền:

WBEM_E_ACCESS_DENIED 2147749891 (0x80041003) Người dùng hiện tại không có quyền thực hiện hành động.

Thông tin khác duy nhất tôi có thể tìm thấy về 0x80041013lỗi là một người đã đăng trên TechNet , người dường như cũng gặp vấn đề tương tự như tôi, thậm chí cả vấn đề mà anh ta đã cài đặt SCCM trước đó mà không gian tên WMI bị tham chiếu nhầm ( ví dụ, site_REVthay vì site_004). Cuối cùng, anh ta đã thu thập toàn bộ không gian tên WMI cũng như các phần của SMS_ProviderLocation. Tôi không chắc chắn tôi muốn làm điều đó.


Tại thời điểm này, đó là một ngày dài, chúng tôi cần phải vá các máy chủ này và đầu tôi đau. Có lời khuyên nào không?


1
Bạn đã thử tải xuống / triển khai các bản cập nhật thủ công (bỏ qua ADR) chưa? Và ... có thể xóa và tạo lại ADR?
Jason Sypkens

@JasonSypkens - Xóa các ADR và ​​tạo lại chúng tái tạo lỗi và tôi thực sự muốn khắc phục sự cố cơ bản với SCCM thay vì tải xuống các bản cập nhật theo cách thủ công - chúng tôi chưa hoàn toàn tuyệt vọng như vậy.

Trên máy chủ trang web chính của bạn, có tồn tại không gian tên WMI gốc \ sms \ site_REV không? root \ sms \ site_004 có tồn tại không? Ngoài ra, điều này có thể hơi quyết liệt, nhưng ... bạn đã thử loại bỏ và thêm lại vai trò SUP và / hoặc cài đặt lại WSUS chưa? Tôi đã xem qua bảng điều khiển quản lý của mình và tôi không thấy bất kỳ điểm rõ ràng nào mà SUP có thể được cấu hình thành mã trang web sai.
Jason Sypkens

Câu trả lời:


5

Có lẽ REVmã trang web đã được sử dụng để cài đặt thử nghiệm tạm thời SCCM 2012? Có lẽ không. Kiến thức thể chế không có bất kỳ hồ sơ nào về REVnó và việc di chuyển chúng tôi đã thực hiện trước khi tôi được thuê.

Linh cảm này đã đúng. Tôi đã nắm giữ người tiền nhiệm của mình và rõ ràng lần đầu tiên và không thành công để di chuyển từ SCCM 2007 sang SCCM 2010 đã sử dụng REVmã trang web. Làm thế nào nó quản lý để ngồi im trong WMI mọi lúc và tại sao nó được "kích hoạt" là một bí ẩn hoàn toàn đối với tôi.

Tôi rất cẩn thận đọc lại giải pháp trong bài đăng trên TechNet này , khuyên nên xóa các không gian tên cũ và quyết định thử nó. Tôi hơi ngại khi đánh dấu đây là một câu trả lời mặc dù nó đã giải quyết được vấn đề này, điều đó cho thấy rằng tôi hoàn toàn tán thành nó, đặc biệt là vì tôi không thể nhờ bất kỳ ai "chính thức" tại Microsoft xác nhận liệu đây có phải là một cách tiếp cận an toàn hay không hoặc hậu quả là gì khi làm điều này. Điều đó đang được nói, hãy chắc chắn rằng bạn đã sao lưu hoàn toàn máy chủ SCCM của mình hoặc ít nhất là một kiến ​​thức sâu sắc hơn nhiều về WMI trước khi tiếp tục. Bạn có thể rất dễ dàng phá vỡ mọi thứ khi làm điều này, đặc biệt là nếu như tôi, bạn không quen với WMI và SCCM tận dụng nó sâu sắc như thế nào.


Tôi đã sử dụng wbemtest để kết nối với root\smskhông gian tên trên máy chủ SCCM của chúng tôi. Từ đó tôi đã sử dụng nút [Enum_Instances ...] và tìm kiếm __NAMESPACEdưới dạng siêu lớp. Tôi đã xóa các mục cho REVmã trang web. Sau đó, tôi đã thực hiện cùng Enum_Instances cho SMS_ProviderLocationsiêu lớp và xóa mã trang web cũ khỏi không gian tên đó. Chạy lại Quy tắc triển khai tự động và xem xét việc PatchDownloader.loghiển thị tải xuống thành công từng bản cập nhật Windows.

WBEMTEST __NÊN TÊN

WBEMTEST SMS_ProviderLocation

Tôi sẽ đánh giá rất cao thông tin thêm về cách các không gian tên này được SCCM sử dụng và chính xác cách khắc phục sự cố này nếu có ai có thông tin chi tiết hơn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.