Share via

針對 Configuration Manager 中的軟體更新管理進行疑難解答

  • 發行項

本文可協助您針對 Configuration Manager 中的軟體更新管理程序進行疑難解答。 其中包括客戶端軟體更新掃描、同步處理問題，以及特定更新的偵測問題。

原始產品版本：Configuration Manager (最新分支) 、System Center 2012 R2 Configuration Manager、System Center 2012 Configuration Manager
原始 KB 編號： 4505440

界定您的問題範圍

本指南假設已安裝和設定軟體更新點。 如需在 Configuration Manager 中設定軟體更新的詳細資訊，請參閱準備軟體更新管理。

開始進行疑難解答之前，請務必強調，您越瞭解所遇到的問題，就能更快速且更輕鬆地修正問題。 無論您負責修正所遇到的問題，或組織中有人向您回報的問題，請花一點時間回答下列問題：

  1. 具體而言，哪些項目無法運作，以及/或您的目標是什麼？
  2. 問題的頻率或模式為何？ 問題仍在發生嗎？
  3. 您如何察覺到問題存在？
  4. 它是否曾運作過？ 如果是，何時停止？ 環境在停止運作之前是否有任何變更？
  5. 受影響的用戶端百分比為何？
  6. 如果有任何) 嘗試修正， (已完成哪些動作？
  7. 瞭解客戶端的確切版本和伺服器的版本。 這些系統是否為最新狀態？
  8. 受影響的用戶端有哪些共同點？ 例如，相同的子網、AD 月臺、網域、實體位置、月臺、月臺系統。

瞭解並了解這些問題的答案，可讓您快速輕鬆地解決所遇到的任何問題。

如果您知道軟體更新管理程式中想要進行疑難解答的特定區域，請在下方選取它。 如果不確定，請從用戶端軟體更新掃描開始，我們將從頭到尾逐步解說整個程式。

用戶端軟體更新掃描

下列步驟概述客戶端掃描程式。 確認每個步驟，以正確地建立問題所在位置。

步驟 1：用戶端將 WSUS 位置要求傳送至管理點

用戶端做的第一件事是將WSUS伺服器設定為其軟體更新掃描的更新來源。 該程序詳述如下。

  1. 當 Configuration Manager 用戶端需要處理軟體更新掃描時，掃描代理程式會根據可用的原則建立掃描要求，如ScanAgent.log所述：

    CScanAgent::ScanByUpdates- Policy available for UpdateSourceID={SourceID}  
ContentVersion=38  
CScanAgent::ScanByUpdates- Added Policy to final ScanRequest List UpdateSourceID={SourceID}, Policy-ContentVersion=38, Required-ContentVersion=38

  2. 掃描代理程式現在會將 WSUS 位置要求傳送至位置服務，如ScanAgent.log中所述：

    Inside CScanAgent::ProcessScanRequest()  
CScanJobManager::Scan- entered  
ScanJob({JobID}): CScanJob::Initialize- entered  
ScanJob({JobID}): CScanJob::Scan- entered  
ScanJob({JobID}): CScanJob::RequestLocations- entered  
- - - - - -Requesting WSUS Server Locations from LS for {WSUSLocationID} version 38  
- - - - - -Location Request ID = {LocationRequestID}  
CScanAgentCache::PersistInstanceInCache- Persisted Instance CCM_ScanJobInstance  
ScanJob({JobID}): - - - - - -Locations requested for ScanJobID={JobID} (LocationRequestID={LocationRequestID}), will process the scan request once locations are available.

    提示

    每個掃描作業都會儲存在 類別的 WMI 中 CCM_ScanJobInstance ：

    命名空間： root\CCM\ScanAgent 類別： CCM_ScanJobInstance

  3. 位置服務會建立位置要求，並將其傳送至管理點。 WSUS 位置要求的套件標識碼是更新來源的唯一標識碼。 在 LocationServices.log中：

    CCCMWSUSLocation::GetLocationsAsyncEx  
Attempting to persist WSUS location request for ContentID='{ContentID}' and ContentVersion='38'  
Persisted WSUS location request LocationServices  
Attempting to send WSUS Location Request for ContentID='{ContentID}'
WSUSLocationRequest : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest>  
Created and Sent Location Request '{LocationRequestID}' for package {ContentID}

  4. CCM 傳訊會將位置要求訊息傳送至管理點。 在CcmMessaging.log中：

    Sending async message '{Message}' to outgoing queue 'mp:[http]mp_locationmanager'  
Sending outgoing message '{Message}'. Flags 0x200, sender account empty

  5. 管理點會剖析此要求，並呼叫 MP_GetWSUSServerLocations 預存程式以從資料庫取得WSUS位置。 在MP_Location.log中：

    MP LM: Message Body : \<WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> MP_LocationManager  
MP LM: calling MP_GetWSUSServerLocations

    在 SQL Server Profiler：

    exec MP_GetMPSitesFromAssignedSite N'PS1'  
exec MP_GetSiteInfoUnified N'<ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2-PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo>'  
exec MP_GetWSUSServerLocations N'{WSUSServerLocationsID}',N'38',N'PS1',N'PS1',N'0',N'CONTOSO.COM'

  6. 從預存程式取得結果之後，管理點會將回應傳送至用戶端。 在MP_Location.log中：

    MP LM: Reply message body: <WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply>

  7. CCM 傳訊會接收回應，並將其傳送回位置服務。 在CcmMessaging.log中：

    Message '{Message1}' got reply '{Message2}' to local endpoint queue 'LS_ReplyLocations'  
OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={*Message1*}):  
Delivered successfully to host 'PS1SYS.CONTOSO.COM'.  
Message '{Message2}' delivered to endpoint 'LS_ReplyLocations'

  8. 位置服務會剖析回應，並將位置傳送回掃描代理程式。 在 LocationServices.log中：

    Processing Location reply message LocationServices  
