ソフトウェア更新プログラムのコンプライアンス評価を追跡する

適用対象: Configuration Manager

ソフトウェア更新プログラムをクライアントに展開する前に、クライアントはソフトウェア更新プログラムのコンプライアンス スキャンを実行する必要があります。 クライアントがスキャンを完了してコンプライアンスの結果を報告し、コンプライアンスの結果を確認し、クライアントに必要な更新プログラムのみを展開できるように、十分な時間を取ることをお勧めします。

ソフトウェアの更新ポイント (SUP) がインストールされ、同期されると、サイト全体のコンピューター ポリシーが作成され、Configuration Manager ソフトウェア更新プログラムがサイトに対して有効にされたことをクライアント コンピューターに通知します。 クライアントがコンピューター ポリシーを受信すると、コンプライアンス対応評価スキャンが次の 2 時間以内にランダムで開始するようスケジュールされます。 スキャンが開始されると、ソフトウェア更新クライアント エージェント プロセスによってスキャン履歴がクリアされ、スキャンに使用する Windows Server Update Services (WSUS) サーバーを検索する要求が送信され、WSUS の場所でローカル グループ ポリシーが更新されます。

コンプライアンス評価プロセスの概要については、「 Software 更新プログラムのコンプライアンス評価」を参照してください。

ソフトウェア更新プログラムのスキャン ポリシー

クライアントが更新プログラムのスキャンを試みる前に、UpdateSource ポリシーが必要です。 このポリシーは、SUP の同期が成功した後、サイト サーバー上に作成されます。 このセクションでは、次のプロセスによってこのポリシーがどのように作成されるかについて説明します。

手順 1: 同期が成功した後、WSyncMgr はデータベースのコンテンツ バージョンと最終同期時刻を更新します

プライマリ サイトでの同期が正常に完了すると、WSyncMgr は SUP のデータベースおよび Content バージョンを更新します。 これを行うには、 spProcessSUMSyncStateMessage ストアド プロシージャを実行します。 次のサンプル SQL Server プロファイラー トレースでは、このストアド プロシージャを実行してコンテンツ バージョンを 36 に更新します。

@Error int を宣言します。 exec spProcessSUMSyncStateMessage N'2014-01-17 17:59:54', N'PS1', N'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}', 1, 0, '36', @Error output, N'PS1SITE.CONTOSO。COM'

手順 2: SMSDBMON がトリガーされ、削除されます。policypv.box の STN ファイル

spProcessSUMSyncStateMessage は、 Update_SyncStatus テーブルを新しいコンテンツ バージョンと同期時間で更新します。 Update_SyncStatus テーブルに対するこの更新により、SMSDBMON がトリガーされ、<UpdateSource_UniqueID>が削除されます。スキャン ツール定義の変更を示すために、policypv.box の STN ファイル (STN はスキャン ツール通知を表します)。 次のコードがSMSDBMON.logに記録されます。

RCV: UpdSyncStatus_iuのUpdate_SyncStatusの更新 [{C2D17964-BBDD-4339-B9F3-12D7205B39CC}][46680] SMS_DATABASE_NOTIFICATION_MONITOR
SND: Dropped E:\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}。STN (0 以外) [46680] SMS_DATABASE_NOTIFICATION_MONITOR

手順 3: ポリシー プロバイダーがデータベース内の UpdateSource ポリシーを作成または更新する

<UpdateSource_UniqueID>。STN ファイルは、データベース内の UpdateSource ポリシーをウェイクアップして更新する必要があることをポリシー プロバイダーに通知します。

次のコードがPolicyPv.logに記録されます。

{C2D17964-BBDD-4339-B9F3-12D7205B39CC} が見つかりました。STN SMS_POLICY_PROVIDER
スキャン ツール ID {C2D17964-BBDD-4339-B9F3-12D7205B39CC} を追加しました SMS_POLICY_PROVIDER
削除リストへの追加: E:\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}。STN SMS_POLICY_PROVIDER

SQL Server プロファイラー トレースで次の手順を実行します。

SettingsPolicy から PolicyID、PolicyAssignmentID、SourceCRC、PADBID を選択します。sourceID = N'PS1' と SourceType = N'UpdateSource'

PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}'
IF EXISTS (PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}') 更新ポリシー セット バージョン = N'40.00' where PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}' ELSE insert Policy (PolicyID, Version) values (N'{d0855677- b0a6-4e33-9bd5-7b0d06f0a2be}', N'40.00')

exec sp_describe_undeclared_parameters N'UPDATE Policy SET Body = @P1 where PolicyID = N''{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}'''
IF EXISTS (SELECT PADBID from PolicyAssignment where PADBID = 16777218) update PolicyAssignment set Version = N'40.00', InProcess = 1 , BodyHash = null where PADBID = 16777218 ELSE insert PolicyAssignment (PolicyAssignmentID, PADBID, Version, PolicyID) 値 (N'{375c8020-3cae-4736-89ca-ccf1ce6e3709}', 16777218, N'40.00', N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}')

