追蹤軟體更新合規性評定

發行項
11/20/2024

適用於： Configuration Manager

您必須先執行軟體更新合規性掃描，用戶端才能將軟體更新部署至用戶端。建議您讓用戶端有足夠的時間完成掃描和報告合規性結果，以便檢閱合規性結果，並只部署用戶端上所需的更新。

安裝並同步處理軟體更新點時，會建立全月台機器原則，通知用戶端電腦 Configuration Manager 軟體更新已啟用月臺。當用戶端收到電腦原則時，會排程在接下來兩小時內隨機開始相容性評估掃描。掃描啟動時，軟體更新用戶端代理程式程式會清除掃描歷程記錄、提交要求，以尋找應該用於掃描的 Windows Server Update Services （WSUS）伺服器，並使用 WSUS 位置更新本地組原則。

如需合規性評定程式的概觀，請參閱軟體更新合規性評定。

軟體更新掃描原則

客戶端必須先有UpdateSource原則，用戶端才能嘗試掃描更新。成功同步處理 SUP 之後，會在站台伺服器上建立此原則。本節討論下列程式如何建立此原則：

步驟 1：成功同步處理之後，WSyncMgr 會更新資料庫中的內容版本和上次同步時間

在主要站臺上成功同步處理之後，WSyncMgr 會在資料庫中更新 SUP 的上次同步時間和內容版本。這是藉由執行 spProcessSUMSyncStateMessage 預存程式來完成。在下列範例 SQL Server Profiler 追蹤中，會執行此預存程式，將內容版本更新為 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 檔案

spProcessSUMSyncStateMessageUpdate_SyncStatus使用新的內容版本和同步時間來更新數據表。數據表的 Update_SyncStatus 此更新會觸發SMSDBMON卸載 <UpdateSource_UniqueID>。policypv.box 中的 STN 檔案（STN 代表掃描工具通知），表示掃描工具定義的變更。下列記錄SMSDBMON.log：

RCV Update_SyncStatus：UpdSyncStatus_iu [{C2D17964-BBDD-4339-B9F3-12D7205B39CC}][46680] SMS_DATABASE_NOTIFICATION_MONITOR
SND： Dropd E：\ConfigMgr\inboxes\policypv.box{C2D17964-BBDD-4339-B9F3-12D7205B39CC}。STN （非零） [46680] SMS_DATABASE_NOTIFICATION_MONITOR

步驟 3：原則提供者會在資料庫中建立或更新 UpdateSource 原則

<UpdateSource_UniqueID>。STN 檔案會通知原則提供者應該喚醒並更新資料庫中的 UpdateSource 原則。

下列記錄PolicyPv.log：

找到 {C2D17964-BBDD-4339-B9F3-12D7205B39CC}。STN SMS_POLICY_PROVIDER
已新增掃描工具標識碼 {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}' 的原則選取 PolicyID）更新原則集版本 = N'40.00' 其中 PolicyID = N'{d0855677-b0a6-4e33-9bd5-7b0d06f0a2be}' ELSE insert Policy （PolicyID， Version）值（N'{d0855677- b0a6-4e33-9bd5-7b0d06f0a2be}'， N'40.00'）

exec sp_describe_undeclared_parameters N'UPDATE Policy SET Body = where PolicyID = @P1 N''{d0855677-b0a6-4e33-9bd5- 7b0d06f0a2be}''
IF EXISTS （從 POLICYAssignment 選取 PADBID = 16777218）更新 PolicyAssignment set Version = N'40.00'， InProcess = 1 ， BodyHash = null，其中 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 = where PADBID = @P1 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”] 目前為 [Active] PolicyAgent_PolicyEvaluator

若要在用戶端上尋找 PolicyID UpdateSource 原則的，請執行下列 WQL 查詢：

命名空間：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- 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 位置的要求傳送至位置服務