WSUSLocationReply : <WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" Version="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply>  
Calling back with the following WSUS locations  
WSUS Path='http://PS1SITE.CONTOSO.COM:8530', Server='PS1SITE.CONTOSO.COM', Version='38'  
WSUS Path='https://PS1SYS.CONTOSO.COM:8531', Server='PS1SYS.CONTOSO.COM', Version='38'  
Calling back with locations for WSUS request {WSUSLocationID}

  9. 掃描代理程式現在具有具有適當內容版本的原則和更新來源位置。 在 ScanAgent.log：

    *****WSUSLocationUpdate received for location request guid={LocationGUID}  
ScanJob({JobID}): CScanJob::OnLocationUpdate- Received  
Location=<http://PS1SITE.CONTOSO.COM:8530>, Version=38  
ScanJob({JobID}): CScanJob::Execute- Adding UpdateSource={SourceID}, ContentType=2, ContentLocation=<http://PS1SITE.CONTOSO.COM:8530>, ContentVersion=38

  10. 掃描代理程式會通知 WUAHandler 新增更新來源。 WUAHandler 會將更新來源新增至登錄。 如果客戶端位於網域中，它會起始 群組原則 重新整理，以查看 群組原則 是否覆寫已新增的更新伺服器。 下列專案會登入WUAHandler.log顯示新增的更新來源：

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it  
Its a completely new WSUS Update Source  
Enabling WUA Managed server policy to use server: <http://PS1SITE.CONTOSO.COM:8530>
Policy refresh forced  
Waiting for 2 mins for Group Policy to notify of WUA policy change  
Waiting for 30 secs for policy to take effect on WU Agent.  
Added Update Source ({UpdateSource}) of content type: 2

    在此期間，Windows Update 代理程式會看到 WSUS 組態變更。 在 WindowsUpdate.log：

    * WSUS server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
* WSUS status server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
Sus server changed through policy.

    系統會檢查並設定下列登入機碼：

    登錄子機碼 數值名稱 類型 資料
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate WUServer REG_SZ 包含埠的完整 WSUS 伺服器 URL。 例如，<http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate WUStatusServer REG_SZ 包含埠的完整 WSUS 伺服器 URL。 例如，<http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU UseWUServer REG_DWORD 0x1

    對於現有的客戶端，我們可能會在WUAHandler.log中看到下列訊息，以表示內容版本已遞增時：

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it.  
WSUS update source already exists, it has increased version to 38.

  11. 成功新增更新來源之後，掃描代理程式會引發狀態消息並啟動掃描。 在 ScanAgent.log：

    ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2  
ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1

針對步驟 1 中的問題進行疑難解答

