次の方法で共有


Configuration Managerでのソフトウェア更新プログラム管理のトラブルシューティング

この記事は、Configuration Managerのソフトウェア更新プログラム管理プロセスのトラブルシューティングに役立ちます。 これには、クライアント ソフトウェアの更新プログラムのスキャン、同期の問題、特定の更新プログラムに関する検出の問題が含まれます。

元の製品バージョン: Configuration Manager (現在のブランチ)、System Center 2012 R2 Configuration Manager、System Center 2012 Configuration Manager
元の KB 番号: 4505440

問題の範囲を指定する

このガイドでは、ソフトウェアの更新ポイントが既にインストールおよび構成されていることを前提としています。 Configuration Managerでのソフトウェア更新プログラムの構成の詳細については、「ソフトウェア更新プログラム管理の準備」を参照してください。

トラブルシューティングを開始する前に、発生している問題をより適切に理解し、迅速かつ簡単に修正できるようにすることを強調することが重要です。 発生している問題の修正を任されている場合でも、organizationのユーザーから報告された問題でも、少し時間を取って次の質問に答えます。

  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. スキャン エージェントは、ScanAgent.logに示されているように、WSUS の場所要求を Location Services に送信するようになりました。

    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\ScanAgentCCM_ScanJobInstance

  3. Location Services によって場所要求が作成され、管理ポイントに送信されます。 WSUS の場所要求のパッケージ ID は、更新元の一意の ID です。 In 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 メッセージングは、場所要求メッセージを管理ポイントに送信します。 In 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 の場所を取得します。 In 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. ストアド プロシージャから結果を取得した後、管理ポイントはクライアントに応答を送信します。 In 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 メッセージングは応答を受け取り、Location Services に送信します。 In 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. Location Services は応答を解析し、場所をスキャン エージェントに送信します。 In 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. スキャン エージェントに、ポリシーと更新元の場所が適切なコンテンツ バージョンになりました。 In 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 構成の変更が表示されます。 In 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. 更新ソースが正常に追加されると、スキャン エージェントによって状態メッセージが生成され、スキャンが開始されます。 In 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 [ クライアントでソフトウェア更新プログラムを有効にする] 設定を 確認します。
スキャン エージェントまたは Location Services が 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 エージェント API を使用する WUAHandler からスキャンを要求し、Windows Update エージェントからソフトウェア更新プログラムのスキャンを要求します。 スキャンの原因は次のとおりです。

  • スケジュールされたソフトウェア更新プログラムまたは手動のソフトウェア更新プログラム のスキャン
  • スケジュールされたソフトウェアまたは手動で更新された展開の再評価
  • アクティブになるデプロイ

スキャンによって評価がトリガーされます。 In ScanAgent.log:

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

スキャン結果には、サービス パックと定義の更新プログラムによって置き換えられる場合にのみ、置き換えられた更新プログラムが含まれます。 In 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クライアント for Windows 7: June 2015 を適用します。

スキャンエラーのトラブルシューティングを行うときは、WUAHandler.logファイルとWindowsUpdate.logファイルをチェックします。 WUAHandler は、エージェントが報告した内容Windows Update報告するだけです。 したがって、WUAHandler のエラーは、Windows Update エージェント自体によって報告されたエラーと同じになります。 エラーの詳細については、「WindowsUpdate.log」を参照してください。 WindowsUpdate.logの読み取り方法については、「ログ ファイルのWindows Update」を参照してください。

最適な情報ソースは、ログと、ログに含まれるエラー コードから取得されます。 エラー コードの詳細については、「Windows Update一般的なエラーと軽減策」を参照してください。

手順 3: Windows Update エージェント (WUA) が WSUS コンピューターに対してスキャンを開始する