exec sp_describe_undeclared_parameters N'UPDATE PolicyAssignment SET Body = @P1 where PADBID = 16777218'

update PolicyAssignment set InProcess = 0, BodySignature = N'<BodySignatureTruncated>', TombstoneBodySignature = N'<TombstoneBodySignatureTruncated>', HashAlgOID = N'1.2.840.113549.1.11',HashAlgId = 32780, BodyHash = N'<BodyHashTruncated>', TombstoneBodyHash = N'<TombstoneBodyHashTruncated>' where PADBID = 16777218

データベースでこのポリシーを表示するには、次のクエリを実行します。

SELECT CONVERT(XML, Body, 1), * FROM Policy WHERE PolicyID = (SELECT PolicyID FROM SettingsPolicy WHERE SourceType = 'UpdateSource')

このポリシーには、クライアントがスキャンできる WSUS コンピューターの場所を検索するために使用される更新サーバーのコンテンツ バージョンが含まれています。 このポリシーがデータベースで作成または更新されると、クライアントは次のポリシー評価サイクル中に新しい UpdateSource ポリシーまたは更新された UpdateSource ポリシーを取得します。

手順 4: ポリシーがダウンロードされ、クライアントで評価される

クライアントで次のPolicyAgent.logにログインします。

ポリシー 'CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}",PolicySource="SMS:PS1",PolicyVersion="40.00"' のダウンロードが正常に開始されましたPolicyAgent_ReplyAssignments
ポリシー 'CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}",PolicyVersion="40.00",PolicySource="SMS:PS1"' が正常にコンパイルされましたPolicyAgent_PolicyDownload

クライアントのPolicyEvaluator.logで次の手順を実行します。

ポリシーの更新 CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}",PolicySource="SMS:PS1",PolicyVersion="40.00" PolicyAgent_PolicyEvaluator
Applied policy CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}",PolicySource="SMS:PS1",PolicyVersion="40.00" PolicyAgent_PolicyEvaluator
[CCM_Policy_Policy5.PolicyID="{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}",PolicyVersion="40.00",PolicySource="SMS:PS1"] のポリシー状態は現在 [アクティブ] PolicyAgent_PolicyEvaluator

クライアントで UpdateSource ポリシーの PolicyID を見つけるには、次の WQL クエリを実行します。

• Namespace: ROOT\ccm\Policy\Machine\RequestedConfig
• クエリ: SELECT * FROM CCM_Policy_Policy5 WHERE PolicyCategory = 'UpdateSource'

このポリシーがクライアントでコンパイルされると、UpdateSource 情報は次の WMI クラスに格納されます。

名前空間: ROOT\ccm\Policy\Machine\ActualConfig
クラス: CCM_UpdateSource

ヒント

クライアント上の CCM_UpdateSource クラスのインスタンスをポリシー テーブルから取得した XML 本文と比較すると、XML の内容がインスタンスと同じように見えることがわかります。

手順 5: UpdateSource ポリシーが更新されたことをエージェントに通知する

クライアントで次のScanAgent.logログインします。

Inside CScanAgent::Notify() ScanAgent
CScanAgent::OnPolicyChange- Policy InstanceModificationEvent 通知が ScanAgent を受信しました

WSUS サーバーの場所

UpdateSource ポリシーを受け取った後、クライアントはスキャンを開始するために必要な構成を持っています。 ただし、ポリシーの更新では、即時スキャンは開始されません。 スキャンは、Configuration Manager コントロール パネルを使用して手動でトリガーすることも、次回スケジュールされた時刻に自動的に実行することもできます。 この時点で、クライアントはポリシーで指定されたコンテンツ バージョンを持つ WSUS コンピューターを見つけます。 このプロセスは、クライアントが特定のパッケージとバージョンの配布ポイントの場所を見つける方法とよく似ています。

手順 1: スキャン エージェントが使用可能なポリシーに基づいてスキャン要求を作成する

次のコードがScanAgent.logに記録されます。

CScanAgent::ScanByUpdates- Policy available for UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC} ContentVersion=38 ScanAgent
CScanAgent::ScanByUpdates- 最終 ScanRequest List UpdateSourceID={C2D17964-BBDD-4339-B9F3-12D7205B39CC}、Policy-ContentVersion=38、Required-ContentVersion=38 ScanAgent にポリシーを追加しました

手順 2: スキャン エージェントが WSUS の場所の要求を Location Services に送信する

スキャン エージェントが Location Services に WSUS の場所を要求し、応答を待機するようになりました。 この例では、場所要求 ID は {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} です。 次のコードがScanAgent.logに記録されます。

Inside CScanAgent::P rocessScanRequest() ScanAgent
CScanJobManager::Scan- entered ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Initialize- entered ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Scan- entered ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::RequestLocations- entered ScanAgent
- - - - -{C2D17964-BBDD-4339-B9F3-12D7205B39CC} バージョン 38 ScanAgent の LS からの WSUS サーバーの場所の要求
- - - - -Location Request ID = {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
CScanAgentCache::P ersistInstanceInCache- ScanAgent CCM_ScanJobInstance永続化されたインスタンス
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): - - - - -ScanJobID={4CD06388-D509-46 に要求された場所E4-8C00-75909EDD9EE8} (LocationRequestID={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}) は、場所が使用可能になるとスキャン要求を処理します。 ScanAgent