問題 檢查項目
ScanAgent.log顯示更新來源沒有可用的原則，也沒有任何WUAHandler.log存在，或WUAHandler.log 檢查 [ 在用戶端上啟用軟體更新 ] 設定。
掃描代理程式或位置服務未收到 WSUS 伺服器位置

  • 是否已為月臺安裝軟體更新點 (SUP) 角色？

    如果沒有，請安裝和設定軟體更新點，並監視SUPSetup.log進度。 如需詳細資訊，請 參閱安裝和設定軟體更新點。

  • 如果已安裝 SUP 角色，是否已設定並同步處理？

    檢查WCM.log、WSUSCtrl.log和WSyncMgr.log是否有錯誤。

    • select * from WSUSServerLocations
    • select * from Update_SyncStatus
用戶端會接收 WSUS 位置，但無法設定 WSUS 登錄機碼

群組原則 重新整理是否在每個WUAHandler.log的 2 分鐘逾時內回應？ 如果是，WUAHandler 是否表示域 控制器 (域控制器) 覆寫組策略設定 ？

如需詳細資訊，請參閱 群組原則 覆寫正確的 WSUS 設定資訊。

如需軟體更新掃描失敗疑難解答的詳細資訊，請參閱 針對軟體更新掃描失敗進行疑難解答。

步驟 2：掃描代理程式要求掃描，WUAHandler 啟動掃描

在客戶端識別並設定 WSUS 伺服器作為其軟體更新掃描的更新來源之後，掃描代理程式會向使用 Windows Update Agent API 的 WUAHandler 要求掃描，以向 Windows Update Agent 要求軟體更新掃描。 掃描可能是由下列項目產生：

  • 排程或手動軟體更新掃描
  • 已排程或手動更新的軟體部署重新評估
  • 變成作用中的部署

掃描會觸發評估。 在 ScanAgent.log：

ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1

只有當 Service Pack 和定義更新取代已取代的更新時，掃描結果才會包含這些更新。 在 WUAHandler.log：

Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')  
Running single-call scan of updates.  
Async searching of updates using WUAgent started.

提示

檢閱軟體更新掃描之後的WUAHandler.log，以查看是否有任何新的項目發生。 如果未發生任何新專案，則表示管理點不會傳回任何 SUP。

針對步驟 2 中的問題進行疑難解答

軟體更新掃描的許多問題可能是下列其中一個原因所造成：

  • 遺失或損毀的檔案或登錄機碼。
  • 組件註冊問題。

若要修正這類問題，請參閱 掃描因遺失或損毀元件而導致的失敗。

已知有一個問題，要求更新掃描的32位 Windows 7 ConfigMgr 2012 R2 用戶端無法將掃描結果傳回 Configuration Manager。 這會導致客戶端回報不正確的合規性狀態，而且當 Configuration Manager 要求更新週期時，更新無法安裝。 不過，如果您使用 Windows Update 控制面板小程式，更新通常會正常安裝。 當您遇到此問題時，您會收到類似下列WindowsUpdate.log訊息：

WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E

這是記憶體配置問題，因為64位 Windows 7 電腦的位址空間實際上不受限制，所以不會看到此錯誤。 不過，它們會呈現高記憶體和高 CPU 使用量，可能會影響效能。 X86 用戶端也會呈現高記憶體使用量 (通常大約 1.2 GB 到 1.4 GB) 。

若要修正此問題，請套用 Windows Update Client for Windows 7：2015 年 6 月。

針對掃描失敗進行疑難解答時，請檢查WUAHandler.log和WindowsUpdate.log檔案。 WUAHandler 只會報告 Agent Windows Update 報告的內容。 因此，WUAHandler 中的錯誤會與 Windows Update Agent 本身所報告的錯誤相同。 如需錯誤的詳細資訊，請參閱WindowsUpdate.log。 若要瞭解如何讀取WindowsUpdate.log，請參閱 Windows Update 記錄檔。

您的最佳資訊來源將來自記錄及其包含的錯誤碼。 如需錯誤碼的詳細資訊，請參閱 Windows Update 常見錯誤和緩和措施。

步驟 3：Windows Update 代理程式 (WUA) 對 WSUS 計算機啟動掃描

Windows Update Agent 會在收到來自 Configuration Manager 用戶端 (CcmExec) 的要求之後，開始掃描。 如果這些登錄值已透過本機原則正確設定為月臺的有效 SUP 的 WSUS 計算機，您應該會看到來自 Configuration Manager 用戶端的 COM API 搜尋要求 (ClientId = CcmExec) 。 在 WindowsUpdate.log：

