ソフトウェア更新プログラムのコンプライアンス評価を追跡する
適用対象: Configuration Manager
クライアントにソフトウェア更新プログラムを展開する前に、クライアントでソフトウェア更新プログラムのコンプライアンス スキャンを実行する必要があります。 クライアントがスキャンを完了し、コンプライアンスの結果を報告するのに十分な時間を許可することをお勧めします。これにより、コンプライアンスの結果を確認し、クライアントに必要な更新プログラムのみを展開できます。
ソフトウェアの更新ポイント (SUP) をインストールして同期すると、サイト全体のコンピューター ポリシーが作成され、そのサイトに対してソフトウェア Updates Configuration Managerが有効になっていることをクライアント コンピューターに通知します。 クライアントがマシン ポリシーを受け取ると、コンプライアンス評価スキャンは次の 2 時間以内にランダムに開始されるようにスケジュールされます。 スキャンが開始されると、ソフトウェア Updates クライアント エージェント プロセスによってスキャン履歴がクリアされ、スキャンに使用するWindows Server Update Services (WSUS) サーバーを検索する要求が送信され、WSUS の場所でローカル グループ ポリシーが更新されます。
コンプライアンス評価プロセスの概要については、「 ソフトウェア更新プログラムのコンプライアンス評価」を参照してください。
ソフトウェア更新プログラムのスキャン ポリシー
クライアントが更新プログラムをスキャンする前に、UpdateSource ポリシーが必要です。 このポリシーは、SUP の同期が正常に完了した後、サイト サーバー上に作成されます。 このセクションでは、次のプロセスによってこのポリシーがどのように作成されるかについて説明します。
手順 1: 同期が正常に完了すると、WSyncMgr はデータベースのコンテンツ バージョンと最終同期時刻を更新します
プライマリ サイトでの同期が正常に完了すると、WSyncMgr は SUP のデータベース内の 最終同期時刻 と コンテンツ バージョン を更新します。 これを行うには、ストアド プロシージャを spProcessSUMSyncStateMessage 実行します。 次のサンプル SQL Server Profiler トレースでは、このストアド プロシージャを実行してコンテンツ バージョンを 36 に更新します。
declare @Error int; exec spProcessSUMSyncStateMessage N'2014-01-17 17:59:54', N'PS1', N'{C2D17964-BBDD-4339-B9F3-12D7205B39CC}', 1, 0, '36', output, @Error N'PS1SITE.Contoso。COM'
手順 2: SMSDBMON がトリガーされ、 が削除されます。policypv.box の STN ファイル
spProcessSUMSyncStateMessage は、 Update_SyncStatus 新しいコンテンツ バージョンと同期時間でテーブルを更新します。 テーブルに対するこの更新により、Update_SyncStatusSMSDBMON がトリガーされ、UpdateSource_UniqueID>が<削除されます。スキャン ツール定義の変更を示す policypv.box の STN ファイル (STN はスキャン ツール通知を表します)。 次の情報がSMSDBMON.logに記録されます。
RCV: UpdSyncStatus_iuのUpdate_SyncStatusの更新 [{C2D17964-BBDD-4339-B9F3-12D7205B39CC}][46680] SMS_DATABASE_NOTIFICATION_MONITOR
SND: ドロップされた 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 Profiler トレース:
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'{d08556777) -b0a6-4e33-9bd5-7b0d06f06f0a2be}' ELSE insert Policy (PolicyID, Version) 値 (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 (POLICYAssignment から PADBID を選択します(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.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 ポリシーを取得します。
手順 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
適用されたポリシー 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
クライアントで PolicyID UpdateSource ポリシーの を見つけるには、次の 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には、次の情報が記録されます。
CScanAgent::Notify() ScanAgent 内
CScanAgent::OnPolicyChange- ポリシー インスタンスModificationEvent 通知が ScanAgent を受信しました
WSUS サーバーの場所
UpdateSource ポリシーを受け取った後、クライアントはスキャンを開始するために必要な構成を持っています。 ただし、ポリシーの更新では、即時スキャンは開始されません。 スキャンは、Configuration Managerコントロール パネルを介して手動でトリガーすることも、次回スケジュールされた時刻に自動的に実行することもできます。 この時点で、クライアントはポリシーで指定されたコンテンツ バージョンを持つ WSUS コンピューターを見つけます。 このプロセスは、クライアントが特定のパッケージとバージョンの配布ポイントの場所を見つける方法とよく似ています。
手順 1: スキャン エージェントは、使用可能なポリシーに基づいてスキャン要求を作成します
次の情報がScanAgent.logに記録されます。
CScanAgent::ScanByUpdates- 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に記録されます。
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 の WSUS サーバーの場所を LS から要求する
- - - - -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 に CCM_ScanJobInstance 格納されます。
名前空間: 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- 12D7205B39CC}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"ADSite Name=="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></WSUSLocationRequestquest> LocationServices
パッケージ {C2D17964-BBDD-4339-B9F3- 12D7205B39CC} LocationServices の作成および送信された場所要求 '{C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}'
手順 4: CCM メッセージングが場所要求メッセージを管理ポイントに送信する
次の情報がCcmMessaging.logに記録されます。
送信キュー 'mp:[http]mp_locationmanager' CcmMessaging への非同期メッセージ '{76453CC6-76BA-4B68-BE30-BA70754570BB}' の送信
送信メッセージ '{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"/><AssignedSiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM 12-R2- PS1"/><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: MP_GetWSUSServerLocations MP_LocationManagerを呼び出す
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'{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" Version="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' CcmMessaginging
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="ServerName="https://PS1SYS.CONTOSO.COM:8531PS1SYS.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に記録されます。
場所要求 guid={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent に対して受け取った WSUSLocationUpdate
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=, ContentVersion=http://PS1SITE.CONTOSO.COM:853038 ScanAgent
スキャン エージェントは、更新ソースを追加するように WUAHandler に通知します。 WUAHandler は、更新ソースをレジストリに追加し、(クライアントがドメイン内にある場合) グループ ポリシー更新を開始して、追加した更新サーバーグループ ポリシーオーバーライドするかどうかを確認します。 新しい更新ソースが追加されていることを示す新しいクライアントにWUAHandler.log、次の情報が記録されます。
WSUS の更新ソースの種類 ({C2D17964-BBDD-4339-B9F3-12D7205B39CC})、追加します。 WUAHandler
その完全に新しい WSUS Update Source。 WUAHandler
WUA マネージド サーバー ポリシーでサーバーを使用できるようにする:http://PS1SITE.CONTOSO.COM:8530WUAHandler
ポリシーの更新が強制されました。 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 Agent * WSUS サーバー:
http://PS1SITE.CONTOSO.COM:8530(変更)
2014-01-20 12:18:11:520 968 9d0 Agent * 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 エージェントと通信するWindows Update エージェント ハンドラー (WUAHandler) コンポーネントによって処理されます。
手順 1: スキャン エージェントがスキャンを要求し、WUAHandler がスキャンを開始する
スキャン エージェントは WUAHandler からスキャンを要求します。これは、Windows Update エージェント API を使用して、Windows Update エージェントからソフトウェア更新プログラムのスキャンを要求します。 次のものがScanAgent.logに記録されます。
ScanJob({4CD06388-D509-46E4-8C00-75909EDD9EE8}): CScanJob::Execute - 正常に要求されたスキャン、ScanType=1 ScanAgent
次の情報がWUAHandler.logに記録されます。
スキャン結果には、サービス パックと定義の更新プログラムによって置き換えられる場合にのみ、置き換えられた更新プログラムが含まれます。 WUAHandler
Search条件は (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver') WUAHandler
更新プログラムの単一呼び出しスキャンの実行。 WUAHandler
WUAgent を使用した更新プログラムの非同期検索が開始されました。 WUAHandler
手順 2: エージェント (WUA) Windows Update WSUS コンピューターに対してスキャンを開始する
Windows Update エージェントは、Configuration Manager クライアント (CcmExec) から要求を受信した後にスキャンを開始します。 Windows Update サーバーの値は既に 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 ** Agent: 更新プログラムの検索 [CallerId = CcmExec]
2014-01-20 12:18:48:662 968 f58 Agent * 置き換えられる可能性のある更新プログラムを含める
2014-01-20 12:18:48:662 968 f58 Agent * Online = Yes;[ダウンロードの優先順位を無視する] = [はい]
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 - 見つかったUpdates = 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
...
更新プログラム (インストール済み): Windows 7 for x64 ベースシステム用セキュリティ更新プログラム (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104) WUAHandler
Update (Missing): Windows 7 for x64 ベースシステム用セキュリティ更新プログラム (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200) WUAHandler
...
スキャンが正常に完了しました。 WUAHandler
手順 5: 更新ストアが状態を記録し、WMI の更新ごとに状態メッセージを生成する
スキャン結果が使用可能になると、これらの結果は更新ストアに格納されます。 更新ストアは、各更新プログラムの現在の状態を記録し、更新ごとに状態メッセージを作成します。 これらの状態メッセージは、ステータス メッセージ レポート サイクルの終了時 (既定では 15 分) に一括でサイト サーバーに転送されます。
更新プログラム (KB2862152) が記録されておらず、状態メッセージが発生している状態を示すUpdatesStore.log。
更新プログラムからの更新状態の処理 (505fda07-b4f3-45fb-83d9-8642554e2773) ProductID = 0fa1201d-4330-4fa8-8ae9- b877473b6441 UpdatesStore
更新からの更新状態 (505fda07-b4f3-45fb-83d9-8642554e2773) は、新しいインスタンスを作成する前に報告されていません。 UpdatesStore
更新の状態メッセージが正常に発生しました (505fda07-b4f3-45fb-83d9-8642554e2773) 状態 (不足)。 UpdatesStore
更新状態の WMI インスタンスが正常に追加されました (505fda07-b4f3-45fb-83d9-8642554e2773)。 UpdatesStore
状態 ID 2 (欠落) で記録されている状態メッセージを示すStateMessage.log:
TopicType 500 と TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 のメッセージを WMI StateMessage に追加する
TOPICType 500 および TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 の状態メッセージ (状態 ID: 2) が SYSTEM StateMessage に記録されました
更新ごとに、 クラスの CCM_UpdateStatus インスタンスが作成または更新され、更新プログラムの現在の状態が格納されます。 クラスは CCM_UpdateStatus 名前空間にあります ROOT\CCM\SoftwareUpdates\UpdatesStore 。
同様に、 クラスの CCM_StateMsg インスタンスが作成または更新され、更新プログラムの現在の状態が格納されます。 クラスは CCM_StateMsg 名前空間にあります ROOT\CCM\StateMsg 。
手順 6: 状態メッセージが管理ポイントに送信される
前述のように、状態メッセージは、既定で 15 分に構成されている状態メッセージ 報告サイクル スケジュールに基づいて管理ポイントに送信されます。 状態メッセージが管理ポイントに送信されると、 MessageSent クラスの CCM_StateMsg 状態メッセージ インスタンスのプロパティが True に設定されます。
In StateMessage.log:
StateMessage 本文: <XML レポート本文の切り捨て StateMessage>
状態メッセージを MP StateMessage に正常に転送しました
更新プログラムの状態メッセージ本文の外観を次に示します。 通常、この XML 本文はログに対して大きすぎて、CMTrace では切り捨てられます。 ただし、XML 本文全体はメモ帳で確認できます。
StateMessage 本文: <?xml version="1.0" encoding="UTF-16"?>
<ReportHeader Identification Machine ClientInstalled 1</ClientInstalled><>ClientType>1</ClientType><ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>1 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><バージョン>1.0</バージョン><形式>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: State Message コンポーネントが管理ポイントへのメッセージの送信を開始する
In StateMessage.log:
StateMessage 本文: <?xml version="1.0" encoding="UTF-16"?><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><バージョン>1.0</バージョン><形式>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 の場所要求」 セクションで確認したメッセージとは異なり、場所要求を含むメッセージが返信を受け取った場合とは異なります。
In CcmMessaging.log:
非同期メッセージ '{95F79010-D0EB-49A6-8A1E-3897883105F2}' を送信キュー 'mp:mp_relayendpoint' CcmMessaging に送信する
送信メッセージ '{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 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
リレー: 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"?>
<ReportHeader Identification Machine ClientInstalled 1</ClientInstalled><>ClientType>1</ClientType><ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>1 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><バージョン>1.0</バージョン><形式>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 ファイルをサイト サーバーに送信する (管理ポイントがサイト上のサーバーに併置されていない場合のみ)
管理ポイントがサイト サーバーにリモートにある場合、ファイルが送信トレイ\StateMsg.box に到着した後、MP File Dispatch Manager (MPFDM) は、これらのファイルをサイト サーバーの StateMsg.box 受信トレイに移動する役割を担います。 管理ポイントがサイト サーバー上に併置されると、これらのファイルは適切な受信トレイ フォルダーに直接移動されるため、MPFDM は関与しません。
リモート管理ポイントのMPFDM.log:
ファイル C:\SMS\MP\OUTBOXES\statemsg.box\TAZGYTSJ を移動しました。SMX から \\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
スレッド "State Message Processing Thread #0" id:4316 が正常に終了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
スレッド "State Message Processing Thread #0" id:1988 が正常に終了SMS_STATE_SYSTEM
State System Manager で詳細ログが有効になっていない限り、StateSys.log ファイルはファイル名を ログに記録 しません。
StateSys.box フォルダーに移動された SMX ファイルには、メッセージ本文 XML が含まれています。 StateSys は、このファイルを処理するときにストアド プロシージャを spProcessStateReport 呼び出し、この XML 本文をパラメーターとしてストアド プロシージャに渡します。
SQL Server Profiler トレース:
exec dbo.spProcessStateReport N'<?xml version="1.0" encoding="UTF-16"?>
<ReportHeader Identification Machine ClientInstalled 1</ClientInstalled><>ClientType>1</ClientType><ClientID>GUID: A1006D0E-CF56-41D1-A006-6330EFC39381</ClientID><ClientVersion>1 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>20140120220131.071000+000</Date><Version>1.0/0< バージョン><形式>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 定義には、処理される状態メッセージの種類を決定するロジックがあります。 状態メッセージの種類に応じて、状態メッセージを適切に処理し、データをデータベースに挿入します。
次のコマンドを使用してテーブルにクエリを実行すると、すべての状態メッセージ トピックの種類 と ID の SR_StateNames フレンドリ名を見つけることができます。
SELECT * FROM SR_StateNames
ソフトウェア更新プログラムの概要
ソフトウェア更新プログラムのコンプライアンス データをコンソールまたはレポートに表示する前に、ソフトウェア更新プログラムのコンプライアンス データを要約する必要があります。 これは、通常、コンソールとレポートに概要データのみが表示されるため、必要です。 サイト サーバー上の State System コンポーネントは、ソフトウェア更新プログラムの概要と、アプリケーション、DCM の展開、クライアントの正常性などの他のコンポーネントの概要を実行します。 ステート システムが実行するすべての要約タスクに関する情報は、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手動で開始し、展開を右クリックし、[概要の実行] をクリックします。
SUM Update Group Status Summarizer
更新グループの状態を要約します。 このタスクは、既定で 1 時間ごとに実行されます。 これは、ソフトウェア >ライブラリ>ソフトウェア> Updatesソフトウェア更新グループの特定の更新グループConfiguration Manager手動で開始し、更新グループを右クリックして、[概要の実行] をクリックします。
また、 ソフトウェア更新グループ を右クリックするか、リボンの [ 集計のスケジュール ] を選択して、このタスクのスケジュールを変更することもできます。
SUM 更新ステータス サマライザー
すべてのクライアントの更新の状態を要約します。 このタスクは、既定で 1 時間ごとに実行されます。 これは、ソフトウェア ライブラリ>ソフトウェア Updatesコンソール>Configuration Manager手動で開始し、[概要の実行] をクリックします。 [集計のスケジュール] を選択して、既定の スケジュールを変更することもできます。
SUM Migrate Update Status
データベース内で更新状態を内部的に移行します。 このタスクは、既定で 24 時間ごとに実行されます。 Configuration Manager コンソールから手動で開始することはできません。
SUM 削除期限切れの状態
データベース内のソフトウェア更新プログラムの特定のテーブルから期限切れの状態を削除します。 このタスクは、既定で 24 時間ごとに実行されます。 Configuration Manager コンソールから手動で開始することはできません。
ソフトウェアの更新ポイントの切り替え
System Center 2012 Configuration Manager SP1 以降のバージョンでは、サイトに複数の SUP を含めることができます。 これにより、SUP が使用できなくなった場合のフォールト トレランスが提供されます。 SUP のフェールオーバーと切り替えの詳細については、次の記事を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示