各スキャン ジョブは、 クラスの WMI に格納されます。

名前空間: root\CCM\ScanAgent
クラス: CCM_ScanJobInstance

手順 3: Location Services が場所要求を管理ポイントに送信する

Location Services によって場所要求が作成され、管理ポイントに送信されます。 WSUS の場所要求のパッケージ ID は、UpdateSource の一意の ID です。 次のコードがLocationServices.logに記録されます。

CCCMWSUSLocation::GetLocationsAsyncEx LocationServices
ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' および ContentVersion='38' LocationServices に対する WSUS の場所要求を保持しようとしています
永続化された WSUS の場所要求 LocationServices
ContentID='{C2D17964-BBDD-4339-B9F3-12D7205B39CC}' LocationServices の WSUS 場所要求を送信しようとしています
WSUSLocationRequest : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{C2D17964-BBDD-4339-B9F3- 12D720 5B39CC}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.1 68.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> LocationServices
パッケージ {C2D17964-BBDD-4339-B9F3- 12D7205B39CC} LocationServices の場所要求 '{C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}' を作成して送信しました

手順 4: CCM メッセージングが場所要求メッセージを管理ポイントに送信する

次のコードがCcmMessaging.logに記録されます。

非同期メッセージ '{76453CC6-76BA-4B68-BE30-BA70754570BB}' を送信キュー 'mp:[http]mp_locationmanager' CcmMessaging に送信する
送信メッセージ '{76453CC6-76BA-4B68-BE30-BA70754570BB}' を送信しています。 フラグ 0x200、送信者アカウントが空の CcmMessaging

手順 5: 管理ポイントが要求を解析し、データベースから WSUS の場所を取得し、応答を送信する

管理ポイントはこの要求を解析し、 MP_GetWSUSServerLocations ストアド プロシージャを呼び出して、データベースから WSUS の場所を取得します。 次のコードがMP_Location.logに記録されます。

MP LM: メッセージ本文: <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{C2D17964-BBDD-4339-B9F3- 12D7205B39CC}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.1 68.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest> MP_LocationManager
MP LM: MP_GetWSUSServerLocations MP_LocationManagerの呼び出し

SQL Server プロファイラー トレースで次の手順を実行します。

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'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}',N'38',N'PS1',N'PS1',N'0',N'CONTOSO.COM'

ストアド プロシージャから結果を取得した後、管理ポイントはクライアントに応答を送信します。 次のコードがMP_Location.logに記録されます。

MP LM: 応答メッセージ本文:
<WSUSLocationReply SchemaVersion="1.00"><Sites><Site><MPSite SiteCode="PS1"/><LocationRecords><LocationRecord WSUSURL="http://PS1SITE.CONTOSO.COM:8530" ServerName="PS1SITE.CONTOSO.COM" バージョン ="38"/><LocationRecord WSUSURL="https://PS1SYS.CONTOSO.COM:8531" ServerName="PS1SYS.CONTOSO.COM" Version="38"/></LocationRecords></Site></Sites></WSUSLocationReply> MP_LocationManager

手順 6: CCM メッセージングが応答を受信し、Location Services に返送する

クライアント上のCcmMessaging.log ファイルは、応答が受信されたことを示しています。 このメッセージは、Location Services に配信されました。

メッセージ '{76453CC6-76BA-4B68-BE30-BA70754570BB}' に応答 '{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}' がローカル エンドポイント キュー 'LS_ReplyLocations' CcmMessaging に送信されました
OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={76453CC6-76BA-4B68-BE30-BA70754570BB}): 'PS1SYS.CONTOSO.COM' をホストするために正常に配信されました。 CcmMessaging
エンドポイント 'LS_ReplyLocations' CcmMessaging に配信されたメッセージ '{8E6D05EF-B77F-4AD0-AF64-1C6F3069A29C}'

手順 7: Location Services が応答を解析し、場所をスキャン エージェントに返す

次のコードがLocationServices.logに記録されます。

処理場所応答メッセージ LocationServices 1/20/2014 12:18:09 PM
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> LocationServices
次の WSUS の場所 LocationServices を使用した呼び戻し
WSUS Path='http://PS1SITE.CONTOSO.COM:8530',Server='PS1SITE.CONTOSO。COM',Version='38' LocationServices
WSUS Path='https://PS1SYS.CONTOSO.COM:8531',Server='PS1SYS.CONTOSO。COM',Version='38' LocationServices
WSUS 要求 {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} LocationServices の場所を使用した呼び戻し

手順 8: スキャン エージェントが WUAHandler に通知して、更新ソースをレジストリに追加する

スキャン エージェントに、ポリシーと更新元の場所が適切なコンテンツ バージョンで追加されました。 次のコードがScanAgent.logに記録されます。