COMAPI -- START -- COMAPI: Search [ClientId = CcmExec]  
COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec] PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent ** START ** Agent: Finding updates [CallerId = CcmExec]  
Agent * Include potentially superseded updates  
Agent * Online = Yes; Ignore download priority = Yes  
Agent * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"  
Agent * ServiceID = {ServiceID} Managed  
Agent * Search Scope = {Machine}

PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent * Added update {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 to search result  
Agent * Added update {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 to search result  
Agent * Found 163 updates and 70 categories in search; evaluated appl. rules of 622 out of 1150 deployed entities  
Agent ** END ** Agent: Finding updates [CallerId = CcmExec]  
COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec]  
COMAPI - Updates found = 163  
COMAPI -- END -- COMAPI: Search [ClientId = CcmExec]

針對步驟 3 中的問題進行疑難解答

在掃描期間，Windows Update 代理程式必須與 ClientWebService WSUS 電腦上的 和 SimpleAuthWebService 虛擬目錄通訊，才能執行掃描。 如果客戶端無法與 WSUS 計算機通訊，掃描將會失敗。 此問題可能會因為許多原因而發生，包括：

  • Proxy 相關問題

    若要修正這些問題，請參閱 掃描因 Proxy 相關問題而導致的失敗。

    如需 Proxy 伺服器的詳細資訊，請參閱下列文章：

  • HTTP 逾時錯誤

    若要針對 HTTP 逾時錯誤進行疑難解答，請先檢閱 WSUS 電腦上的 Internet Information Services (IIS) 記錄，以確認錯誤實際上是從 WSUS 傳回。 如果 WSUS 電腦未傳回錯誤，問題可能是中繼防火牆或 Proxy。

    如果 WSUS 電腦傳回錯誤，請確認與 WSUS 計算機的連線能力。 步驟如下：

    1. 若要確認用戶端連線到正確的 WSUS 伺服器，請尋找 Windows Update Agent 用戶端所使用的 WSUS 計算機 URL。 檢查登錄子機碼或檢視WindowsUpdate.log檔案，即可找到 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate 此 URL。

      WSUS 指派可能不正確的常見原因包括：

      • 群組原則 衝突
      • 在初始用戶端安裝之後，將 SUP 新增至次要月臺

      注意事項

      Active Directory 群組原則 可能會覆寫本機 WSUS 原則。

      軟體更新功能會自動設定 Configuration Manager 用戶端的本機 群組原則 設定，以便使用軟體更新點來源位置和埠號碼進行設定。 需要伺服器名稱和埠號碼，用戶端才能找到軟體更新點。

      如果 Active Directory 群組原則 設定套用至電腦以進行軟體更新點用戶端安裝，它會覆寫本機 群組原則 設定。 如果 Active Directory 群組原則 中定義的設定值與 Configuration Manager 所設定的值不同，則掃描會在用戶端上失敗，因為它找不到正確的 WSUS 計算機。 在此情況下，WUAHandler.log會顯示下列訊息：

      域控制器 (域控制器) 覆寫組策略設定：伺服器 <http://server> 和原則啟用

      用戶端安裝和軟體更新的軟體更新點必須是相同的伺服器。 而且必須在 Active Directory 群組原則 設定中指定，並具有正確的名稱格式和埠資訊。 例如，如果軟體更新點使用預設網站，則為 <http://server1.contoso.com:80> 。

    2. 如果伺服器 URL 正確，請使用類似下列 URL 的 URL 來存取伺服器，以確認用戶端與 WSUS 計算機之間的連線能力：

      <http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab>

      若要檢查用戶端是否可以存取 ClientWebService 虛擬目錄，請嘗試存取類似下列的 URL：

      <http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml>

      若要檢查用戶端是否可以存取 SimpleAuthWebService，請嘗試存取類似下列的 URL：

      <http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx>

      如果其中任何一個 URL 失敗，某些可能的原因包括：

      • 用戶端上的名稱解析問題。 確認您可以解析 WSUS 計算機的 FQDN。

      • Proxy 設定問題。

      • 其他網路相關連線問題。

      • 埠設定有問題，因此最好確認埠設定正確無誤。 WSUS 可以設定為使用下列任何埠：80、443 或 8530、8531。

        若要讓用戶端與 WSUS 計算機通訊，必須在 WSUS 計算機的防火牆上允許適當的埠。 建立軟體更新點站台系統角色時，會設定埠設定。 這些埠設定必須與 WSUS 網站所使用的埠設定相同。 否則，WSUS 同步處理管理員將無法連線到軟體更新點上執行的 WSUS，以要求同步處理。 下列程式提供如何驗證 WSUS 和軟體更新點所使用之埠設定的相關信息。

        1. 判斷 IIS 7.0 和更新版本中使用的 WSUS 埠設定。

        2. 決定 IIS 6.0 中的 WSUS 埠設定。

        3. 設定軟體更新點的埠。

        4. 確認埠連線能力

          若要檢查來自用戶端的埠連線能力，請執行下列命令：

          telnet SUPSERVER.CONTOSO.COM <portnumber>

          例如，如果埠為 8530，請執行下列命令：

          telnet SUPSERVER.CONTOSO.COM 8530

          如果無法存取埠，telnet 會傳回類似下列錯誤：

          無法在埠 <PortNumber 上開啟與主機的連線>

          此錯誤表示防火牆規則未設定為允許 WSUS 計算機的通訊。 此錯誤也可能表示中繼網路裝置封鎖該埠。 若要確認，請嘗試從相同本機子網上的用戶端進行相同的測試。 如果可以運作，則會正確設定計算機。 不過，區段之間的路由器或防火牆會封鎖埠並導致失敗。

      • IIS 可用性問題。

        1. 在 WSUS 計算機上，開啟 Internet Information Services (IIS) Manager。
        2. 展開 [網站]，以滑鼠右鍵按兩下 WSUS 電腦的網站，然後按兩下 [ 編輯系結]。
        3. 在 [ 月台系結] 對話框中，HTTP 和 HTTPS 連接埠值會顯示在 [ 埠] 資料 行中。
        4. 在 WSUS 伺服器上，開啟 Internet Information Services (IIS) Manager。
        5. 展開 [網站]，以滑鼠右鍵按兩下 WSUS 電腦的網站，然後按兩下 [ 屬性]。
        6. 按兩下 [ 網站] 索引標籤 。HTTP 連接埠設定會顯示在 TCP 連接埠 中，而 HTTPS 連接埠設定會顯示在 SSL 埠中。
        7. 在 Configuration Manager 控制台中，移至 [系統管理>網站>設定伺服器] 和 [月台系統角色]，然後按兩下 <[SiteSystemName>] 右側窗格。
        8. 在底部窗格中，以滑鼠右鍵按兩下 [軟體更新點] ，然後按兩下 [ 內容]。
        9. 移至 [ 一般] 索引標籤，指定或驗證 WSUS 設定埠號碼。

  • 驗證錯誤

    當掃描失敗時，通常會指出 HTTP 狀態 401) 或0x80244018 (HTTP 狀態 403) 0x80244017 (验证错误。

    首先，使用下列命令確認正確的 WinHTTP Proxy 設定：

    • 在 Windows Vista 或更新版本上： netsh winhttp show proxy
    • 在 Windows XP 上： proxycfg.exe

    如果 Proxy 設定正確無誤，請完成 HTTP 逾時錯誤中的步驟，以確認與 WSUS 計算機的連線能力。 另請檢閱 WSUS 電腦上的 IIS 記錄，以確認 HTTP 錯誤正從 WSUS 傳回。 如果 WSUS 電腦未傳回錯誤，問題可能是中繼防火牆或 Proxy。

  • 憑證問題

    憑證問題是由錯誤碼0x80072F0C表示「需要憑證才能完成客戶端驗證」。 若要修正此問題，請參閱 掃描失敗並出現錯誤0x80072f0c。

步驟 4：WUAHandler 接收來自 Windows Update Agent 的結果，並將掃描標示為完成

下列專案會登入WUAHandler.log：

Async searching completed.  
Finished searching for everything in single call.

針對步驟 4 中的問題進行疑難解答

此處的問題解決方式應與 步驟 3 中的掃描失敗相同。

如本指南稍早所述，針對掃描失敗進行疑難解答時，請檢查WUAHandler.log和WindowsUpdate.log檔案。 WUAHandler 只會報告代理程式 Windows Update 報告的內容。 因此，WUAHandler 中的錯誤會與 Windows Update Agent 本身所報告的錯誤相同。 如需錯誤的詳細資訊，請參閱WindowsUpdate.log。 若要瞭解如何讀取WindowsUpdate.log，請參閱 Windows Update 記錄檔。

有許多原因會導致軟體更新掃描失敗。 這可能是因為稍早所述的其中一個問題，或用戶端與軟體更新點計算機之間的通訊或防火牆問題所造成。 您的最佳資訊來源將來自記錄及其包含的錯誤碼。 如需錯誤碼的詳細資訊，請參閱 Windows Update 常見錯誤和緩和措施。

步驟 5：WUAHandler 剖析掃描結果

WUAHandler 接著會剖析結果，其中包含每個更新的適用性狀態。 在此程式中，會剪除已取代的更新。系統會檢查所有符合 CCMExec 提交至 Windows Update Agent 之準則的更新適用性狀態。 請務必瞭解，無論這些更新是否在部署中，您都應該看到更新的適用性結果。

下列項目會記錄在 WUAHandler.log：

> Pruning: update id (70f4f236-0248-4e84-b472-292913576fa1) is superseded by (726b7201-862a-4fde-9b12-f36b38323a6f).  
> ...  
> Update (Installed): Security Update for Windows 7 for x64-based Systems (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104)  
> Update (Missing): Security Update for Windows 7 for x64-based Systems (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200)  
> ...  
> Successfully completed scan.

針對步驟 5 中的問題進行疑難解答

問題的解決方式與 步驟 3 中的掃描失敗相同。

如本指南稍早所述，針對掃描失敗進行疑難解答時，請檢查WUAHandler.log和WindowsUpdate.log檔案。 WUAHandler 只會報告代理程式 Windows Update 報告的內容。 因此，WUAHandler 中的錯誤會與 Windows Update Agent 本身所報告的錯誤相同。 如需錯誤的詳細資訊，請參閱WindowsUpdate.log。 若要瞭解如何讀取WindowsUpdate.log，請參閱 Windows Update 記錄檔。

一般而言，軟體更新掃描可能會失敗的原因有很多。 這可能是因為稍早所述的其中一個問題，或用戶端與軟體更新點計算機之間的通訊或防火牆問題所造成。 您的最佳資訊來源將來自記錄及其包含的錯誤碼。 如需參考，請參閱 Windows Update 常見錯誤和緩和措施。

步驟 6：更新存放區會記錄狀態，並針對 WMI 中的每個更新引發狀態消息

一旦掃描結果可用，這些結果就會儲存在更新存放區中。 更新存放區會記錄每個更新的目前狀態，併為每個更新建立狀態消息。 根據預設，這些狀態消息會在狀態消息報告週期 (結束時大量轉送至月臺伺服器) 。 在下列情況下，我們只會傳送狀態消息：

  • 先前的狀態消息從未針對更新 (記錄專案傳送： 之前尚未回報，) 建立新的 實例。
  • 自上次提交狀態消息以來，更新的適用性狀態已變更。

UpdatesStore.log顯示所記錄更新 (KB2862152) 遺失的狀態，以及引發狀態消息：

Processing update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) with ProductID = 0fa1201d-4330-4fa8-8ae9b877473b6441  
Update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) hasn't been reported before, creating new instance.  
Successfully raised state message for update (505fda07-b4f3-45fb-83d9-8642554e2773) with state (Missing).  
Successfully added WMI instance of update status (505fda07-b4f3-45fb-83d9-8642554e2773).