Windows Update エージェントは、Configuration Manager クライアント (CcmExec) から要求を受信した後にスキャンを開始します。 これらのレジストリ値が、ローカル ポリシーを使用してサイトの有効な SUP である WSUS コンピューターに正しく設定されている場合は、Configuration Manager クライアントからの COM API 検索要求 (ClientId = CcmExec) が表示されます。 In 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 エージェントは WSUS コンピューター上のClientWebServiceおよび仮想ディレクトリとSimpleAuthWebService通信してスキャンを実行する必要があります。 クライアントが WSUS コンピューターと通信できない場合、スキャンは失敗します。 この問題は、次のような多くの理由で発生する可能性があります。

  • プロキシ関連の問題

    これらの問題を解決するには、「 プロキシ関連の問題によるスキャン エラー」を参照してください。

    プロキシ サーバーの詳細については、次の記事を参照してください。

  • HTTP タイムアウト エラー

    HTTP タイムアウト エラーのトラブルシューティングを行うには、まず WSUS コンピューターのインターネット インフォメーション サービス (IIS) ログを確認して、エラーが WSUS から実際に返されていることを確認します。 WSUS コンピューターがエラーを返していない場合は、中間ファイアウォールまたはプロキシに問題がある可能性があります。

    WSUS コンピューターがエラーを返している場合は、WSUS コンピューターとの接続を確認します。 それらのステップは次のとおりです。

    1. クライアントが正しい WSUS サーバーに接続していることを確認するには、Windows Update エージェント クライアントによって使用される WSUS コンピューターの URL を見つけます。 この URL は、レジストリ サブキーを確認するか、 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate WindowsUpdate.log ファイルを表示することで確認できます。

      WSUS の割り当てが正しくない可能性がある一般的な理由は次のとおりです。

      • グループ ポリシーの競合
      • 初期クライアント インストール後のセカンダリ サイトへの SUP の追加

      注:

      Active Directory グループ ポリシーは、ローカル WSUS ポリシーをオーバーライドする可能性があります。

      ソフトウェア更新機能では、Configuration Manager クライアントのローカル グループ ポリシー設定が自動的に構成され、ソフトウェアの更新ポイントのソースの場所とポート番号で構成されます。 クライアントがソフトウェアの更新ポイントを見つけるには、サーバー名とポート番号の両方が必要です。

      Active Directory グループ ポリシー設定がソフトウェアの更新ポイント クライアント インストールのコンピューターに適用されている場合は、ローカルのグループ ポリシー設定をオーバーライドします。 Active Directory グループ ポリシー で定義されている設定の値が、Configuration Managerによって設定されたものと異なる場合、クライアントでスキャンが失敗します。正しい WSUS コンピューターが見つからないためです。 この状況では、WUAHandler.logに次のメッセージが表示されます。

      グループ ポリシー設定が、サーバー <http://server> とポリシーの ENABLED に対する上位機関 (ドメイン コントローラー) によって上書きされました

      クライアントのインストールとソフトウェア更新プログラムのソフトウェアの更新ポイントは、同じサーバーである必要があります。 また、正しい名前形式とポート情報を使用して、Active Directory グループ ポリシー設定で指定する必要があります。 たとえば、 <http://server1.contoso.com:80> ソフトウェアの更新ポイントが既定の Web サイトを使用していた場合です。

    2. サーバー 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 を解決できることを確認します。

      • プロキシ構成の問題

      • その他のネットワーク関連の接続の問題。

      • ポート構成の問題があるため、ポート設定が正しいことを確認することをお勧めします。 WSUS は、80、443、8530、8531 のいずれかのポートを使用するように構成できます。

        クライアントが WSUS コンピューターと通信するには、WSUS コンピューター上のファイアウォールで適切なポートを許可する必要があります。 ポート設定は、ソフトウェアの更新ポイント サイト システムの役割が作成されるときに構成されます。 これらのポート設定は、WSUS Web サイトで使用されるポート設定と同じである必要があります。 そうしないと、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 コンピューターで、 インターネット インフォメーション サービス (IIS) マネージャーを開きます。
        2. [ サイト] を展開し、WSUS コンピューターの Web サイトを右クリックし、[ バインドの編集] をクリックします。
        3. [ サイト バインド ] ダイアログ ボックスの [ポート] 列に HTTP ポートと HTTPS ポート の値が表示されます。
        4. WSUS サーバーで、 インターネット インフォメーション サービス (IIS) マネージャーを開きます。
        5. [ Web サイト] を展開し、WSUS コンピューターの Web サイトを右クリックし、[ プロパティ] をクリックします。
        6. [ Web サイト ] タブをクリックします。HTTP ポート設定は TCP ポート で表示され、HTTPS ポート設定は SSL ポートで表示されます。
        7. Configuration Manager コンソールで、[管理>] [サイト構成>サーバー] と [サイト システムの役割] に移動し、[SiteSystemName>] 右側のウィンドウを<クリックします。
        8. 下部のウィンドウで、[ ソフトウェアの更新ポイント ] を右クリックし、[ プロパティ] をクリックします。
        9. [ 全般 ] タブに移動し、WSUS 構成ポート番号を指定または確認します。
  • 認証エラー

    これは通常、認証エラーが0x80244017 (HTTP 状態 401) または0x80244018 (HTTP 状態 403) でスキャンが失敗したときに示されます。

    まず、次のコマンドを使用して、正しい WinHTTP プロキシ設定を確認します。

    • Windows Vista 以降のバージョンでは、次の手順を実行します。 netsh winhttp show proxy
    • Windows XP の場合: proxycfg.exe

    プロキシ設定が正しい場合は、「 HTTP タイムアウト エラー」の手順を完了して、WSUS コンピューターとの接続を確認します。 また、WSUS コンピューターの IIS ログを確認して、WSUS から HTTP エラーが返されていることを確認します。 WSUS コンピューターがエラーを返していない場合は、中間ファイアウォールまたはプロキシに問題がある可能性があります。

  • 証明書の問題

    証明書の問題は、"クライアント認証を完了するために証明書が必要です" というエラー コード0x80072F0Cによって示されます。 この問題を解決するには、「 エラー 0x80072f0cでスキャンが失敗する」を参照してください。

