Устранение неполадок управления обновлениями программного обеспечения в Configuration Manager

Эта статья поможет устранить неполадки в процессе управления обновлениями программного обеспечения в Configuration Manager. Она включает сканирование обновлений клиентского программного обеспечения, проблемы синхронизации и обнаружение проблем с конкретными обновлениями.

Исходная версия продукта: Configuration Manager (текущая ветвь), System Center 2012 R2 Configuration Manager, System Center 2012 Configuration Manager
Исходный номер базы знаний: 4505440

Область проблемы

В этом руководстве предполагается, что точка обновления программного обеспечения уже установлена и настроена. Дополнительные сведения о настройке обновлений программного обеспечения в Configuration Manager см. в разделе Prepare для управления обновлениями программного обеспечения.

Прежде чем приступить к устранению неполадок, важно подчеркнуть, что лучше понять проблему, которую вы испытываете, быстрее и проще будет для вас исправить ее. Будь то задача по устранению проблемы, с которой вы столкнулись, или проблема, сообщаемая вами кем-либо в вашей организации, выполните некоторое время и ответьте на следующие вопросы:

1. Что конкретно не работает и/или какова ваша цель?
2. Какова частота или шаблон проблемы? Проблема по-прежнему возникает?
3. Как вы узнали, что проблема существует?
4. Он когда-либо работал? Если да, когда это остановилось? Было ли что-либо изменено в среде прямо перед остановкой работы?
5. Какой процент затронутых клиентов?
6. Что уже сделано (если что-нибудь), чтобы попытаться исправить его?
7. Сведения о точной версии клиента и версии сервера. Актуальны ли эти системы?
8. Что общего у затронутых клиентов? Например, одна подсеть, сайт AD, домен, физическое расположение, сайт, система сайта.

Знание и понимание ответов на эти вопросы поместит вас на лучший путь для быстрого и легкого решения любой проблемы, которую вы испытываете.

Если вы знаете конкретную область в процессе управления обновлениями программного обеспечения, которую вы хотите устранить, выберите ее ниже. Начните с проверки обновления клиентского программного обеспечения, если не уверены, и мы рассмотрим весь процесс с начала до конца.

• Сканирование обновлений клиентского программного обеспечения
• Синхронизация WSUS с Майкрософт Update
• Проблемы с установкой, заменой или обнаружением определенных обновлений

Сканирование обновлений клиентского программного обеспечения

Процесс сканирования клиента описан в следующих шагах. Убедитесь, что каждый шаг правильно определяет, где возникла проблема.

Шаг 1. Клиент отправляет запрос расположения WSUS в точку управления.

Первое, что делает клиент, — это настраивает сервер WSUS в качестве источника для сканирования обновлений программного обеспечения. Этот процесс подробно описан ниже.

1. Когда клиенту Configuration Manager необходимо обработать проверку обновления программного обеспечения, агент сканирования создает запрос проверки на основе доступной политики, как указано в ScanAgent.log:

   CScanAgent::ScanByUpdates- Policy available for UpdateSourceID={SourceID}  
   ContentVersion=38  
   CScanAgent::ScanByUpdates- Added Policy to final ScanRequest List UpdateSourceID={SourceID}, Policy-ContentVersion=38, Required-ContentVersion=38
   

2. Агент сканирования теперь отправляет запрос на местоположение WSUS в службы местоположения, как это отражено в ScanAgent.log.

   Inside CScanAgent::ProcessScanRequest()  
   CScanJobManager::Scan- entered  
   ScanJob({JobID}): CScanJob::Initialize- entered  
   ScanJob({JobID}): CScanJob::Scan- entered  
   ScanJob({JobID}): CScanJob::RequestLocations- entered  
   - - - - - -Requesting WSUS Server Locations from LS for {WSUSLocationID} version 38  
   - - - - - -Location Request ID = {LocationRequestID}  
   CScanAgentCache::PersistInstanceInCache- Persisted Instance CCM_ScanJobInstance  
   ScanJob({JobID}): - - - - - -Locations requested for ScanJobID={JobID} (LocationRequestID={LocationRequestID}), will process the scan request once locations are available.
   

   Подсказка

   Каждое задание сканирования хранится в WMI в CCM_ScanJobInstance классе:

   Пространство имен: root\CCM\ScanAgent Класс: CCM_ScanJobInstance

3. Службы расположений создают запрос расположения и отправляют его в точку управления. Идентификатор пакета для запроса расположения WSUS — это уникальный идентификатор источника обновления. В LocationServices.log:

   CCCMWSUSLocation::GetLocationsAsyncEx  
   Attempting to persist WSUS location request for ContentID='{ContentID}' and ContentVersion='38'  
   Persisted WSUS location request LocationServices  
   Attempting to send WSUS Location Request for ContentID='{ContentID}'
   WSUSLocationRequest : <WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><Forest Name="CONTOSO.COM"/><Domain Name="CONTOSO.COM"/><IPAddresses><IPAddress SubnetAddress="192.168.2.0" Address="192.168.2.62"/></IPAddresses></ClientLocationInfo></WSUSLocationRequest>  
   Created and Sent Location Request '{LocationRequestID}' for package {ContentID}
   