StateMessage.log顯示已記錄狀態訊息， 且狀態標識碼為 2 (遺失) ：

Adding message with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 to WMI  
State message(State ID : 2) with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 has been recorded for SYSTEM

提示

針對每個更新，會建立或更新 類別的 CCM_UpdateStatus 實例，並儲存更新的目前狀態。 類別 CCM_UpdateStatus 位於 命名空間中 ROOT\CCM\SoftwareUpdates\UpdatesStore 。

針對步驟 6 中的問題進行疑難解答

此處的問題解決方式應與 步驟 3 中的掃描失敗相同。

如本指南稍早所述，針對掃描失敗進行疑難解答時，請檢查WUAHandler.log和WindowsUpdate.log檔案。 WUAHandler 只會報告代理程式 Windows Update 報告的內容。 因此，WUAHandler 中的錯誤會與 Windows Update Agent 本身所報告的錯誤相同。 如需錯誤的詳細資訊，請參閱WindowsUpdate.log。 若要瞭解如何讀取WindowsUpdate.log，請參閱 Windows Update 記錄檔。

一般而言，軟體更新掃描可能會失敗的原因有很多。 這可能是因為稍早所述的其中一個問題，或用戶端與軟體更新點計算機之間的通訊或防火牆問題所造成。 您的最佳資訊來源將來自記錄及其包含的錯誤碼。 如需參考，請參閱 Windows Update 常見錯誤和緩和措施。