WSUSLocationUpdate received for location request guid={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::OnLocationUpdate- Received Location=http://PS1SITE.CONTOSO.COM:8530, Version=38 ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute- Adding UpdateSource={C2D17964-BBDD-4339-B9F3-12D7205B39CC}, ContentType=2、ContentLocation=http://PS1SITE.CONTOSO.COM:8530、ContentVersion=38 ScanAgent

スキャン エージェントは、更新ソースを追加するように WUAHandler に通知します。 WUAHandler は、更新ソースをレジストリに追加し、グループ ポリシーの更新を開始して (クライアントがドメイン内にある場合)、グループ ポリシーが追加した更新サーバーをオーバーライドするかどうかを確認します。 新しい更新ソースが追加されたことを示す新しいクライアントにWUAHandler.log、次の情報が記録されます。

WSUS の更新ソースの種類 ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) を追加します。 WUAHandler
その完全に新しい WSUS 更新プログラム ソース。 WUAHandler
WUA マネージド サーバー ポリシーでサーバーを使用できるようにする: WUAHandler http://PS1SITE.CONTOSO.COM:8530
ポリシーの更新が強制されました。 WUAHandler
グループ ポリシーが WUA ポリシーの変更を通知するまで 2 分間待機しています...WUAHandler
WU エージェントでポリシーが有効になるまで 30 秒待ちます。 WUAHandler
コンテンツ タイプの更新ソース ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) を追加しました: 2 WUAHandler

この間、Windows Update エージェントに WSUS 構成の変更が表示されます。 次のコードがWindowsUpdate.logに記録されます。

2014-01-20 12:18:11:520 968 9d0 エージェント * WSUS サーバー: http://PS1SITE.CONTOSO.COM:8530 (変更)
2014-01-20 12:18:11:520 968 9d0 エージェント * WSUS 状態サーバー: http://PS1SITE.CONTOSO.COM:8530 (変更)
2014-01-20 12:18:11:520 968 9d0 AU Sus サーバーがポリシーによって変更されました。

次のレジストリ キーがチェックされ、設定されます。

レジストリ サブキー	値の名前	種類	データ​​
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に次の内容が表示される可能性があります。

WSUS の更新ソースの種類 ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) を追加します。 WUAHandler
WSUS の更新プログラム ソースは既に存在し、バージョンが 38 に増えました。 WUAHandler

手順 9: スキャン エージェントがスキャンを開始する

更新ソースが正常に追加されると、スキャン エージェントによって状態メッセージが生成され、スキャンが開始されます。 次のコードがScanAgent.logに記録されます。

ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): UpdateSource ({C2D17964-BBDD-4339-B9F3-12D7205B39CC}) 状態メッセージが正常に発生しました。 StateId = 2 ScanAgent
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute - 正常に要求されたスキャン、ScanType=1 ScanAgent

クライアントでのソフトウェア更新プログラムのスキャン

更新元ポリシーと更新元の場所を使用できるようになったら、スキャン エージェントによってスキャンが開始されます。 ソフトウェア更新プログラムのスキャンは、Windows Update エージェントによって実際に実行されます。 ただし、Configuration Manager クライアントは Windows Update エージェントと対話してスキャンを実行し、スキャン結果を取得します。 この相互作用は、Windows Update エージェント ハンドラー (WUAHandler) コンポーネントによって処理され、Windows Update エージェントと通信します。

手順 1: スキャン エージェントがスキャンを要求し、WUAHandler がスキャンを開始する

スキャン エージェントは WUAHandler からスキャンを要求します。WUAHandler は、Windows Update エージェント API を使用して、Windows Update エージェントにソフトウェア更新プログラムのスキャンを要求します。 次のコードがScanAgent.logに記録されます。

ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute - 正常に要求されたスキャン、ScanType=1 ScanAgent

次のコードがWUAHandler.logに記録されます。

スキャン結果には、置き換えられた更新プログラムがサービス パックと定義の更新プログラムに置き換えられる場合にのみ含まれます。 WUAHandler
Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') WUAHandler
更新プログラムの単一呼び出しスキャンの実行。 WUAHandler
WUAgent を使用した更新プログラムの非同期検索が開始されました。 WUAHandler

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

Windows Update エージェントは、Configuration Manager クライアント (CcmExec) から要求を受信した後にスキャンを開始します。 Windows Update Server の値は SUP サーバーに既に設定されているため、このスキャンは、SUP の役割がインストールされている WSUS サーバーに対して実行されます。 次のコードがWindowsUpdate.logに記録されます。

2014-01-20 12:18:42:694 3856 708 COMAPI -- START -- COMAPI: Search [ClientId = CcmExec]
2014-01-20 12:18:42:752 3856 708 COMAPI <<- SUBMITTED -- COMAPI: Search [ClientId = CcmExec]
2014-01-20 12:18:47:511 968 f58 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, サーバー URL = http://PS1SITE.CONTOSO.COM:8530/ClientWebService/client.asmx
2014-01-20 12:18:48:662 968 f58 Agent ** START ** エージェント: 更新プログラムの検索 [CallerId = CcmExec]
2014-01-20 12:18:48:662 968 f58 Agent * 置き換えられる可能性のある更新プログラムを含める
2014-01-20 12:18:48:662 968 f58 エージェント * オンライン = はい;[ダウンロードの優先度を無視する] = [はい]
2014-01-20 12:18:48:662 968 f58 Agent * Criteria = "(DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')"
2014-01-20 12:18:48:662 968 f58 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} マネージド
2014-01-20 12:18:48:662 968 f58 Agent * Search Scope = {Machine}