手順 4: WUAHandler は、Windows Update エージェントから結果を受け取り、スキャンを完了としてマークします

次の情報がWUAHandler.logに記録されます。

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

手順 4 の問題のトラブルシューティング

ここでの問題は、 手順 3 のスキャン エラーと同じ方法で対処する必要があります。

このガイドで前述したように、スキャンエラーのトラブルシューティングを行うときは、WUAHandler.logファイルとWindowsUpdate.logファイルをチェックします。 WUAHandler は、エージェントが報告した内容Windows Update報告するだけです。 したがって、WUAHandler のエラーは、Windows Update エージェント自体によって報告されたのと同じエラーになります。 エラーの詳細については、「WindowsUpdate.log」を参照してください。 WindowsUpdate.logの読み取り方法については、「ログ ファイルのWindows Update」を参照してください。

ソフトウェア更新プログラムのスキャンが失敗する理由は多数あります。 これは、前述の問題の 1 つ、またはクライアントとソフトウェアの更新ポイント コンピューター間の通信またはファイアウォールの問題によって発生する可能性があります。 最適な情報ソースは、ログと、ログに含まれるエラー コードから取得されます。 エラー コードの詳細については、「Windows Update一般的なエラーと軽減策」を参照してください。

手順 5: WUAHandler がスキャン結果を解析する

その後、WUAHandler は結果を解析します。これには、各更新プログラムの適用可能性の状態が含まれます。 このプロセスの一環として、置き換えられた更新プログラムは排除されます。適用性の状態は、CCMExec によってWindows Update エージェントに送信された条件に一致するすべての更新プログラムに対してチェックされます。 ここで理解しておくべき重要な点は、更新プログラムが展開されているかどうかに関係なく、更新プログラムの適用可能性の結果を確認する必要があるということです。

次のエントリが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 エージェント自体によって報告されたのと同じエラーになります。 エラーの詳細については、「WindowsUpdate.log」を参照してください。 WindowsUpdate.logの読み取り方法については、「ログ ファイルのWindows Update」を参照してください。

一般に、ソフトウェア更新プログラムのスキャンが失敗する理由は多数あります。 これは、前述の問題の 1 つ、またはクライアントとソフトウェアの更新ポイント コンピューター間の通信またはファイアウォールの問題によって発生する可能性があります。 最適な情報ソースは、ログと、ログに含まれるエラー コードから取得されます。 リファレンスとして、「一般的なエラーと軽減策Windows Update」を参照してください。