4. Служба обмена сообщениями CCM отправляет сообщение запроса расположения в точку управления. В CcmMessaging.log:

   Sending async message '{Message}' to outgoing queue 'mp:[http]mp_locationmanager'  
   Sending outgoing message '{Message}'. Flags 0x200, sender account empty
   

5. Управляющая точка анализирует этот запрос и вызывает MP_GetWSUSServerLocations хранимую процедуру, чтобы получить местоположение WSUS из базы данных. В MP_Location.log:

   MP LM: Message Body : \<WSUSLocationRequest SchemaVersion="1.00"><Content ID="{ContentID}" Version="38"/><AssignedSite SiteCode="PS1"/><ClientLocationInfo OnInternet="0"><ADSite Name="CM12-R2PS1"/><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: calling MP_GetWSUSServerLocations
   

   В 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'{WSUSServerLocationsID}',N'38',N'PS1',N'PS1',N'0',N'CONTOSO.COM'
   

6. После получения результатов из хранимой процедуры точка управления отправляет клиенту ответ. В MP_Location.log:

   MP LM: Reply message body: <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>
   

7. CCM-мессенджер получает ответ и отправляет его обратно в службы геолокации. В CcmMessaging.log:

   Message '{Message1}' got reply '{Message2}' to local endpoint queue 'LS_ReplyLocations'  
   OutgoingMessage(Queue='mp_[http]mp_locationmanager', ID={*Message1*}):  
   Delivered successfully to host 'PS1SYS.CONTOSO.COM'.  
   Message '{Message2}' delivered to endpoint 'LS_ReplyLocations'
   

8. Службы определения местоположения анализируют ответ и отправляют местоположение обратно в Агент сканирования. В LocationServices.log:

   Processing Location reply message LocationServices  
   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>  
   Calling back with the following WSUS locations  
   WSUS Path='http://PS1SITE.CONTOSO.COM:8530', Server='PS1SITE.CONTOSO.COM', Version='38'  
   WSUS Path='https://PS1SYS.CONTOSO.COM:8531', Server='PS1SYS.CONTOSO.COM', Version='38'  
   Calling back with locations for WSUS request {WSUSLocationID}
   

9. Агент сканирования теперь имеет политику и расположение источника обновления с соответствующей версией содержимого. В ScanAgent.log:

   *****WSUSLocationUpdate received for location request guid={LocationGUID}  
   ScanJob({JobID}): CScanJob::OnLocationUpdate- Received  
   Location=<http://PS1SITE.CONTOSO.COM:8530>, Version=38  
   ScanJob({JobID}): CScanJob::Execute- Adding UpdateSource={SourceID}, ContentType=2, ContentLocation=<http://PS1SITE.CONTOSO.COM:8530>, ContentVersion=38
   

10. Агент сканирования уведомляет WUAHandler о добавлении источника обновления. WUAHandler добавляет источник обновления в реестр. Он инициирует обновление групповой политики, если клиент находится в домене, чтобы определить, переопределяет ли групповая политика добавленный сервер обновлений. Следующие записи вошли в систему WUAHandler.log с добавлением нового источника обновления:

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it  
    Its a completely new WSUS Update Source  
    Enabling WUA Managed server policy to use server: <http://PS1SITE.CONTOSO.COM:8530>
    Policy refresh forced  
    Waiting for 2 mins for Group Policy to notify of WUA policy change  
    Waiting for 30 secs for policy to take effect on WU Agent.  
    Added Update Source ({UpdateSource}) of content type: 2
    

    В это время агент клиентский компонент Центра обновления Windows видит изменение конфигурации WSUS. В WindowsUpdate.log:

    * WSUS server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
    * WSUS status server: <http://PS1SITE.CONTOSO.COM:8530> (Changed)  
    Sus server changed through policy.
    

    Следующие ключи реестра проверяются и задаются:

    Подраздел реестра	Имя параметра	Тип	Данные
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate	WUServer	REG_SZ	Полный URL-адрес сервера WSUS, включая порт. Например: <http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate	WUStatusServer	REG_SZ	Полный URL-адрес сервера WSUS, включая порт. Например: <http://PS1Site.Contoso.com:8530>
    HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate\AU	UseWUServer	REG_DWORD	0x1

    Для существующего клиента мы могли бы увидеть следующее сообщение в WUAHandler.log, чтобы указать, когда версия содержимого добавилась:

    Its a WSUS Update Source type ({WSUSUpdateSource}), adding it.  
    WSUS update source already exists, it has increased version to 38.
    

11. После успешного добавления источника обновления агент сканирования создает сообщение о состоянии и запускает проверку. В ScanAgent.log:

    ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2  
    ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
    

