Мы обновили от SCCM 2012 SP1 на Сервере 2 008 R2 к R2 CU2 SCCM 2012 на Сервере 2 012 R2. Очень простая иерархия сайта - один сервер сайта обеспечивает MP, DP, ГЛОТОК, и т.д. роли, и имеет установленный WSUS (со всей конфигурацией, выполненной SCCM).
Я пытаюсь развернуть обновления Windows и обновления SCEP; мои обновления определения SCEP работают отлично, но обновления Windows 7, такие как безопасность и очень важный, не танцуют джайв так хорошо. Между Windows и обновлениями SCEP, соответствующими группами обновления программного обеспечения, ADRs, развертывание, и т.д. все идентичны до такой степени, что релевантно. Нет никаких ошибок в UpdatesDeployment.log
, UpdatesHandler.log
, UpdatesStore.log
, WUAHandler.log
, или WindowsUpdate.log
. Единственная вещь, которая особенно выделяется мне, состоит в том что когда я Цикл Сканирования Обновления программного обеспечения (клиентское действие SCCM) от клиента, WindowsUpdate.log
предложения эта информация:
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 = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
Agent * Search Scope = {Machine}
PT +++++++++++ PT: Synchronizing server updates +++++++++++
PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asmx
PT +++++++++++ PT: Synchronizing extended update info +++++++++++
PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asm
PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asmx
Agent * Added update {0BCA6C00-4FD3-4280-96BE-B89988FA1702}.101 to search result
~[Omitting 425 more lines identical except for the particular update GUID.]
Agent * Found 426 updates and 75 categories in search; evaluated appl. rules of 2398 out of 3466 deployed entities
Agent ** END ** Agent: Finding updates [CallerId = CcmExec]
~[Omitting a lot of identical lines that describe WUA's (successful) reporting.]
COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec]
COMAPI - Updates found = 426
COMAPI -- END -- COMAPI: Search [ClientId = CcmExec]
Таким образом, уж точно кажется, что это нашло некоторые обновления, но это никогда ничего не устанавливает, ни делает обновления, показанные в Центре программного обеспечения, даже при том, что развертывание настроено, чтобы сделать так. Однако, если я использую Windows Update для проверки на обновления на клиенте, я вкладываю этот результат WindowsUpdate.log
:
Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
Agent * Online = Yes; Ignore download priority = No
Agent * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
Agent * Search Scope = {Machine}
Setup Checking for agent SelfUpdate
Setup Client version: Core: 7.6.7600.320 Aux: 7.6.7600.320
~[Omitting lines about signature validation and SelfUpdate check (spoiler alert: "SelfUpdate is NOT required").]
PT +++++++++++ PT: Synchronizing server updates +++++++++++
PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asmx
PT +++++++++++ PT: Synchronizing extended update info +++++++++++
PT + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://[REDACTED]:8530/ClientWebService/client.asmx
Agent * Found 0 updates and 75 categories in search; evaluated appl. rules of 2398 out of 3466 deployed entities
Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
AU >>## RESUMED ## AU: Search for updates [CallId = {87B4DC09-5A34-4351-975C-EE9BB69D9346}]
AU # 0 updates detected
AU ## END ## AU: Search for updates [CallId = {87B4DC09-5A34-4351-975C-EE9BB69D9346}]
Я понятия не имею, относятся ли результаты Windows Automatic Updates к проблеме WSUS/SCCM, поэтому простите мне, если мой второй блок журналов бесполезен.
Я делал попытку решений, предлагаемых в этом вопросе без изменения в результатах. Кто-либо может предложить какие-либо другие предложения?
Дополнительные детали:
wsyncmgr.log
).distmgr.log
).PatchDownloader.log
, SUPSetup.log
, WCM.log
,WSUSCtrl.log
, или wsyncmgr.log
.Ответ на этот вопрос был дан в потоке TechNet.
SCCM 2012 великолепный контроль версии повышает версию каталога SUP каждый раз, когда он загружает новые обновления, как показано в колонке Catalog Version в разделе Monitoring -> Software Update Point Synchronization Status. Каждое обновление, которое SUP добавляет, вводится строкой в таблицу CI_ConfigurationItems в базе данных SCCM. Один столбец в этой таблице, SDMPackageDigest, содержит XML метаданные, включая строку, указывающую номер версии каталога, в который было добавлено обновление: <Имя свойства="MinCatalogVersion" Value="[x]". />
, где [x]
- десятичное целое число. При обновлении с 2012 SP1 на 2012 R2, мы импортировали всю нашу базу данных на новый сервер, что означало, что все обновления имели запись для MinCatalogVersion
, достигающую, по крайней мере, 2200. Однако, SCCM хранит каталоговую версию в ключах реестра, которые не были импортированы, что означало, что на новом сервере номер версии был перезапущен на 1. Таким образом, SUP не устанавливал обновления, которые имели бы более высокую MinCatalogVersion
, чем каталоговая версия, которая была. ...по сути, все.
Исправление заключается в изменении трех значений реестра на сервере SCCM, все они расположены в ключе HKLM\SOFTWARE\Microsoft\SMS\Components\SMS_WSUS_SYNC_MANAGER
.
После перезапуска службы SMS_Executive обновления быстро стали доступны для всех рабочих станций, на которых они были развернуты.
Я признаю, что правильным было бы использовать XQuery для поиска XML-данных в таблице SQL по самому высокому значению для MinCatalogVersion
; однако, у меня были очень сжатые сроки для исправления проблемы, и у меня не было времени на то, чтобы попытаться найти подходящий запрос. Таким образом, я просто установил все три значения реестра на 10,000 (десятичное) и надеялся на лучшее.