步驟 7：狀態消息會傳送至管理點

當 WUAHandler 成功收到來自 Windows Update Agent 的結果時，它會將掃描標示為完成，並在 WUAHandler.log 中記錄下列訊息：

Async searching completed. WUAHandler  
Finished searching for everything in single call

針對步驟 7 中的問題進行疑難解答

此處的問題應該以與 步驟 3 中的掃描失敗相同的方式來解決，雖然此階段的失敗可能會特別出現在WindowsUpdate.log檔案中。 若要瞭解如何讀取WindowsUpdate.log，請參閱 Windows Update 記錄檔。

一般而言，軟體更新掃描可能會失敗的原因有很多。 這可能是因為稍早所述的其中一個問題，或用戶端與軟體更新點計算機之間的通訊或防火牆問題所造成。 您的最佳資訊來源將來自記錄及其包含的錯誤碼。 如需參考，請參閱 Windows Update 常見錯誤和緩和措施。

WSUS 至 Microsoft Update 同步處理

下列步驟概述與 Microsoft Update 同步處理的 WSUS。 確認每個步驟，以正確地建立問題所在位置。

步驟 1：同步處理會從排程或手動要求開始

觸發同步處理時，我們預期會在 WSUS 伺服器的SoftwareDistribution.log中看到下列訊息：