Устранение неполадок на шаге 1

Дополнительные сведения об устранении неполадок при проверке обновлений программного обеспечения см. в разделе "Устранение неполадок с проверкой обновлений программного обеспечения".

Шаг 2. Агент сканирования запрашивает сканирование и WUAHandler запускает сканирование.

После того как клиент определил и назначил сервер WSUS в качестве источника для сканирования обновлений программного обеспечения, агент сканирования запрашивает сканирование у WUAHandler, который использует API агента клиентский компонент Центра обновления Windows для выполнения проверки обновлений с помощью агента клиентский компонент Центра обновления Windows. Сканирование может привести к следующим результатам:

• Проверка запланированного или ручного обновления программного обеспечения
• Переоценка развертывания обновления программного обеспечения, запланированного или выполненного вручную.
• Развертывание, которое становится активным

Сканирование запускает оценку. В ScanAgent.log:

ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1

Результаты проверки будут включать устаревшие обновления только в том случае, если они замещены пакетами обновления и обновлениями определений. В WUAHandler.log:

Search Criteria is (DeploymentAction=* AND Type='Software') OR (DeploymentAction=* AND Type='Driver')  
Running single-call scan of updates.  
Async searching of updates using WUAgent started.

Устранение неполадок на шаге 2

Многие проблемы с проверкой обновлений программного обеспечения могут быть вызваны одной из следующих причин:

• Отсутствуют или повреждены файлы или разделы реестра.
• Проблемы с регистрацией компонентов.

Чтобы устранить такие проблемы, ознакомьтесь с ошибками сканирования из-за отсутствия или повреждения компонентов.

Существует известная проблема, из-за которой 32-разрядный клиент ConfigMgr 2012 R2 на Windows 7, запрашивающий сканирование обновлений, не может вернуть результаты сканирования в Configuration Manager. Это приводит к тому, что клиент сообщает о неправильном состоянии соответствия требованиям, и обновления не устанавливаются, когда Configuration Manager запрашивает цикл обновления. Однако если вы используете апплет панели управления клиентский компонент Центра обновления Windows, обновления обычно устанавливаются нормально. При возникновении этой проблемы вы получите сообщение, аналогичное следующему в WindowsUpdate.log:

WARNING: ISusInternal::GetUpdateMetadata2 failed, hr=8007000E

Это проблема с выделением памяти, 64-разрядная Windows 7 компьютеры не увидят эту ошибку, так как их адресное пространство фактически неограниченно. Однако они будут демонстрировать высокую память и высокую загрузку ЦП, что может повлиять на производительность. Клиенты X86 также будут отображать высокую нагрузку на память (обычно около 1,2 ГБ до 1,4 ГБ).

Чтобы устранить эту проблему, примените клиент клиентский компонент Центра обновления Windows для Windows 7: июнь 2015.

При устранении неполадок сканирования проверьте WUAHandler.log и WindowsUpdate.log файлы. WUAHandler просто сообщает, что сообщил агент клиентский компонент Центра обновления Windows. Таким образом, ошибка в WUAHandler будет той же ошибкой, о которой сообщил сам агент клиентский компонент Центра обновления Windows. Дополнительные сведения об ошибке можно найти в WindowsUpdate.log. Сведения о том, как читать WindowsUpdate.log, см. в разделе клиентский компонент Центра обновления Windows файлы журналов.

Лучший источник информации будет поступать из журналов и кодов ошибок, которые они содержат. Дополнительные сведения о кодах ошибок см. в разделе клиентский компонент Центра обновления Windows распространенные ошибки и устранение.

Шаг 3. клиентский компонент Центра обновления Windows агент (WUA) запускает проверку на компьютере WSUS.

клиентский компонент Центра обновления Windows агент запускает проверку после получения запроса от клиента Configuration Manager (CcmExec). Если эти значения реестра правильно заданы на компьютере WSUS, который через локальную политику является действительным SUP для сайта, вы увидите запрос на поиск COM API от клиента Configuration Manager (ClientId = CcmExec). В WindowsUpdate.log:

COMAPI -- START -- COMAPI: Search [ClientId = CcmExec]  
COMAPI <<-- SUBMITTED -- COMAPI: Search [ClientId = CcmExec] PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
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 = {ServiceID} Managed  
Agent * Search Scope = {Machine}

PT + ServiceId = {ServiceID}, Server URL = <http://PS1.CONTOSO.COM:8530/ClientWebService/client.asmx>  
Agent * Added update {4AE85C00-0EAA-4BE0-B81B-DBD7053D5FAE}.104 to search result  
Agent * Added update {57260DFE-227C-45E3-9FFC-2FC77A67F95A}.104 to search result  
Agent * Found 163 updates and 70 categories in search; evaluated appl. rules of 622 out of 1150 deployed entities  
Agent ** END ** Agent: Finding updates [CallerId = CcmExec]  
COMAPI >>-- RESUMED -- COMAPI: Search [ClientId = CcmExec]  
COMAPI - Updates found = 163  
COMAPI -- END -- COMAPI: Search [ClientId = CcmExec]

