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

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

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

Определение области проблемы

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

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

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

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

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

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

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

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

Шаг 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 Messaging отправляет сообщение о запросе расположения в точку управления. В 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.
    

    Проверяются и задаются следующие разделы реестра:

    Подраздел реестра	Value name	Тип	Data
    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

Проблемы	Что требуется проверить
ScanAgent.log отображается отсутствие политики, доступной для источника обновлений, отсутствие WUAHandler.log или текущее действие в WUAHandler.log	Установите флажок Включить обновления программного обеспечения на клиентах .
Агент сканирования или службы определения местоположения не получают расположение сервера WSUS	Установлена ли роль точки обновления программного обеспечения (SUP) для сайта? В противном случае установите и настройте точку обновления программного обеспечения и отслеживайте ход выполнения SUPSetup.log. Дополнительные сведения см. в статье Установка и настройка точки обновления программного обеспечения. Если установлена роль SUP, настроена ли она и синхронизирована? Проверьте WCM.log, WSUSCtrl.log и WSyncMgr.log на наличие ошибок. select * from WSUSServerLocations select * from Update_SyncStatus
Клиент получает расположение WSUS, но не может настроить разделы реестра WSUS.	Отвечает ли групповая политика обновление в течение 2 минут времени ожидания на WUAHandler.log? Если да, означает ли WUAHandler параметры групповой политики были перезаписаны более высоким центром (контроллером домена)? Дополнительные сведения см. в разделе групповая политика переопределяет правильные сведения о конфигурации WSUS.

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

Шаг 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.

Совет

Просмотрите WUAHandler.log после проверки обновлений программного обеспечения, чтобы узнать, появились ли новые записи. Если новых записей не возникает, это означает, что точка управления не возвращает sup.

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

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

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

Сведения об устранении таких проблем см. в статье Сбои сканирования из-за отсутствующих или поврежденных компонентов.

Существует известная проблема, из-за чего 32-разрядная версия Windows 7 ConfigMgr клиента 2012 R2, запрашивающего проверку обновлений, не возвращает результаты проверки в 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, сначала просмотрите журналы служб IIS на компьютере WSUS, чтобы убедиться, что ошибки действительно возвращаются из WSUS. Если компьютер WSUS не возвращает ошибку, скорее всего, проблема связана с промежуточным брандмауэром или прокси-сервером.

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

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

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

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

     Примечание.

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

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

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

     Параметры групповой политики были перезаписаны более высоким центром (контроллером домена) на сервер и политику ENABLED.<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-адресов завершается ошибкой, возможны следующие причины:

     • Проблемы с разрешением имен в клиенте. Убедитесь, что вы можете разрешить полное доменное имя компьютера 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 откройте диспетчер служб IIS.
       2. Разверните узел Сайты, щелкните правой кнопкой мыши веб-сайт компьютера WSUS и выберите команду Изменить привязки.
       3. В диалоговом окне Привязки сайта значения портов HTTP и HTTPS отображаются в столбце Порт .
       4. На сервере WSUS откройте диспетчер служб IIS.
       5. Разверните узел Веб-сайты, щелкните правой кнопкой мыши веб-сайт компьютера WSUS и выберите пункт Свойства.
       6. Перейдите на вкладку Веб-сайт . Параметр HTTP-порта отображается в tcp-порте , а параметр порта HTTPS отображается в ssl-порте.
       7. В консоли Configuration Manager перейдите в раздел Администрирование> серверовконфигурации> сайтаи ролей системы сайта, а затем щелкните < правой панели 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. Таким образом, ошибка в WUAHandler будет той же ошибкой, что и сам агент клиентский компонент Центра обновления Windows. Дополнительные сведения об ошибке можно найти в 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

Совет

Для каждого обновления создается или обновляется экземпляр CCM_UpdateStatus класса и сохраняется текущее состояние обновления. Класс CCM_UpdateStatus находится в ROOT\CCM\SoftwareUpdates\UpdatesStore пространстве имен.

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

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

Как упоминалось ранее в этом руководстве, при устранении неполадок сканирования проверка файлы WUAHandler.log и WindowsUpdate.log. WUAHandler просто сообщает, что сообщил агент клиентский компонент Центра обновления Windows. Таким образом, ошибка в WUAHandler будет той же ошибкой, что и сам агент клиентский компонент Центра обновления Windows. Дополнительные сведения об ошибке можно найти в 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 с Центром обновления Майкрософт

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

Шаг 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 (службы Обновления в WSUS 3.x; СЛУЖБА WSUSService в Windows Server 2012 и более поздних версиях) находится в остановленном состоянии.

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

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

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

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

Шаг 2. Wsus создает подключение к Центру обновления Майкрософт (MU)

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

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

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

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

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

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

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

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

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

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

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

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

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

Области	Установка	Замены	Обнаружение
Компоненты	АВП Установщик обновлений (обслуживание на основе компонентов (CBS), MSI) CCMExec	Обновление метаданных	АВП Обновление метаданных Установщик обновлений (CBS, MSI)

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

Что такое установщик (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, см. в разделе Правила замены.
2. Если срок действия обновления истек Configuration Manager, корпорация Майкрософт рекомендует развернуть последнее заменяющее обновление. Если вам по-прежнему нужно развернуть обновления с истекшим сроком действия, их можно развернуть за пределами развертывания обновлений программного обеспечения путем распространения программного обеспечения или управления приложениями.
3. Для вопросов, связанных с логикой замены обновления, сначала ознакомьтесь со статьей базы знаний для обновления, чтобы получить дополнительные сведения. Вы также можете просмотреть замены в каталоге Центра обновления Майкрософт, консоли WSUS или консоли Configuration Manager.

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

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

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

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

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

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

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

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

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

Посетите наш блог, чтобы получить все последние новости, информацию и технические советы по Configuration Manager.