手動同步處理：

Changew3wp.6AdminDataAccess.StartSubscriptionManuallySynchronization manually started  
Info WsusService.27EventLogEventReporter.ReportEvent  
EventId=382,Type=Information,Category=Synchronization,Message=A manual synchronization was started.

針對排程同步處理：

InfoWsusService.10EventLogEventReporter.ReportEvent  
EventId=381,Type=Information,Category=Synchronization,Message=A scheduled synchronization was started.

針對步驟 1 中的手動同步進行疑難解答

  1. 確認 WSUS 服務正在執行。 如果手動同步處理已啟動，但維持在 0%，這是因為 WSUS 服務 (WSUS 3.x 上的更新服務;Windows Server 2012 和更新版本上的 WSUSService) 處於已停止狀態。

  2. 依照下列步驟重設 WSUS 控制台 MMC 快取：

    1. 關閉 WSUS 控制台。
    2. 停止 WSUS 3.x 上的 WSUS 服務 (更新服務;Windows Server 2012 和更新版本上的 WSUS 服務) 。
    3. 瀏覽至 %appdata%\Microsoft\mmc。
    4. 將 wsus 重新命名為 wsus_bak。
    5. 啟動 WSUS 服務。
    6. 開啟 WSUS 控制台，然後嘗試另一個手動同步處理。

針對步驟 1 中的排程同步進行疑難解答

  1. 嘗試從 WSUS 控制台進行手動同步處理。
  2. 如果手動同步處理正常運作，請檢查排定的同步處理設定。

步驟 2：WSUS 會繁衍與 Microsoft Update (MU 連線)

同步處理開始之後，WSUS 伺服器會嘗試透過 WinHTTP 建立 HTTP 連線。 針對連線進行疑難解答時，請考慮下列因素：

WSUS <=winHTTP=> 網络實體 <=> 因特網

  • 網路實體是否 (Proxy、防火牆、安全性篩選器等) 存在於 WSUS 主計算機與因特網之間？
  • 如果 Proxy 存在，而且需要 WSUS 伺服器才能使用 Proxy，則 Proxy 是否已在適當的 WSUS 設定內設定？

針對步驟 2 中的手動同步進行疑難解答

  1. 確認 WSUS 服務正在執行。 如果手動同步處理已啟動，但保持在 0%，這是因為 WSUS 服務 (WSUS 3.x 上的更新服務;Windows Server 2012 和更新版本上的 WSUS 服務) 處於停止狀態。

  2. 完成下列步驟來重設 WSUS 控制台 MMC 快取：

    1. 關閉 WSUS 控制台。
    2. 停止 WSUS 3.x 上的 WSUS 服務 (更新服務;Windows Server 2012 和更新版本上的 WSUS 服務) 。
    3. 瀏覽至 %appdata%\Microsoft\mmc。
    4. 將 wsus 重新命名為 wsus_bak。
    5. 啟動 WSUS 服務。
    6. 開啟 WSUS 控制台，然後嘗試另一個手動同步處理。