Устранение неполадок на шаге 3

Во время проверки агент клиентский компонент Центра обновления Windows должен взаимодействовать с ClientWebService и SimpleAuthWebService виртуальными директориями на компьютере WSUS для выполнения сканирования. Если клиент не может взаимодействовать с компьютером WSUS, проверка завершится ошибкой. Эта проблема может возникнуть по многим причинам, в том числе:

• Проблемы, связанные с прокси-сервером

  Чтобы устранить эти проблемы, ознакомьтесь с ошибками сканирования из-за проблем, связанных с прокси-сервером.

  Дополнительные сведения о прокси-серверах см. в следующих статьях:

  • Как клиент клиентский компонент Центра обновления Windows определяет, какой прокси-сервер следует использовать для подключения к веб-сайту клиентский компонент Центра обновления Windows
  • Поддержка DNS и DHCP для веб-прокси и автоматического обнаружения клиента брандмауэра

• Ошибки времени ожидания HTTP

  Чтобы разобраться с ошибками времени ожидания HTTP, сначала проверьте журналы Internet Information Services (IIS) на компьютере WSUS, чтобы убедиться, что ошибки действительно исходят от WSUS. Если компьютер WSUS не возвращает ошибку, проблема, скорее всего, связана с промежуточным брандмауэром или прокси-сервером.

  Если компьютер WSUS возвращает ошибку, проверьте подключение к компьютеру WSUS. Ниже приведены шаги.

  1. Чтобы убедиться, что клиент подключается к правильному серверу WSUS, найдите URL-адрес компьютера WSUS, используемого клиентом агента клиентский компонент Центра обновления Windows. Этот URL-адрес можно найти, проверив подраздел реестра HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Майкрософт\Windows\WindowsUpdate или просмотрев файл WindowsUpdate.log.

     Распространенные причины, по которым назначение WSUS может быть неверным, включают:

     • Конфликты групповой политики
     • Добавление SUP на дополнительный сайт после первоначальной установки клиента

     Примечание.

     Active Directory групповая политика может переопределить локальную политику WSUS.

     Функция обновления программного обеспечения автоматически настраивает локальные параметры групповой политики для клиента Configuration Manager, обеспечивая их настройку с использованием источника точки обновления и номера порта. Имя сервера и номер порта необходимы для поиска точки обновления программного обеспечения.

     Если параметр групповой политики Active Directory применяется к компьютерам для установки клиента точки обновления программного обеспечения, он переопределяет локальный параметр групповой политики. Если значение параметра, определенного в групповой политике Active Directory, отличается от заданного в Configuration Manager, сканирование завершится с ошибкой на клиенте, так как не удается найти правильный компьютер WSUS. В этой ситуации WUAHandler.log покажет следующее сообщение:

     Параметры групповой политики были перезаписаны вышестоящим органом (контроллером домена) для: сервер <http://server> и политика включена

     Точка обновления программного обеспечения для установки клиента и обновлений программного обеспечения должна быть одной и той же сервером. И он должен быть указан в параметре групповой политики Active Directory с правильным форматом имени и сведениями о порту. Например, если <http://server1.contoso.com:80> точка обновления программного обеспечения использует веб-сайт по умолчанию.

  2. Если URL-адрес сервера правильный, обратитесь к серверу с помощью URL-адреса, аналогичного следующему, чтобы проверить подключение между клиентом и компьютером WSUS:

     <http://SUPSERVER.CONTOSO.COM:8530/Selfupdate/wuident.cab>

     Чтобы проверить, может ли клиент получить доступ к виртуальному ClientWebService каталогу, попробуйте получить доступ к URL-адресу, аналогичному этому:

     <http://SUPSERVER.CONTOSO.COM:8530/ClientWebService/wusserverversion.xml>

     Чтобы проверить, имеет ли клиент доступ к SimpleAuthWebService, попробуйте открыть похожий URL-адрес.

     <http://SUPSERVER.CONTOSO.COM:8530/SimpleAuthWebService/SimpleAuth.asmx>

     Если какой-либо из этих URL-адресов не работает, некоторые из возможных причин включают:

     • Проблемы с разрешением имен на клиенте. Убедитесь, что вы можете разрешить FQDN компьютера WSUS.

     • Проблемы с конфигурацией прокси-сервера.

     • Другие проблемы с подключением, связанные с сетью.

     • Проблемы с конфигурацией портов, поэтому рекомендуется проверить правильность параметров порта. Службы WSUS можно настроить для использования любого из следующих портов: 80, 443 или 8530, 8531.

       Чтобы клиенты взаимодействовали с компьютером WSUS, соответствующие порты должны быть разрешены на брандмауэре на компьютере WSUS. Параметры порта настраиваются при создании роли системы сайта точки обновления программного обеспечения. Эти параметры порта должны совпадать с параметрами порта, используемыми веб-сайтом WSUS. В противном случае диспетчер синхронизации WSUS не сможет подключиться к службам WSUS, работающим в точке обновления программного обеспечения, чтобы запросить синхронизацию. Следующие процедуры содержат сведения о том, как проверить параметры порта, используемые WSUS и точкой обновления программного обеспечения.

       1. Определите параметры порта WSUS, используемые в службах IIS 7.0 и более поздних версий.

       2. Определите параметры порта WSUS в IIS 6.0.

       3. Настройте порты для точки обновления программного обеспечения.

       4. Проверка подключения к порту

          Чтобы проверить подключение к порту от клиента, выполните следующую команду:

          telnet SUPSERVER.CONTOSO.COM <portnumber>
          

          Например, выполните следующую команду, если порт равен 8530:

          telnet SUPSERVER.CONTOSO.COM 8530
          

          Если порт недоступен, telnet вернет ошибку, похожую на следующую:

          Не удалось открыть подключение к узлу в порте <PortNumber>

          Эта ошибка предполагает, что правила брандмауэра не настроены для связи с компьютером WSUS. Эта ошибка также может предложить, что промежуточное сетевое устройство блокирует этот порт. Чтобы проверить, попробуйте выполнить тот же тест из клиента в той же локальной подсети. Если это работает, компьютеры настроены правильно. Однако маршрутизатор или брандмауэр между сегментами блокирует порт и вызывает сбой.

     • Проблемы с доступностью IIS.

       1. На компьютере WSUS откройте диспетчер Internet Information Services (IIS.
       2. Разверните Сайты, щелкните правой кнопкой мыши веб-сайт компьютера WSUS и нажмите Изменить привязки.
       3. В диалоговом окне "Привязки сайта" значения портов HTTP и HTTPS отображаются в столбце "Порт".
       4. На сервере WSUS откройте диспетчер Internet Information Services (IIS.
       5. Разверните веб-сайты, щелкните правой кнопкой мыши веб-сайт компьютера WSUS, а затем выберите пункт "Свойства".
       6. Щелкните вкладку веб-сайта . Параметр HTTP-порта отображается в TCP-порту , а параметр порта HTTPS отображается в SSL-порту.
       7. В консоли Configuration Manager перейдите в раздел Administration>Site Configuration>Servers and Site System Roles, затем щелкните на <SiteSystemName> в правой панели.
       8. В нижней области щелкните правой кнопкой мыши точку обновления программного обеспечения и выберите пункт "Свойства".
       9. Перейдите на вкладку "Общие" , укажите или проверьте номера портов конфигурации WSUS.

• Ошибки проверки подлинности

  Обычно это указывает, когда проверка завершается ошибкой проверки подлинности 0x80244017 (состояние HTTP 401) или 0x80244018 (состояние HTTP 403).

  Сначала проверьте правильные параметры прокси-сервера WinHTTP с помощью следующих команд:

  • В Windows Vista или более поздних версиях: netsh winhttp show proxy
  • В Windows XP: proxycfg.exe

  Если параметры прокси-сервера верны, проверьте подключение к компьютеру WSUS, выполнив действия, описанные в ошибках времени ожидания HTTP. Также просмотрите журналы IIS на компьютере WSUS, чтобы убедиться, что ошибки HTTP возвращаются из WSUS. Если компьютер WSUS не возвращает ошибку, проблема, скорее всего, связана с промежуточным брандмауэром или прокси-сервером.

• Проблемы с сертификатом

  Проблемы с сертификатами указываются кодом ошибки 0x80072F0C, что означает"Сертификат требуется для завершения проверки подлинности клиента". Чтобы исправить эту ошибку, см. статью Сканирование завершилось неудачей с ошибкой 0x80072f0c.

Шаг 4. WUAHandler получает результаты от агента клиентский компонент Центра обновления Windows и помечает сканирование как завершенное

В WUAHandler.log фиксируются следующие записи:

Async searching completed.  
Finished searching for everything in single call.

Устранение неполадок на шаге 4

Здесь необходимо устранить проблемы так же, как и сбои сканирования на шаге 3.

Как упоминалось ранее в этом руководстве при устранении неполадок сканирования, проверьте WUAHandler.log и WindowsUpdate.log файлы. WUAHandler просто сообщает, что сообщил агент клиентский компонент Центра обновления Windows. Таким образом, ошибка в WUAHandler будет такой же, как и ошибка, о которой сообщил сам агент клиентский компонент Центра обновления Windows. Дополнительные сведения об ошибке можно найти в WindowsUpdate.log. Сведения о том, как читать WindowsUpdate.log, см. в разделе клиентский компонент Центра обновления Windows файлы журналов.

Причин, по которым сканирование обновлений программного обеспечения может не удастся, много. Это может быть вызвано одним из упомянутых ранее проблем или проблемы с взаимодействием или брандмауэром между клиентом и компьютером точки обновления программного обеспечения. Лучший источник информации будет поступать из журналов и кодов ошибок, которые они содержат. Дополнительные сведения о кодах ошибок см. в разделе клиентский компонент Центра обновления Windows распространенные ошибки и устранение.

Шаг 5. WUAHandler анализирует результаты сканирования

Затем WUAHandler анализирует результаты, которые включают состояние применимости для каждого обновления. В рамках этого процесса замененные обновления удаляются. Состояние применимости проверяется для всех обновлений, которые соответствуют критериям, отправленным CCMExec агенту клиентский компонент Центра обновления Windows. Важно понимать здесь, что следует видеть результаты применимости для обновлений, независимо от того, находятся ли эти обновления в развертывании.

Следующие записи записываются в WUAHandler.log.

> Pruning: update id (70f4f236-0248-4e84-b472-292913576fa1) is superseded by (726b7201-862a-4fde-9b12-f36b38323a6f).  
> ...  
> Update (Installed): Security Update for Windows 7 for x64-based Systems (KB2584146) (4ae85c00-0eaa-4be0-b81b-dbd7053d5fae, 104)  
> Update (Missing): Security Update for Windows 7 for x64-based Systems (KB2862152) (505fda07-b4f3-45fb-83d9-8642554e2773, 200)  
> ...  
> Successfully completed scan.

Устранение неполадок на шаге 5

Проблемы можно устранить так же, как и сбои сканирования на шаге 3.

Как упоминалось ранее в этом руководстве при устранении неполадок сканирования, проверьте WUAHandler.log и WindowsUpdate.log файлы. WUAHandler просто сообщает, что сообщил агент клиентский компонент Центра обновления Windows. Та же ошибка, что и в случае с самим агентом клиентский компонент Центра обновления Windows, будет присутствовать и в WUAHandler. Дополнительные сведения об ошибке можно найти в WindowsUpdate.log. Сведения о том, как читать WindowsUpdate.log, см. в разделе клиентский компонент Центра обновления Windows файлы журналов.

Как правило, существует множество причин, по которым сканирование обновлений программного обеспечения может потерпеть неудачу. Это может быть вызвано одной из упомянутых ранее проблем, или проблемой связи или брандмауэра между клиентом и компьютером точки обновления программного обеспечения. Лучший источник информации будет поступать из журналов и кодов ошибок, которые они содержат. В качестве справки см. статью клиентский компонент Центра обновления Windows распространенные ошибки и их устранение.

Шаг 6. Обновление хранилища записывает состояние и вызывает сообщение о состоянии для каждого обновления в WMI

После того как результаты сканирования будут доступны, эти результаты хранятся в хранилище обновлений. Хранилище обновлений записывает текущее состояние каждого обновления и создает сообщение о состоянии для каждого обновления. Эти сообщения состояния перенаправляются на сервер сайта массово в конце цикла отчетов о состоянии (это минуты по умолчанию). Только при следующих обстоятельствах мы отправляем сообщение о состоянии.

• Предыдущее сообщение о состоянии никогда не отправлялось для обновления (запись журнала: раньше не сообщалось, создание нового экземпляра).
• Состояние применимости обновления изменилось с момента отправки последнего сообщения о состоянии.

UpdatesStore.log показывающий состояние отсутствующего обновления (KB2862152) и генерируется соответствующее сообщение о состоянии:

Processing update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) with ProductID = 0fa1201d-4330-4fa8-8ae9b877473b6441  
Update status from update (505fda07-b4f3-45fb-83d9-8642554e2773) hasn't been reported before, creating new instance.  
Successfully raised state message for update (505fda07-b4f3-45fb-83d9-8642554e2773) with state (Missing).  
Successfully added WMI instance of update status (505fda07-b4f3-45fb-83d9-8642554e2773).

StateMessage.log показывает сообщение о состоянии, записанное с идентификатором состояния 2 (отсутствует):

Adding message with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 to WMI  
State message(State ID : 2) with TopicType 500 and TopicId 505fda07-b4f3-45fb-83d9-8642554e2773 has been recorded for SYSTEM

Устранение неполадок на шаге 6

Здесь необходимо устранить проблемы так же, как и сбои сканирования на шаге 3.

Как упоминалось ранее в этом руководстве при устранении неполадок сканирования, проверьте WUAHandler.log и WindowsUpdate.log файлы. WUAHandler просто сообщает, что сообщил агент клиентский компонент Центра обновления Windows. Та же ошибка, что и в случае с самим агентом клиентский компонент Центра обновления Windows, будет присутствовать и в WUAHandler. Дополнительные сведения об ошибке можно найти в WindowsUpdate.log. Сведения о том, как читать WindowsUpdate.log, см. в разделе клиентский компонент Центра обновления Windows файлы журналов.

Как правило, существует множество причин, по которым сканирование обновлений программного обеспечения может потерпеть неудачу. Это может быть вызвано одной из упомянутых ранее проблем, или проблемой связи или брандмауэра между клиентом и компьютером точки обновления программного обеспечения. Лучший источник информации будет поступать из журналов и кодов ошибок, которые они содержат. В качестве справки см. статью клиентский компонент Центра обновления Windows распространенные ошибки и их устранение.

Шаг 7. Сообщения о состоянии отправляются в точку управления

Когда WUAHandler успешно получает результаты от агента клиентский компонент Центра обновления Windows, он помечает сканирование как завершенное и записывает следующее сообщение в WUAHandler.log:

Async searching completed. WUAHandler  
Finished searching for everything in single call

Устранение неполадок на шаге 7

Здесь должны быть устранены проблемы так же, как и сбои сканирования на шаге 3, хотя сбои на этом этапе, скорее всего, будут отображаться в файле WindowsUpdate.log конкретно. Сведения о том, как читать WindowsUpdate.log, см. в разделе клиентский компонент Центра обновления Windows файлы журналов.

Как правило, существует множество причин, по которым сканирование обновлений программного обеспечения может потерпеть неудачу. Это может быть вызвано одной из упомянутых ранее проблем, или проблемой связи или брандмауэра между клиентом и компьютером точки обновления программного обеспечения. Лучший источник информации будет поступать из журналов и кодов ошибок, которые они содержат. В качестве справки см. статью клиентский компонент Центра обновления Windows распространенные ошибки и их устранение.

Синхронизация WSUS с Майкрософт Update

Синхронизация WSUS с Майкрософт Update описана в следующих шагах. Убедитесь, что каждый шаг правильно определяет, где возникла проблема.

Шаг 1. Синхронизация начинается с запланированного или ручного запроса

При активации синхронизации мы ожидаем, что в SoftwareDistribution.log сервера WSUS будут отображаться следующие сообщения:

Для синхронизации вручную:

Changew3wp.6AdminDataAccess.StartSubscriptionManuallySynchronization manually started  
Info WsusService.27EventLogEventReporter.ReportEvent  
EventId=382,Type=Information,Category=Synchronization,Message=A manual synchronization was started.

Для запланированной синхронизации:

InfoWsusService.10EventLogEventReporter.ReportEvent  
EventId=381,Type=Information,Category=Synchronization,Message=A scheduled synchronization was started.

Устранение неполадок с синхронизацией вручную на шаге 1

1. Убедитесь, что служба WSUS запущена. Если синхронизация была запущена вручную, но остается на уровне 0%, служба WSUS (Update Services в WSUS 3.x; WSUSService на Windows Server 2012 и более поздних версиях) находится в остановленном состоянии.

2. Сбросьте кэш консоли WSUS MMC, выполнив следующие действия.

   1. Закройте консоль WSUS.
   2. Остановите службу WSUS (Update Services в WSUS 3.x; WSUS Service на Windows Server 2012 и более поздних версиях).
   3. Перейдите к %appdata%\Майкрософт\mmc.
   4. Переименуйте wsus в wsus_bak.
   5. Запустите службу WSUS.
   6. Откройте консоль WSUS и попробуйте другую синхронизацию вручную.

Устранение неполадок запланированной синхронизации на шаге 1

1. Попробуйте выполнить синхронизацию вручную из консоли WSUS.
2. Если синхронизация выполняется вручную, проверьте параметры запланированной синхронизации.

Шаг 2. WSUS устанавливает соединение с Майкрософт Update (MU)

После запуска синхронизации сервер WSUS пытается выполнить HTTP-подключение через WinHTTP. При устранении неполадок подключения следует учитывать следующие факторы:

WSUS <=winhttp=> Сетевые сущности <=> Интернет

• Существует ли сетевая сущность (прокси-сервер, брандмауэр, фильтр безопасности и т. д.) между узлом WSUS и Интернетом?
• Если прокси-сервер существует, а сервер WSUS необходим для использования прокси-сервера, настроен ли прокси-сервер в соответствующих параметрах WSUS?

Устранение неполадок с синхронизацией вручную на шаге 2

1. Убедитесь, что служба WSUS запущена. Если синхронизация была запущена вручную, но она остается на уровне 0%, служба WSUS (Update Services в WSUS 3.x; WSUS Service в Windows Server 2012 и более поздних версиях) находится в остановленном состоянии.

2. Сбросьте кэш MMC консоли WSUS, выполнив следующие действия:

   1. Закройте консоль WSUS.
   2. Остановите службу WSUS (Update Services в WSUS 3.x; WSUS Service на Windows Server 2012 и более поздних версиях).
   3. Перейдите к %appdata%\Майкрософт\mmc.
   4. Переименуйте wsus в wsus_bak.
   5. Запустите службу WSUS.
   6. Откройте консоль WSUS и попробуйте другую синхронизацию вручную.

Устранение неполадок запланированной синхронизации на шаге 2

1. Попробуйте выполнить синхронизацию вручную из консоли WSUS.
2. Если синхронизация выполняется вручную, проверьте параметры запланированной синхронизации.

Шаг 3. Компьютер WSUS получает сведения о продукте и классификации из Майкрософт Update и всех подписанных метаданных

После получения сведений о продуктах и классификации WSUS и всех подписанных метаданных из Майкрософт Update синхронизация WSUS завершится.

Проблемы с установкой, заменой или обнаружением определенных обновлений

Проблемы с развертыванием, возникающие при определенных обновлениях, могут быть разбиты на указанные ниже области. При начале устранения неполадок рассмотрите следующие компоненты, связанные с этими областями.

Проблемы с установкой

Что такое установщик (CBS, MSI, другие)?

CBS

Для обновлений, применимых к Windows Vista и более поздним версиям, CBS используется для обработки установки.

1. Соберите журнал CBS (%Windir%\Logs\Cbs\Cbs.log) и выполните начальную проверку, чтобы получить представление о причине сбоя. Устранение проблем, связанных с установкой, с помощью журналов CBS выходит за рамки этого руководства. Дополнительные сведения см. в разделе Исправление ошибок повреждения Windows с помощью инструмента DISM или средства готовности к обновлению системы.
2. Установлено ли обновление успешно, когда пользователь вошёл в систему? Если да, он завершается ошибкой только в том случае, если он установлен в контексте системы? В этом случае сосредоточьтесь на устранении неполадок, связанных с ошибкой установки вручную в контексте системы.

MSI (установщик Windows)

Для обновления программного обеспечения, отличного от Windows, MSI используется для обработки установки.

1. Соберите и просмотрите журналы MSI по умолчанию для обновления. Ознакомьтесь со связанной статьей базы знаний по обновлению для всех известных проблем или часто задаваемых вопросов.

2. Включите ведение журнала установщика Windows и воспроизведите сбой.

   При просмотре полученных журналов проверьте возвращаемое значение 3 в журнале и строки, предшествующие этой записи, чтобы получить представление о сбое.

3. Проверьте, не удалось ли установить то же обновление вручную в контексте локальной системы. Для этого используйте те же параметры установки, которые были использованы во время неудачного развертывания обновления программного обеспечения.

   При сбое проверьте установку, войдя в систему под пользователем с теми же параметрами установки. Проверьте, возникла ли проблема с установкой в локальной системе. Если это работает, вы можете сосредоточиться на проблеме, чтобы правильно установить обновление с помощью контекста локальной системы. Для обновления может потребоваться проверка рекомендаций по административному развертыванию в базе знаний или в сети.

Проблемы замены

Попытайтесь изолировать проблему, связанную с заменой, с помощью следующих вопросов:

1. Вопросы об управлении истечением срока действия обновления Configuration Manager см. в разделе Supersedence rules.
2. Если обновление было помечено Configuration Manager как истекшее, Майкрософт рекомендует развернуть последнее обновление, заменяющее его. Если вам по-прежнему нужно развернуть обновления с истекшим сроком действия, их можно развернуть вне развертывания обновлений программного обеспечения с помощью распространения программного обеспечения или управления приложениями.
3. Для вопросов, связанных с логикой замещения обновления, сначала ознакомьтесь со статьей базы знаний (KB) об обновлении, чтобы получить дополнительные сведения. Вы также можете просмотреть замены в каталоге обновлений Майкрософт, консоли WSUS или консоли Configuration Manager.

Проблемы с обнаружением

Определение состояния соответствия для каждого обновления на клиенте

1. Ознакомьтесь со статьей об обновлении базы знаний о известных проблемах с обновлением.
2. Выполните действие Цикл сканирования обновлений программного обеспечения на клиенте Configuration Manager.
3. Просмотрите UpdatesStore.log и WindowsUpdate.log.

Устранение неполадок при применении обновлений

1. Проверьте, не пропущены ли какие-либо предварительные условия, используя статью базы знаний, касающуюся обновления. Например, требует ли обновление, чтобы приложение или ОС были на определенном уровне пакета обновления?
2. Убедитесь, что уникальный идентификатор рассматриваемого обновления соответствует развернутому. Например, обновление является 32-разрядным, но предназначено для 64-разрядного хоста?

Дополнительная информация

Дополнительные сведения о настройке обновлений программного обеспечения в Configuration Manager см. в следующих статьях:

• План для обновлений программного обеспечения в Configuration Manager
• Настройка точки обновления программного обеспечения для использования кластера балансировки нагрузки сети (NLB)
• Как включить проверку отзыва сертификатов для обновлений программного обеспечения

Вы также можете опубликовать вопрос на форуме поддержки Configuration Manager для обеспечения безопасности, обновлений и соответствия требованиям here.

Посетите блог our для всех последних новостей, сведений и технических советов по Configuration Manager.