手順 6: 更新ストアは状態を記録し、WMI の更新ごとに状態メッセージを生成します

スキャン結果が使用可能になると、これらの結果は更新ストアに格納されます。 更新ストアは、各更新プログラムの現在の状態を記録し、更新ごとに状態メッセージを作成します。 これらの状態メッセージは、ステータス メッセージ レポート サイクルの終了時 (既定では分単位) に一括でサイト サーバーに転送されます。 次の状況でのみ状態メッセージを送信します。

  • 更新プログラムに対して以前の状態メッセージが送信されたことがありません (ログ エントリ: 新しいインスタンスを作成する前に報告されていません)。
  • 更新プログラムの適用可能性の状態は、最後の状態メッセージが送信されてから変更されました。

更新プログラム (KB2862152) が記録されておらず、状態メッセージが発生している状態を示すUpdatesStore.log。

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).

状態 ID 2 (欠落) で記録されている状態メッセージを示すStateMessage.log。

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 エージェント自体によって報告されたのと同じエラーになります。 エラーの詳細については、「WindowsUpdate.log」を参照してください。 WindowsUpdate.logの読み取り方法については、「ログ ファイルのWindows Update」を参照してください。

一般に、ソフトウェア更新プログラムのスキャンが失敗する理由は多数あります。 これは、前述の問題の 1 つ、またはクライアントとソフトウェアの更新ポイント コンピューター間の通信またはファイアウォールの問題によって発生する可能性があります。 最適な情報ソースは、ログと、ログに含まれるエラー コードから取得されます。 リファレンスとして、「一般的なエラーと軽減策Windows Update」を参照してください。

手順 7: 状態メッセージが管理ポイントに送信される

WUAHandler は、Windows Update エージェントから結果を正常に受信すると、スキャンが完了としてマークされ、次のメッセージがWUAHandler.logに記録されます。

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

手順 7 の問題のトラブルシューティング

ここでの問題は 、手順 3 のスキャン エラーと同じ方法で対処する必要がありますが、この段階では特にWindowsUpdate.log ファイルでエラーが発生する可能性があります。 WindowsUpdate.logの読み取り方法については、「ログ ファイルのWindows Update」を参照してください。

一般に、ソフトウェア更新プログラムのスキャンが失敗する理由は多数あります。 これは、前述の問題の 1 つ、またはクライアントとソフトウェアの更新ポイント コンピューター間の通信またはファイアウォールの問題によって発生する可能性があります。 最適な情報ソースは、ログと、ログに含まれるエラー コードから取得されます。 リファレンスとして、「一般的なエラーと軽減策Windows Update」を参照してください。

WSUS から Microsoft Update の同期

次の手順では、WSUS と Microsoft Update の同期について説明します。 各手順を確認して、問題の場所を適切に確立します。

手順 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 の Update Services;Windows Server 2012以降のバージョン) の WSUSService は停止状態です。

  2. 次の手順に従って、WSUS コンソール MMC キャッシュをリセットします。

    1. WSUS コンソールを閉じます。
    2. WSUS サービスを停止する (WSUS 3.x でのサービスの更新;WSUS Service on Windows Server 2012 以降のバージョン)。
    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=> ネットワーク エンティティ <=> インターネット

  • WSUS ホスト コンピューターとインターネットの間にネットワーク エンティティ (プロキシ、ファイアウォール、セキュリティ フィルターなど) が存在しますか?
  • プロキシが存在し、WSUS サーバーでプロキシを使用する必要がある場合、プロキシは適切な WSUS 設定内で構成されていますか?

手順 2 の手動同期のトラブルシューティング

  1. WSUS サービスが実行されていることを確認します。 手動同期が開始されても 0% のままである場合は、WSUS サービス (WSUS 3.x の Update Services;WINDOWS SERVER 2012 以降のバージョン) の WSUS サービスが停止状態です。

  2. 次の手順を実行して、WSUS コンソール MMC キャッシュをリセットします。

    1. WSUS コンソールを閉じます。
    2. WSUS サービスを停止する (WSUS 3.x でのサービスの更新;WSUS Service on Windows Server 2012 以降のバージョン)。
    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
  • メタデータを更新する
  • 更新プログラム インストーラー (CBS、MSI)