Windows Update エージェントは WSUS サーバーをスキャンし、結果を CcmExec (具体的には WUAHandler) に報告するようになりました。 次のコードがWindowsUpdate.logに記録されます。

2014-01-20 12:18:49:175 968 f58 PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, サーバー URL = http://PS1SITE.CONTOSO.COM:8530/ClientWebService/client.asmx
2014-01-20 12:18:52:680 968 f58 Agent * 更新プログラム {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 を追加して結果を検索
2014-01-20 12:18:52:683 968 f58 Agent * 更新プログラム {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 を検索結果に追加しました
2014-01-20 12:18:52:694 968 f58 Agent * 検索で163の更新プログラムと70カテゴリが見つかりました。評価されたアプリ。1150 個のデプロイ済みエンティティのうち 622 個のルール
2014-01-20 12:18:52:745 968 f58 Agent ** END ** Agent: 更新プログラムの検索 [CallerId = CcmExec]
2014-01-20 12:18:52:755 3856 708 COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec]
2014-01-20 12:18:53:137 3856 708 COMAPI - 更新プログラムが見つかりました = 163
2014-01-20 12:18:53:137 3856 708 COMAPI -- END -- COMAPI: Search [ClientId = CcmExec]

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

次のコードがWUAHandler.logに記録されます。

非同期検索が完了しました。 WUAHandler
1 回の呼び出しですべてを検索し終えました。 WUAHandler

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

その後、WUAHandler は結果を解析します。これには、各更新プログラムの適用状態が含まれます。 このプロセスの一環として、置き換えられた更新プログラムは排除されます。次のコードがWUAHandler.logに記録されます。

排除: 更新 ID (70f4f236-0248-4e84-b472-292913576fa1) が置き換えられます (726b7201-862a-4fde-9b12-f36b38323a6f)。 WUAHandler
...
更新プログラム (インストール済み): x64 ベース システム用 Windows 7 用セキュリティ更新プログラム (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104) WUAHandler
更新プログラム (不足): x64 ベース システム用 Windows 7 用セキュリティ更新プログラム (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773,200) WUAHandler
...
スキャンが正常に完了しました。 WUAHandler

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

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

不足している更新 (KB2862152) が記録され、状態メッセージが発生した状態を示すUpdatesStore.log:

ProductID = 0fa1201d-4330-4fa8-8ae9- b877473b6441 UpdatesStore を使用した更新プログラム (505fda07-b4f3-45fb-83d9-864254e2773) からの更新の状態の処理
更新プログラム (505fda07-b4f3-45fb-83d9-8642554e2773) からの更新の状態は、新しいインスタンスを作成する前に報告されていません。 UpdatesStore
状態 (不足) の更新プログラム (505fda07-b4f3-45fb-83d9-8642554e2773) の状態メッセージが正常に発生しました。 UpdatesStore
更新状態の WMI インスタンスが正常に追加されました (505fda07-b4f3-45fb-83d9-8642554e2773)。 UpdatesStore

State ID 2 (不足) で記録されている状態メッセージを示すStateMessage.log:

TopicType 500 および TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 のメッセージを WMI StateMessage に追加する
SYSTEM StateMessage に対して TopicType 500 および TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 の状態メッセージ (状態 ID: 2) が記録されました

更新ごとに、 CCM_UpdateStatus クラスのインスタンスが作成または更新され、更新プログラムの現在の状態が格納されます。 CCM_UpdateStatus クラスは、ROOT\CCM\SoftwareUpdates\UpdatesStore 名前空間にあります。

同様に、 CCM_StateMsg クラスのインスタンスが作成または更新され、更新プログラムの現在の状態が格納されます。 CCM_StateMsg クラスは、ROOT\CCM\StateMsg 名前空間にあります。

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

前述のように、状態メッセージは、既定で 15 分に構成されている状態メッセージ報告サイクル スケジュールに基づいて管理ポイントに送信されます。 状態メッセージが管理ポイントに送信されると、CCM_StateMsg クラスの状態メッセージ インスタンスのMessageSent プロパティが True に設定されます。

In StateMessage.log:

StateMessage 本文: <XML レポート本文の切り捨て> StateMessage
状態メッセージを MP StateMessage に正常に転送しました

更新プログラムの状態メッセージ本文の外観を次に示します。 通常、この XML 本文はログに対して大きすぎて、CMTrace では切り捨てられます。 ただし、XML 本文全体はメモ帳で確認できます。

StateMessage 本文: <?xml version="1.0" encoding="UTF-16"?>
<Report><ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType>1</ClientType ><ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName>PS1WIN7X64</NetBIOSName><CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority><5//Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType>Full</ReportType><Date>20140120194656.903000+000</DateVersion>< >1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="20140120171855.573000+000" SerialNumber="232"><トピック ID="505fda07-b4f3-45fb-83d9-8642554e2773" Type="500" IDType="3" User="" UserSID=""/><State ID="2" Criticality="0"/><UserParameters Flags="0" Count="1"><Param>200</Param></UserParameters></StateMessage></ReportBody></Report> StateMessage
状態メッセージを MP StateMessage に正常に転送しました

状態メッセージ処理フロー

状態メッセージの記録方法と、これらの状態メッセージが格納される WMI の場所を把握しました。 また、クライアント上の未送信状態メッセージは、状態メッセージ報告サイクルに従って、既定で 15 分ごとに管理ポイントに送信されます。 このスケジュールは、カスタムまたは既定のクライアント設定の State Messaging で変更できます。

StateMessage.logは、 正常に転送された状態メッセージを MP に報告しますが、状態メッセージ コンポーネントは実際にはこれらのメッセージ自体を送信していません。 管理ポイントから送受信されるすべてのメッセージは、クライアント上の CCM メッセージング コンポーネントによって処理されます。 CCM メッセージングは、データの送受信のために管理ポイントと通信する実際のコンポーネントです。 管理ポイントには、さまざまな種類の受信トラフィックを処理するために、さまざまなキューが定義されています。 状態メッセージの場合、このトラフィックを処理するキューは MP_RelayEndpoint キューです。

手順 1: 状態メッセージ コンポーネントが管理ポイントへのメッセージの送信を開始する

In StateMessage.log:

StateMessage 本文: <?xml version="1.0" encoding="UTF-16"?><Report><ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType>1</ClientType><ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID ><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName>PS1WIN7X64</NetBIOSName><CodePage >437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority>5</Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType>Full</ReportType><Date>20140120194656.903000+000</Date><Version>1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="20140120171855.573000+000" SerialNumber="232"><トピック ID="505fda07-b4f3-45fb-83d9-8642554e2773" Type="500" IDType="3" User="" UserSID=""/><State ID="2" Criticality ="0"/><UserParameters Flags="0" Count="1"><Param>200</Param></UserParameters></StateMessage></ReportBody></Report> StateMessage
状態メッセージを MP StateMessage に正常に転送しました

手順 2: CCM メッセージングが、状態メッセージ XML 本文を含むメッセージを管理ポイントに送信する

CCM メッセージングは、 MP_RelayEndpoint キューにメッセージを正常に送信します。 このメッセージには応答がありません。前に「 WSUS Location Request 」セクションで確認した応答とは異なり、Location Request を含むメッセージが応答を受信しました。

In CcmMessaging.log:

送信キュー 'mp:mp_relayendpoint' CcmMessaging への非同期メッセージ '{95F79010-D0EB-49A6-8A1E-3897883105F2}' の送信
送信メッセージ '{95F79010-D0EB-49A6-8A1E-3897883105F2}' を送信しています。 フラグ 0x200、送信者アカウントが空の CcmMessaging
POST: Host=PS1SYS。CONTOSO.COM、Path=/ccm_system/request、Port=443、Protocol=https、Flags=512、Options=480 CcmMessaging
メッセージ '{95F79010-D0EB-49A6-8A1E-3897883105F2}' に応答 CcmMessaging がありません
OutgoingMessage(Queue='mp_mp_relayendpoint', ID={95F79010-D0EB-49A6-8A1E-3897883105F2}): 'PS1SYS.CONTOSO.COM' をホストするために正常に配信されました。 CcmMessaging

手順 3: 管理ポイントでメッセージを受信し、メッセージを処理して SMX ファイルを作成MP_Relay

すべてのメッセージは HTTP/HTTPS を使用して送信され、IIS によって受信されます。 この例では、この要求はCCM_System仮想ディレクトリに対して行われます。

IIS ログで次の手順を実行します。

192.168.2.12 CCM_POST /ccm_system/request - 443 - 192.168.2.62 ccmhttp - 200 0 0 542 31

管理ポイントでメッセージが正常に受信されると、 MP_Relay コンポーネントはこのメッセージを処理し、メッセージを SMX ファイルに変換し、管理ポイントがサイト サーバーに併置されているかどうかに応じて、SMX ファイルを適切な場所に移動します。

• リモート管理ポイント: \SMS\mp\outboxes\StateMsg.box
• サイト サーバーに併置された管理ポイント: \inboxes\auth\StateSys.box\incoming

サイト サーバーに併置されている管理ポイントのMP_Relay.log:

Mp メッセージ ハンドラー: Relay のメッセージ処理を開始します----------------------- MP_RelayEndpoint
Mp メッセージ ハンドラー: FileType=SMX MP_RelayEndpoint
メッセージ本文: <XML 本文が切り捨てられました> MP_RelayEndpoint
Relay: Outbox dir: E:\ConfigMgr\inboxes\auth\statesys.box\incoming MP_RelayEndpoint
メッセージの優先度 = 5 MP_RelayEndpoint
State Priority Directory = E:\ConfigMgr\inboxes\auth\statesys.box\incoming MP_RelayEndpoint
Inv-Relay: タスクが正常に完了MP_RelayEndpoint

リモート管理ポイントのMP_Relay.log:

Mp メッセージ ハンドラー: Relay のメッセージ処理を開始します------------------------------ MP_RelayEndpoint
Mp メッセージ ハンドラー: FileType=SMX MP_RelayEndpoint
メッセージ本文:
<?xml version="1.0" encoding="UTF-16"?>
<Report><ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType>1</ClientType ><ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName>PS1WIN7X64</NetBIOSName><CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority><5//Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType>Full</ReportType><Date>20140120194656.903000+000</DateVersion>< >1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="20140120171855.573000+000" SerialNumber="232"><トピック ID="505fda07-b4f3-45fb-83d9-8642554e2773" Type="500" IDType="3" User="" UserSID=""/><State ID="2 " Criticality="0"/><UserParameters Flags="0" Count="1"><Param>200</Param></UserParameters></StateMessage></ReportBody></Report> MP_RelayEndpoint
Inv-Relay タスク: メッセージ本文の処理MP_RelayEndpoint
Relay: Outbox dir: C:\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
メッセージの優先度 = 5 MP_RelayEndpoint
State Priority Directory = C:\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Inv-Relay: タスクが正常に完了MP_RelayEndpoint

XML 本文は、クライアントでStateMessage.logにログインしているものと同じように見えます。

手順 4: MP ファイル ディスパッチ マネージャーが SMX ファイルをサイト サーバーに送信する (管理ポイントがサイト サーバーに併置されていない場合のみ)

管理ポイントがサイト サーバーにリモートにある場合、ファイルが outboxes\StateMsg.box に到着した後、MP File Dispatch Manager (MPFDM) は、これらのファイルをサイト サーバー上の StateMsg.box 受信トレイに移動する役割を担います。 管理ポイントがサイト サーバーに併置されると、これらのファイルは適切な受信トレイ フォルダーに直接移動されるため、MPFDM は関与しません。

リモート管理ポイントのMPFDM.log:

C:\SMS\MP\OUTBOXES\statemsg.box\TAZGYTSJ ファイルを移動しました。SMX to \\PS1SITE.CONTOSO.COM\SMS_PS1\inboxes\auth\statesys.box\incoming\TAZGYTSJ.SMX SMS_MP_FILE_DISPATCH_MANAGER

MPFDM がファイルを適切な受信トレイに移動するには、リモート管理ポイントがサイト サーバーのレジストリにアクセスして受信トレイのソースの場所を特定できる必要があります。 そのため、リモート レジストリ サービスが実行されていて、レジストリ アクセスがグループ ポリシーによってブロックされないようにする必要があります。 MPFDM は、サイト サーバー上の次のレジストリ キーにアクセスして受信トレイの場所を決定します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Inbox Source

手順 5: サイト サーバー上の StateSys コンポーネントがデータベースへの状態メッセージを処理する

ファイルがサイト サーバーの \inboxes\auth\StateSys.box に到着すると、State System Manager (StateSys) コンポーネントが起動し、SMX ファイルが処理されます。

詳細ログが有効になっているStateSys.log:

受信トレイの通知がトリガーされ、10 秒間一時停止します......SMS_STATE_SYSTEM
処理する新しい状態メッセージが見つかりました。スレッド SMS_STATE_SYSTEMの処理を開始しています
Thread "State Message Processing Thread #0" id:4316 started SMS_STATE_SYSTEM
合計チャック(1)SMS_STATE_SYSTEM
CMessageProcessor - 処理ファイル: YCE2H3VD。SMX SMS_STATE_SYSTEM
CMessageProcessor - 0 個の無効なレコードを含む 1 つのレコードを処理しました。 SMS_STATE_SYSTEM
CMessageProcessor - このバッチ内の 1 つのメッセージ ファイルを処理し、0 個の不適切なファイルを処理しました。 SMS_STATE_SYSTEM
合計チャック(0)SMS_STATE_SYSTEM
Thread "State Message Processing Thread #0" id:4316 terminated normally SMS_STATE_SYSTEM

詳細ログ記録が有効になっていないStateSys.log:

処理する新しい状態メッセージが見つかりました。スレッド SMS_STATE_SYSTEMの処理を開始しています
Thread "State Message Processing Thread #0" id:1988 started SMS_STATE_SYSTEM
合計チャック(1)SMS_STATE_SYSTEM
合計チャック(0)SMS_STATE_SYSTEM
Thread "State Message Processing Thread #0" id:1988 terminated normally SMS_STATE_SYSTEM

StateSys.log ファイルは、state System Manager で verbose logging が有効になっていない限り、ファイル名をログに記録しません。

StateSys.box フォルダーに移動された SMX ファイルには、メッセージ本文 XML が含まれています。 StateSys はこのファイルを処理するときに、 spProcessStateReport ストアド プロシージャを呼び出し、この XML 本文をパラメーターとしてストアド プロシージャに渡します。

SQL Server プロファイラー トレースで次の手順を実行します。

exec dbo.spProcessStateReport N'<?xml version="1.0" encoding="UTF-16"?>
<Report><ReportHeader><Identification><Machine><ClientInstalled>1</ClientInstalled><ClientType>1</ClientType ><ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>5.00.7958.1000</ClientVersion><NetBIOSName>PS1WIN7X64</NetBIOSName><CodePage>437</CodePage><SystemDefaultLCID>1033</SystemDefaultLCID><Priority><5//Priority></Machine></Identification><ReportDetails><ReportContent>State Message Data</ReportContent><ReportType> </ReportType><Date>20140120220131.071000+000</Date><Version >1.0</Version><Format>1.0</Format></ReportDetails></ReportHeader><ReportBody><StateMessage MessageTime="20140120171855.573000+000" SerialNumber="239"><トピック ID="505fda07-b4f3-45fb-83d9-8642554e2773" Type="500" IDType="3" User="" UserSID=""/><State ID="2 " Criticality="0"/><UserParameters Flags="0" Count="1"><Param>200</Param></UserParameters></StateMessage></ReportBody></Report>'

spProcessStateReport は CLR ストアド プロシージャであり、CLR 定義には、処理される状態メッセージの種類を決定するロジックがあります。 状態メッセージの種類に応じて、状態メッセージを適切に処理し、データベースにデータを挿入します。

次のコマンドを使用してSR_StateNames テーブルに対してクエリを実行するとすべての状態メッセージのフレンドリ名トピックの種類と ID を確認できます。

SELECT * FROM SR_StateNames

ソフトウェア更新プログラムの概要

ソフトウェア更新プログラムのコンプライアンス データをコンソールまたはレポートに表示する前に、ソフトウェア更新プログラムのコンプライアンス データを要約する必要があります。 これは、コンソールとレポートには通常、集計データのみが表示されるために必要です。 サイト サーバー上の状態システム コンポーネントは、ソフトウェア更新プログラムの概要と、アプリケーション、DCM 展開、クライアントの正常性などの他のコンポーネントの概要を実行します。 State System が実行するすべての概要タスクに関する情報は、Configuration Manager データベースの vSR_SummaryTasks ビューに対してクエリを実行することで確認できます。 State System は、構成されたスケジュールでこれらのタスクを実行し、StateSys.logの各タスクに関する詳細をログに記録します。

開始タスク '<TaskName>' SMS_STATE_SYSTEM
タスク '<TaskName>' は、状態 8 で 15 秒間実行した後に正常に完了しました。 SMS_STATE_SYSTEM

これらのタスクのほとんどは、StateSys.logによってログに記録される状態はエラー コードではありません。 代わりに、集計を実行する適切な SQL Server ストアド プロシージャによって返される行の数です。

ソフトウェア更新プログラムに固有の概要タスクは次のとおりです。

• SUM 割り当てコンプライアンス エバリュエーター

  すべてのソフトウェア更新プログラム グループの割り当て (展開) の状態メッセージを要約します。 このタスクは、既定で 1 時間ごとに実行されます。 Configuration Manager コンソール >Monitoring>Deployments で特定の展開に対して手動で開始し、展開を右クリックして、[概要の実行 ] をクリック。

• SUM 更新グループの状態サマライザー

  更新グループの状態を要約します。 このタスクは、既定で 1 時間ごとに実行されます。 これは、Configuration Manager コンソールの特定の更新グループに対して手動で開始できます >ソフトウェア ライブラリ>Software Updates>Software Update Groups、更新グループを右クリックし、 実行概要をクリックします。

  このタスクのスケジュールを変更するには、 Software 更新グループを右クリックするか リボンで 集計のスケジュール を選択します。

• SUM 更新ステータス サマライザー

  すべてのクライアントの更新の状態を要約します。 このタスクは、既定で 1 時間ごとに実行されます。 Configuration Manager コンソール >Software Library>Software Updates で手動で開始し、[概要の実行 ] をクリック。 既定のスケジュールを変更するには、[集計のスケジュールを選択します。

• SUM Migrate Update Status

  データベース内で更新状態を内部的に移行します。 このタスクは、既定で 24 時間ごとに実行されます。 Configuration Manager コンソールから手動で開始することはできません。

• SUM 期限切れ状態の削除

  データベース内のソフトウェア更新プログラム固有のテーブルから期限切れの状態を削除します。 このタスクは、既定で 24 時間ごとに実行されます。 Configuration Manager コンソールから手動で開始することはできません。

ソフトウェアの更新ポイントの切り替え

System Center 2012 Configuration Manager SP1 以降のバージョンでは、サイトに複数の SUP を含めることができます。 これにより、SUP が使用できなくなった場合のフォールト トレランスが提供されます。 SUP のフェールオーバーと切り替えの詳細については、次の記事を参照してください。

• Configuration Manager Service Pack 1 のソフトウェア更新ポイント
• ソフトウェアの更新ポイントの切り替え