掃描代理程式現在會向位置服務要求 WSUS 位置，並等候回應。在此範例中，位置要求標識符為 {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}。下列記錄ScanAgent.log：

在 CScanAgent：:P rocessScanRequest（） ScanAgent 內
CScanJobManager：：Scan- 輸入 ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：Initialize- 輸入 ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：Scan- 輸入 ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：RequestLocations- 輸入 ScanAgent
- - - -針對 {C2D17964-BBDD-4339-B9F3-12D7205B39CC} 第 38 版 ScanAgent 向 LS 要求 WSUS 伺服器位置
- - -位置要求標識符 = {C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent
CScanAgentCache：:P ersistInstanceInCache- Persisted Instance CCM_ScanJobInstance ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： - 要求 ScanJobID={4CD06388-D509-D509-D46E4-8C00-75909EDD9EE8} （LocationRequestID={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862}），一旦有位置可用，就會處理掃描要求。 ScanAgent

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

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

步驟 3：位置服務會將位置要求傳送至管理點

位置服務會建立位置要求，並將它傳送至管理點。 WSUS 位置要求的套件識別碼是 UpdateSource 唯一識別符。下列記錄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=“CM 12-R2- PS1”/><樹系名稱=“CONTOSO.COM”/><域名=“CONTOSO.COM”/><IPAddresses><IPAddress SubnetAddress=“192.168.2.0” Address=“192.168.2.62”/></IPAddresses></ClientLocationInfo></WSUSLocationRequest>><LocationServices
針對套件 {C2D17964-BBDD-4339-B9F3- 12D7205B39CC} LocationServices，已建立並傳送位置要求 '{C2BB9710-C548-49D0-9DF8-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-R2- PS1”/><樹系名稱=“CONTOSO.COM”/域名=“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><><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 傳訊會接收回應，並將其傳回位置服務

用戶端上的CcmMessaging.log檔案會顯示已收到回復。此訊息已傳遞至位置服務：

訊息 '{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：位置服務會剖析回應，並將位置傳回掃描代理程式

下列記錄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：

針對位置要求 guid={C2BB9710-C548-49D0-9DF8-5F9CFC5F3862} ScanAgent 收到的 WSUSLocationUpdate
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：OnLocationUpdate- Received Location=， Version=http://PS1SITE.CONTOSO.COM:853038 ScanAgent
ScanJob（{4CD06388-D509-46E4-8C00-75909EDD9EE8}）： CScanJob：：Execute- 新增 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 受控伺服器原則以使用伺服器： http://PS1SITE.CONTOSO.COM:8530 WUAHandler
強制重新整理原則。 WUAHandler
等候 2 分鐘，組策略通知 WUA 原則變更...WUAHandler
等候 30 秒的原則對 WU 代理程式生效。 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 代理程式通訊的 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：

只有在 Service Pack 和定義更新取代這些更新時，掃描結果才會包含已取代的更新。 WUAHandler
搜尋準則為（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：搜尋 [ClientId = CcmExec]
2014-01-20 12：18：42：752 3856 708 COMAPI -- 提交 -- COMAPI <<：搜尋 [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 代理程式 ** START ** 代理程序：尋找更新 [CallerId = CcmExec]
2014-01-20 12：18：48：662 968 f58 代理程式 * 包含可能取代的更新
2014-01-20 12：18：48：662 968 f58 代理程式 * Online = 是;忽略下載優先順序 = 是
2014-01-20 12：18：48：662 968 f58 代理程式 * Criteria = “（DeploymentAction=* AND Type='Software'） OR （DeploymentAction=* AND Type='Driver'）”
2014-01-20 12：18：48：662 968 f58 代理程式 * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} 受控
2014-01-20 12：18：48：662 968 f58 代理程式 * 搜尋範圍 = {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 代理程式 * 已新增更新 {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 tosearch 結果
2014-01-20 12：18：52：683 968 f58 代理程式 * 已新增更新 {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 至搜尋結果
2014-01-20 12：18：52：694 968 f58 代理程式 * 在搜尋中找到 163 個更新和 70 個類別：評估的 appl。1150 個已部署實體中 622 的規則
2014-01-20 12：18：52：745 968 f58 代理程式 ** END ** 代理程序：尋找更新 [CallerId = CcmExec]
2014-01-20 12：18：52：755 3856 708 COMAPI -- RESUMED -- COMAPI >>：搜尋 [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：搜尋 [ClientId = CcmExec]

步驟 3：WUAHandler 會從 Windows Update 代理程式接收結果，並將掃描標示為完成

下列記錄WUAHandler.log：

異步搜尋已完成。 WUAHandler
完成在單一呼叫中搜尋所有專案。 WUAHandler

步驟 4：WUAHandler 剖析掃描結果

WUAHandler 接著會剖析結果，其中包含每個更新的適用性狀態。在此程式中，已取代的更新會剪除。下列記錄WUAHandler.log：

剪除：更新標識符（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分鐘）。

UpdatesStore.log顯示所記錄的遺漏更新狀態（KB2862152），以及正在引發的狀態消息：

處理更新狀態的更新狀態（505fda07-b4f3-45fb-83d9-8642554e2773）與 ProductID = 0fa1201d-4330-4fa8-8ae9- b87473b6441 UpdatesStore
更新狀態（505fda07-b4f3-45fb-83d9-8642554e2773）之前尚未報告，建立新的實例。 UpdatesStore
成功引發狀態消息以更新（505fda07-b4f3-45fb-83d9-8642554e2773）狀態（遺漏）。 UpdatesStore
已成功新增更新狀態的 WMI 實例（505fda07-b4f3-45fb-83d9-8642554e2773）。 UpdatesStore

StateMessage.log顯示狀態消息以狀態標識碼 2 記錄（遺漏）：

使用 TopicType 500 和 TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 新增訊息至 WMI StateMessage
狀態消息（狀態標識碼：2）已記錄 SYSTEM StateMessage 的 TopicType 500 和 TopicId 505fda07-b4f3-45fb-83d9-8642554e2773

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

CCM_UpdateStatus 類別實例的螢幕快照。

同樣地，會建立或更新類別的 CCM_StateMsg 實例，這會儲存更新的目前狀態。 CCM_StateMsg 類別位於 ROOT\CCM\StateMsg 命名空間中。

CCM_StateMsg 類別實例的螢幕快照。

步驟 6：狀態訊息會傳送至管理點

如先前所述，狀態消息會根據預設設定為15分鐘的狀態消息報告週期排程傳送至管理點。將狀態消息傳送至管理點之後， MessageSent 類別中狀態消息實例的 CCM_StateMsg 屬性會設定為 True。

在 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>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName>><CodePage 437</CodePage><>SystemDefaultLCID>1033</SystemDefaultLCID><優先順序>5/<><><><><>><Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent>><ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version>1.0</Version><格式>1.0</Format></ReportDetails/ReportHeader><ReportBody><StateMessage>< MessageTime=“20140120171855.573000+000” SerialNumber=“232”><主題標識符=“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 分鐘傳送至管理點。您可以在自訂或預設客戶端設定的狀態傳訊中修改此排程。

雖然StateMessage.log報告 已成功將狀態消息轉送至 MP，但狀態消息元件實際上不會傳送這些訊息本身。從管理點傳送和接收的所有訊息都會由用戶端上的 CCM 傳訊元件處理。 CCM 傳訊是與管理點通訊以傳送和接收數據的實際元件。管理點已定義各種佇列來處理不同類型的傳入流量。針對狀態消息，處理此流量的 MP_RelayEndpoint 佇列是佇列。

步驟 1：狀態消息元件會開始將訊息傳送至管理點

在 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><優先順序>5/<><><><><>><Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent>><ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version>1.0</Version><格式>1.0</Format></ReportDetails/ReportHeader><ReportBody><StateMessage>< MessageTime=“20140120171855.573000+000” SerialNumber=“232”><主題標識符=“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 位置要求區段中注意到的回復訊息，其中含有位置要求的郵件會收到回復。

在 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：在管理點上收到訊息，然後MP_Relay處理訊息並建立 SMX 檔案

由於所有訊息都是使用 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 訊息處理程式：啟動轉送的訊息處理----------------------- MP_RelayEndpoint
Mp 訊息處理程式：FileType=SMX MP_RelayEndpoint
訊息本文： <XML 本文截斷> MP_RelayEndpoint
轉送：Outbox dir： E：\ConfigMgr\inboxes\auth\statesys.box\incoming MP_RelayEndpoint
訊息中的優先順序 = 5 MP_RelayEndpoint
狀態優先順序目錄 = E：\ConfigMgr\inboxes\auth\statesys.box\incoming MP_RelayEndpoint
Inv-Relay：工作順利完成MP_RelayEndpoint

在遠端管理點MP_Relay.log：

Mp 訊息處理程式：啟動轉送的訊息處理------------------------------ 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>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName>><CodePage 437</CodePage><>SystemDefaultLCID>1033</SystemDefaultLCID><優先順序>5/<><><><><>><Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent>><ReportType Full</ReportType><>Date>20140120194656.903000+000</Date><Version>1.0</Version><格式>1.0</Format></ReportDetails/ReportHeader><ReportBody><StateMessage>< MessageTime=“20140120171855.573000+000” SerialNumber=“232”><主題標識符=“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
轉送：Outbox dir： C：\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
訊息中的優先順序 = 5 MP_RelayEndpoint
狀態優先順序目錄 = C：\SMS\mp\outboxes\StateMsg.box MP_RelayEndpoint
Inv-Relay：工作順利完成MP_RelayEndpoint

XML 主體看起來與用戶端上已登入StateMessage.log的內容相同。

步驟 4：MP 檔案發送管理員會將 SMX 檔案傳送至月臺伺服器（只有在管理點未共置在月臺伺服器上時）

當管理點遠端至月臺伺服器時，檔案抵達 outboxes\StateMsg.box 之後，MP 檔案分派管理員（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
線程「狀態消息處理線程 #0」識別碼：4316 已啟動SMS_STATE_SYSTEM
總切克載入（1） SMS_STATE_SYSTEM
CMessageProcessor - 處理檔案：YCE2H3VD。SMX SMS_STATE_SYSTEM
CMessageProcessor - 已處理 1 筆無效記錄的記錄。 SMS_STATE_SYSTEM
CMessageProcessor - 在此批次中處理了 1 個訊息檔案，並含有 0 個不正確的檔案。 SMS_STATE_SYSTEM
總切克載入（0） SMS_STATE_SYSTEM
線程「狀態消息處理線程 #0」標識碼：4316 已正常終止SMS_STATE_SYSTEM

在StateSys.log中，未啟用詳細信息記錄：

找到要處理的新狀態消息，開始處理線程SMS_STATE_SYSTEM
線程「狀態消息處理線程 #0」標識碼：1988 已啟動SMS_STATE_SYSTEM
總切克載入（1） SMS_STATE_SYSTEM
總切克載入（0） SMS_STATE_SYSTEM
線程「狀態消息處理線程 #0」標識碼：1988 已正常終止SMS_STATE_SYSTEM

除非狀態系統管理員啟用詳細資訊記錄，否則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>5.00.7958.1000</ClientVersion><NetBIOSName PS1WIN7X64</NetBIOSName>><CodePage 437</CodePage><>SystemDefaultLCID>1033</SystemDefaultLCID><優先順序>5/<><><><><>><Priority></Machine></Identification><ReportDetails><ReportContent State Message Data</ReportContent><>ReportType>Full</ReportType><Date>20140120220131.071000+000</Date><Version>1.0</Version><格式>1.0</Format></ReportDetails/ReportHeader><ReportBody><StateMessage>< MessageTime=“20140120171855.573000+000” SerialNumber=“239”><主題標識符=“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資料表，以尋找所有狀態訊息主題類型和識別碼的易記名稱：

SELECT * FROM SR_StateNames

軟體更新摘要

必須先摘要說明軟體更新合規性數據，才能在主控台或報告中呈現軟體更新合規性數據。這是必要的，因為控制台和報表通常只會顯示摘要數據。月臺伺服器上的狀態系統元件會執行軟體更新摘要，以及其他元件的摘要，例如應用程式、DCM 部署和用戶端健康情況。您可以藉由查詢 vSR_SummaryTasks Configuration Manager 資料庫中的檢視，找到狀態系統執行之所有摘要工作的相關信息。狀態系統會在設定的排程上執行這些工作，並記錄StateSys.log中每個工作的詳細數據：

已啟動的工作『<TaskName>』 SMS_STATE_SYSTEM
工作 '<TaskName>' 在執行 15 秒後成功完成，狀態為 8。 SMS_STATE_SYSTEM

對於大部分的工作，StateSys.log記錄的狀態不是錯誤碼。而是執行摘要的適當 SQL Server 預存程式所傳回的數據列數目。

軟體更新特定的摘要工作如下：

SUM 指派合規性評估工具

摘要說明所有軟體更新群組指派的狀態消息（部署）。此工作預設會每小時執行一次。您可以在 Configuration Manager 控制台>監視>部署中，以滑鼠右鍵按兩下部署，然後按兩下 [執行摘要]，手動起始此部署。
SUM 更新群組狀態摘要器

摘要說明更新群組的狀態。此工作預設會每小時執行一次。您可以在 Configuration Manager 控制台>軟體更新>>軟體更新群組中手動起始它，以滑鼠右鍵按兩下更新群組，然後按兩下 [執行摘要]。

您也可以在 [軟體更新群組] 上按下滑鼠右鍵，或在功能區中選取 [排程摘要] 來變更此工作的排程。
SUM 更新狀態摘要器

摘要說明所有用戶端的更新狀態。此工作預設會每小時執行一次。它可以在 Configuration Manager 控制台>軟體連結庫>軟體更新中手動起始，然後按兩下 [執行摘要]。您也可以選取 [排程摘要] 來變更預設排程。
SUM Migrate 更新狀態

在資料庫內部移轉更新狀態。此工作預設會每隔 24 小時執行一次。無法從 Configuration Manager 控制台手動起始。
SUM 刪除過時狀態

從資料庫中的軟體更新特定數據表中刪除過時狀態。此工作預設會每隔 24 小時執行一次。無法從 Configuration Manager 控制台手動起始。

軟體更新點切換

在 System Center 2012 Configuration Manager SP1 和更新版本中，月臺可以有多個 SUP。這會針對 SUP 變成無法使用的情況提供容錯功能。如需 SUP 故障轉移和切換的詳細資訊，請參閱下列文章：

共用方式為

追蹤軟體更新合規性評定

軟體更新掃描原則

步驟 1：成功同步處理之後，WSyncMgr 會更新資料庫中的內容版本和上次同步時間

步驟 2：SMSDBMON 會觸發並卸載。policypv.box 中的 STN 檔案

步驟 3：原則提供者會在資料庫中建立或更新 UpdateSource 原則

步驟 4：在用戶端上下載並評估原則

步驟 5：掃描代理程式收到 UpdateSource 原則更新的通知

WSUS 伺服器位置

步驟 1：掃描代理程式會根據可用的原則建立掃描要求

步驟 2：掃描代理程式會將 WSUS 位置的要求傳送至位置服務

步驟 3：位置服務會將位置要求傳送至管理點

步驟 4：CCM 傳訊會將位置要求訊息傳送至管理點

步驟 5：管理點會剖析要求、從資料庫取得 WSUS 位置，以及傳送回應

步驟 6：CCM 傳訊會接收回應，並將其傳回位置服務

步驟 7：位置服務會剖析回應，並將位置傳回掃描代理程式

步驟 8：掃描代理程式通知 WUAHandler 將更新來源新增至登錄

步驟 9：掃描代理程式會起始掃描

用戶端上的軟體更新掃描

步驟 1：掃描代理程式會要求掃描，而 WUAHandler 會起始掃描

步驟 2：Windows Update 代理程式（WUA）會針對 WSUS 計算機啟動掃描

步驟 3：WUAHandler 會從 Windows Update 代理程式接收結果，並將掃描標示為完成

步驟 4：WUAHandler 剖析掃描結果

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

步驟 6：狀態訊息會傳送至管理點

狀態消息處理流程

步驟 1：狀態消息元件會開始將訊息傳送至管理點

步驟 2：CCM 傳訊會將包含狀態訊息 XML 本文的訊息傳送至管理點

步驟 3：在管理點上收到訊息，然後MP_Relay處理訊息並建立 SMX 檔案

步驟 4：MP 檔案發送管理員會將 SMX 檔案傳送至月臺伺服器（只有在管理點未共置在月臺伺服器上時）

步驟 5：站台伺服器上的 StateSys 元件會將狀態消息處理至資料庫

軟體更新摘要

軟體更新點切換

意見反應

其他資源

共用方式為

追蹤軟體更新合規性評定

軟體更新掃描原則

步驟 1：成功同步處理之後，WSyncMgr 會更新資料庫中的內容版本和上次同步時間

步驟 2：SMSDBMON 會觸發並卸載 。policypv.box 中的 STN 檔案

步驟 3：原則提供者會在資料庫中建立或更新 UpdateSource 原則

步驟 4：在用戶端上下載並評估原則

步驟 5：掃描代理程式收到 UpdateSource 原則更新的通知

WSUS 伺服器位置

步驟 1：掃描代理程式會根據可用的原則建立掃描要求

步驟 2：掃描代理程式會將 WSUS 位置的要求傳送至位置服務

步驟 3：位置服務會將位置要求傳送至管理點

步驟 4：CCM 傳訊會將位置要求訊息傳送至管理點

步驟 5：管理點會剖析要求、從資料庫取得 WSUS 位置，以及傳送回應

步驟 6：CCM 傳訊會接收回應，並將其傳回位置服務

步驟 7：位置服務會剖析回應，並將位置傳回掃描代理程式

步驟 8：掃描代理程式通知 WUAHandler 將更新來源新增至登錄

步驟 9：掃描代理程式會起始掃描

用戶端上的軟體更新掃描

步驟 1：掃描代理程式會要求掃描，而 WUAHandler 會起始掃描

步驟 2：Windows Update 代理程式 （WUA） 會針對 WSUS 計算機啟動掃描

步驟 3：WUAHandler 會從 Windows Update 代理程式接收結果，並將掃描標示為完成

步驟 4：WUAHandler 剖析掃描結果

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

步驟 6：狀態訊息會傳送至管理點

狀態消息處理流程

步驟 1：狀態消息元件會開始將訊息傳送至管理點

步驟 2：CCM 傳訊會將包含狀態訊息 XML 本文的訊息傳送至管理點

步驟 3：在管理點上收到訊息，然後MP_Relay處理訊息並建立 SMX 檔案

步驟 4：MP 檔案發送管理員會將 SMX 檔案傳送至月臺伺服器（只有在管理點未共置在月臺伺服器上時）

步驟 5：站台伺服器上的 StateSys 元件會將狀態消息處理至資料庫

軟體更新摘要

軟體更新點切換

意見反應

其他資源

步驟 2：SMSDBMON 會觸發並卸載。policypv.box 中的 STN 檔案

步驟 2：Windows Update 代理程式（WUA）會針對 WSUS 計算機啟動掃描