インストールに関する問題

インストーラー (CBS、MSI、その他) とは

Cbs

Windows Vista 以降のバージョンに適用される更新プログラムの場合は、インストールを処理するために CBS が使用されます。

  1. CBS ログ (%Windir%\Logs\Cbs\Cbs.log) を収集し、最初のレビューを実行して、障害の原因を把握します。 CBS ログを使用したインストール ベースの問題のトラブルシューティングは、このガイドの範囲外です。 詳細については、「 DISM またはシステム更新準備ツールを使用して Windows 破損エラーを修正する」を参照してください。
  2. ログオンユーザーとして更新プログラムは正常にインストールされますか? その場合、システム コンテキストの下にインストールされている場合にのみ失敗しますか? この場合は、システム コンテキストの手動インストール エラーのトラブルシューティングに焦点を当てます。

MSI (Windows インストーラー)

Windows 以外のソフトウェア更新プログラムの場合、MSI を使用してインストールを処理します。

  1. 更新プログラムの既定の MSI ログを収集して確認します。 既知の問題や FAQ については、関連する KB 記事で更新プログラムを確認してください。

  2. Windows インストーラーのログ記録を有効 にし、エラーを再現します。

    結果のログを確認するときは、ログ内の戻り値 3 と、そのエントリの前の行をチェックして、エラーの分析情報を得ることができます。

  3. 同じ更新プログラムがローカル システム コンテキストで手動でインストールできないかどうかを確認します。 これを行うには、ソフトウェア更新プログラムの展開中に失敗したのと同じインストール スイッチを使用します。

    失敗した場合は、同じインストール スイッチを使用してログオン ユーザーとしてインストールをテストします。 ローカル システムでのインストールに問題があるかどうかを確認します。 正常に動作する場合は、ローカル システム コンテキストを使用して更新プログラムを適切にインストールする方法に関する問題に焦点を当てることができます。 更新プログラムまたはオンラインの KB 内の管理展開ガイダンスの確認が必要になる場合があります。

置き換えの問題

次の質問を使用して、置き換えに関連する問題の分離を試みます。

  1. 更新プログラムの有効期限Configuration Manager制御する方法については、「置き換え規則」を参照してください。
  2. Configuration Managerによって更新プログラムの有効期限が切れている場合は、最新のスーパーシング更新プログラムを展開することをお勧めします。 期限切れの更新プログラムを展開する必要がある場合は、ソフトウェアの配布またはアプリケーション管理を通じて、ソフトウェア更新プログラムの展開の外部に展開できます。
  3. 更新プログラムの置き換えロジックに特に関連する質問については、まず更新プログラムの KB 記事を参照して詳細を確認してください。 Microsoft Update Catalog、WSUS コンソール、または Configuration Manager コンソール内で置き換えを確認することもできます。

検出の問題

クライアントの更新ごとにコンプライアンス状態を判断する

  1. 更新プログラムに関する既知の問題については、更新プログラム KB の記事を参照してください。
  2. Configuration Manager クライアントで [ソフトウェア 更新 スキャン サイクル] アクションを実行します。
  3. UpdatesStore.logとWindowsUpdate.logを確認します。

更新プログラムの適用性のトラブルシューティング

  1. 更新プログラムの KB 記事を使用して、前提条件がないかどうかを確認します。 たとえば、更新プログラムでは、アプリケーションまたは OS が特定のサービス パック レベルにパッチを適用されている必要がありますか?
  2. 問題の更新プログラムの一意の更新 ID が、デプロイされているものと一致することを確認します。 たとえば、問題の更新プログラムは 32 ビットの更新ですが、64 ビット ホストを対象としていますか?

詳細

Configuration Managerでソフトウェア更新プログラムを構成する方法の詳細については、次の記事を参照してください。

また、セキュリティ、更新プログラム、コンプライアンスに関するConfiguration Managerサポート フォーラムに質問を投稿することもできます。

Configuration Managerに関する最新のニュース、情報、技術に関するヒントについては、ブログをご覧ください。