針對步驟 2 中的排程同步進行疑難解答

  1. 嘗試從 WSUS 控制台進行手動同步處理。
  2. 如果手動同步處理正常運作，請檢查排定的同步處理設定。

步驟 3：WSUS 計算機會從 Microsoft Update 和任何訂閱的元數據接收產品和分類資訊

在 WSUS 從 Microsoft Update 接收產品和分類資訊以及任何訂閱的元數據之後，WSUS 同步處理就會完成。

特定更新的安裝、取代或偵測問題

特定更新所發生的部署問題可以分成下列區域。 當您開始進行疑難解答時，請考慮下列與這些區域相關聯的元件。

Areas 安裝 取代 偵測
元件
  • WUA
  • 更新安裝程式 (元件型服務 (CBS) 、MSI)
  • CCMExec
 更新元數據
  • WUA
  • 更新元數據
  • UPDATE Installer (CBS， MSI)

安裝問題

CBS、MSI 和其他) (安裝程序是什麼？

Cbs

針對適用於 Windows Vista 和更新版本的更新，CBS 可用來處理安裝。

  1. 收集 CBS 記錄 (%Windir%\Logs\Cbs\Cbs.log) 並執行初始檢閱，以深入了解失敗的原因。 透過 CBS 記錄針對安裝型問題進行疑難解答已超出本指南的範圍。 如需詳細資訊，請參閱 使用 DISM 或系統更新整備工具修正 Windows 損毀錯誤。
  2. 以已登入的使用者身分成功安裝更新嗎？ 如果是，它只有在安裝在系統內容下時才會失敗嗎？ 在此情況下，請專注於針對系統內容下的手動安裝失敗進行疑難解答。

MSI (Windows Installer)

針對非 Windows 軟體更新，會使用 MSI 來處理安裝。

  1. 收集並檢閱更新的預設 MSI 記錄。 如需任何已知問題或常見問題的更新，請查看相關聯的 KB 文章。

  2. 啟用 Windows Installer 記錄 並重現失敗。

    檢閱產生的記錄時，請檢查記錄檔內的傳回值 3，以及該專案前面的行，以深入了解失敗。

  3. 檢查相同的更新是否無法在本機系統內容下手動安裝。 若要這樣做，請使用軟體更新部署期間失敗的相同安裝參數。

    如果失敗，請以具有相同安裝參數的登入使用者身分測試安裝。 檢查是否在本機系統下安裝時發生問題。 如果可以運作，您可以接著將問題焦點放在如何使用本機系統內容正確安裝更新。 可能需要檢查 KB 內的系統管理部署指引以取得更新或在線。

取代問題

嘗試使用下列問題來找出與取代相關的問題：

  1. 如需如何控制更新 Configuration Manager 何時到期的問題，請參閱取代規則。
  2. 如果更新已由 Configuration Manager 過期，Microsoft 建議部署最新的取代更新。 如果您仍然需要部署過期的更新，可以透過軟體發佈或應用程式管理，在軟體更新部署外部部署這些更新。
  3. 如需與更新取代邏輯特別相關的問題，請先檢閱 KB 文章以取得更新的進一步資訊。 您也可以檢閱 Microsoft Update Catalog、WSUS 控制台或 Configuration Manager 控制台內的取代。

偵測問題

判斷用戶端上每個更新的合規性狀態

  1. 如需更新的已知問題，請檢閱更新 KB 一文。
  2. 在 Configuration Manager 客戶端上執行軟體 匯報 掃描迴圈動作。
  3. 檢閱UpdatesStore.log和WindowsUpdate.log。

針對更新適用性進行疑難解答

  1. 使用 KB 文章進行更新，檢查是否遺漏任何必要條件。 例如，更新是否需要將應用程式或OS修補到特定ServicePack層級？
  2. 確認有問題的更新的唯一更新標識元符合已部署的專案。 例如，有問題的更新是否為32位更新，但目標為64位主機？

其他相關資訊

如需如何在 Configuration Manager 中設定軟體更新的詳細資訊，請參閱下列文章：

您也可以在我們的 Configuration Manager 支援論壇中張貼安全性、更新和合規性的問題。

如需有關 Configuration Manager 的所有最新消息、資訊和技術秘訣，請造訪我們的部落格。