Windows Updates, не работающий через SCCM 2012 R2

Мы обновили от 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, поэтому простите мне, если мой второй блок журналов бесполезен.

Я делал попытку решений, предлагаемых в этом вопросе без изменения в результатах. Кто-либо может предложить какие-либо другие предложения?

Дополнительные детали:

  • Синхронизация между WSUS и SCCM счастлива (подтвердил успешный wsyncmgr.log).
  • Содержание распределяется в SCCM (подтвердил успешный distmgr.log).
  • Никакие ошибки в журналах серверной стороны: PatchDownloader.log, SUPSetup.log, WCM.log,WSUSCtrl.log, или wsyncmgr.log.
1
задан 13 April 2017 в 15:14
1 ответ

Ответ на этот вопрос был дан в потоке 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.

  • ContentVersion
  • LastAttemptVersion
  • SyncToVersion

После перезапуска службы SMS_Executive обновления быстро стали доступны для всех рабочих станций, на которых они были развернуты.

Я признаю, что правильным было бы использовать XQuery для поиска XML-данных в таблице SQL по самому высокому значению для MinCatalogVersion; однако, у меня были очень сжатые сроки для исправления проблемы, и у меня не было времени на то, чтобы попытаться найти подходящий запрос. Таким образом, я просто установил все три значения реестра на 10,000 (десятичное) и надеялся на лучшее.

.
1
ответ дан 4 December 2019 в 00:21

Теги

Похожие вопросы