Отстраняване на неизправности в диспечера на конфигуриране на управлението на софтуерни актуализации


Домашните потребители: тази статия е предназначена само за агенти за техническа поддръжка и ИТ специалисти. Ако търсите помощ с проблем, моля Попитайте Общността на Microsoft.

Какво прави това ръководство?

Това ръководство ви помага да отстранявате управление процеса на актуализация на софтуера в Microsoft System Center Configuration Manager, включително клиентски софтуер за сканиране на актуализация, синхронизиране и откриване на определени актуализации.

Информацията в това ръководство се отнася за System Center 2012 Configuration Manager (ConfigMgr 2012), System Center 2012 R2 Configuration Manager (ConfigMgr 2012 R2) и всички версии на Configuration Manager в текущата папка.

Кой е?

Това ръководство е за ИТ професионалисти, които трябва да разберете, диагностициране и отстраняване на неизправности в процеса на управлението на софтуерни актуализации в Microsoft System Center Configuration Manager.

Как работи?Той е разделен на три основни раздела:

  • Актуализация на софтуера на клиента сканиране
  • WSUS за синхронизиране на Microsoft Update
  • Инсталиране, supersedence или откриване на проблеми с конкретни актуализации

Това ръководство се предполага, че точка за актуализиране на софтуер вече е инсталиран и конфигуриран. За повече информация относно конфигурирането на софтуерни актуализации в Configuration Manager вижте следните статии:

Конфигуриране на софтуерни актуализации в Configuration Manager

Очакваното време за завършване:

30-45 минути.

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

  1. Какво конкретно не работи и какво е целта ви?
  2. Какво представлява и/или модела на проблема? Проблемът все още се случва?
  3. Как да се знае, че съществува проблем?
  4. Това някога е работил? Ако е така, когато го спрат да? Беше нещо в средата на точно преди той спря да работи?
  5. Какъв процент от клиентите са засегнати?
  6. Какво е направено вече (ако всичко) да се опитате да го поправите?
  7. Знаете точната версия на клиента и версията на сървъра. Тези системи са актуализирани?
  8. Какво да засегнати клиенти имат общо (например същата подмрежа, рекламен сайт, домейн, физическо местоположение, сайт, сайта система и т.н.)?

Знае и разбиране на отговорите на тези въпроси ще ви постави в най-добрия път за бързо и лесно решение каквото и проблема, който имате.

Ако знаете конкретна област в процеса на управлението на софтуерни актуализации, които искате да отстраните, изберете по-долу. Ако не е сигурен, започнете с клиентски софтуер за сканиране на актуализация и ние ще ви преведе през целия процес от начало до край.

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

  1. Какво конкретно не работи и какво е целта ви?
  2. Какво представлява и/или модела на проблема? Проблемът все още се случва?
  3. Как да се знае, че съществува проблем?
  4. Това някога е работил? Ако е така, когато го спрат да? Беше нещо в средата на точно преди той спря да работи?
  5. Какъв процент от клиентите са засегнати?
  6. Какво е направено вече (ако всичко) да се опитате да го поправите?
  7. Знаете точната версия на клиента и версията на сървъра. Тези системи са актуализирани?
  8. Какво да засегнати клиенти имат общо (например същата подмрежа, рекламен сайт, домейн, физическо местоположение, сайт, сайта система и т.н.)?

Знае и разбиране на отговорите на тези въпроси ще ви постави в най-добрия път за бързо и лесно решение каквото и проблема, който имате.

Ако знаете конкретна област в процеса на управлението на софтуерни актуализации, които искате да отстраните, изберете по-долу. Ако не е сигурен, започнете с клиентски софтуер за сканиране на актуализация и ние ще ви преведе през целия процес от начало до край.

Процесът на клиента сканиране е посочено в следващите стъпки. Потвърдете всяка стъпка за правилно установяване къде е проблемът.

Първото нещо, което клиентът се намира WSUS сървър, който ще бъде актуализация източника за сканиране за актуализация на софтуера. Този процес е по-долу.

ScanAgent.log:

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

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 клас:

Namespace: root\CCM\ScanAgent клас: CCM_ScanJobInstance

LocationServices.log:

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}   

CcmMessaging.log:

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

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 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'  

 

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>  

 

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'  

 

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}  

 

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  

 

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 changeWaiting for 30 secs for policy to take effect on WU Agent.  Added Update Source ({UpdateSource}) of content type: 2  

 

През това време агент вижда 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\AUUseWUServer (това трябва да бъде Dword стойност 1)
  • HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate WUServer (това трябва да бъде низ стойност, която ще бъде пълен WSUS сървър включително порт)
  • WUStatusServer (това трябва да бъде низ стойност, която ще бъде пълен WSUS сървър включително порт)

 

Пример:

Ключ име: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Policies\Microsoft\Windows\WindowsUpdate

Име на стойността: WUServer

Тип: REG_SZ

Данни: http://PS1Site.Contoso.com:8530

 

Име на стойността: WUStatusServer

Тип: REG_SZ

Данни: 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.  

 

ScanAgent.log:

ScanJob({JobID}): Raised UpdateSource ({UpdateSource}) state message successfully. StateId = 2 ScanJob({JobID}): CScanJob::Execute - successfully requested Scan, ScanType=1
  1. Когато клиент на Configuration Manager трябва да обработи софтуерна актуализация на сканиране, сканиране агент създава сканиране искане въз основа на наличните, както е отбелязано тук:
  2. Сканиране агент сега изпраща WSUS място искане до услугите, както е отбелязано тук:
  3. Услугите създава искане за местоположение и го изпраща до мястото за управление. ИД на пакет на WSUS местоположение заявка е актуализация източник ИД
  4. CCM съобщения изпраща съобщение местоположение заявка до мястото за управление:
  5. Управление на анализира тази заявка и извиква MP_GetWSUSServerLocations съхраняват процедура да WSUS места от база данни:
  6. След получаване на резултатите от съхранената процедура, точка на управление изпраща отговор на клиента:
  7. CCM съобщения получава отговор и го изпраща обратно към услугите за местоположение:
  8. Услуги синтактичен анализ на отговор и изпраща местоположението сканиране на агент:
  9. Агент за сканиране сега е правилата и местоположение на източника актуализация с подходящата версия съдържание.
  10. Сканиране на агент уведомява WUAHandler да добавите актуализацията източник. WUAHandler добавя източникът на актуализация на системния регистър и започва обновяване на груповите правила (ако клиентът е в домейн) да се види дали груповите замества актуализация на сървъра, ние току-що добавихте.
  11. След успешно се добавя updatesource, сканирайте агент поставя съобщение за състояние и initiatesthe сканиране:

Отстраняване на неизправности

Симптомите на регистрационния файл Какво да проверите
ScanAgent.log показва правила няма налични за актуализация източник и WUAHandler.log не съществува или не текущата дейност в WUAHandler.log Проверете Enable софтуерни актуализации на клиенти за настройка. За повече информация вижте следния технически документ: За настройки на клиент в Configuration Manager
ScanAgent/LocationServices не WSUS сървъра местоположение за получаване Инсталиран ли е софтуерна актуализация точка (SUP) роля на сайта? Ако не, инсталиране и конфигуриране на точка за актуализация на софтуера и наблюдение SUPSetup.log за напредъка. Вижте връзката за повече информация: Инсталиране и конфигуриране на точка за актуализация на софтуер Ако инсталирането на SUP роля е конфигуриран и синхронизиране? Проверете WCM.log, WSUSCtrl.log и WSyncMgr.log за грешки. select * от WSUSServerLocations Изберете * от Update_SyncStatus
Клиента получава WSUS местоположение, но не може да конфигурирате WSUS ключовете от системния регистър Е обновяване на груповите правила отговори в рамките на 2 минути изчакване на WUAHandler.log? Ако е така, WUAHandler означават "настройките на груповите правила са заместени от по-висок орган (домейнов контролер)"? Проверете за GPO се намира в домейна.

 

 

 

След като клиентът е разпознат и задайте WSUS сървър, който ще бъде актуализация източника за софтуерна актуализация на сканиране, сканиране агент след поиска сканиране от WUAHandler, която използва API на Windows Update Agent, за да поискате софтуер сканира актуализация от Windows Update Agent. Сканирането може да доведе от график или ръчно софтуерна актуализация сканиране, актуализиран софтуер график или ръчно разполагане преоценка или от разгръщане, се активира, което предизвиква оценка.

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.

Отстраняване на неизправности

Някои проблеми със софтуерна актуализация сканиране могат да бъдат причинени от липсващи или повредени файлове и ключове на системния регистър, или компонент регистрация проблеми. Това са поправим чрез Windows Update за отстраняване на неизправности актуализиране на агента на Windows Update или възстановяване на хранилището на данни на агент:

Windows Update отстраняване на неизправности:

2714434 - описание на Windows Update за отстраняване на неизправности (http://support.microsoft.com/kb/2714434)

Актуализиране на агента на Windows Update:

949104 - как да актуализирате на агента на Windows Update до най-новата версия (http://support.microsoft.com/kb/949104)

Ако клиентът се изпълнява по-стара версия на Windows Update Agent, имайте предвид, че е известен проблем при 32-битов Windows 7 ConfigMgr 2012 R2 клиент иска актуализация сканиране не може да върне резултати от сканиране Диспечер на конфигурация. Това води до клиента неправилно съответствие състоянието и актуализациите не се инсталират при Configuration Manager изисква актуализация цикъл. Обаче ако използвате Windows Update контролния панел, актуализациите ще обикновено инсталира добре. Ако имате този проблем, трябва да видите съобщение, подобно на следното в WindowsUpdate.log:

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

По своята същност това е проблем за разпределение на памет, така 64-битов Windows 7 компютри няма да видите тази грешка от своите адресно пространство е ефективно неограничен. Те обаче ще имат висок памет и голямо използване на CPU, вероятно засяга изпълнението. Забележка Тази x86 клиенти също ще показват голямо използване на паметта (обикновено около 1.2 до 1.4 ГБ).

За повече информация относно този проблем вижте следната статия:

Поддръжка съвет: ConfigMgr 2012 актуализация сканиране е неуспешно и причинява неправилно съответствие състояние

За щастие има актуална корекция за проблема тук:

3050265 - Windows Update клиент за Windows 7: юни 2015 (https://support.microsoft.com/en-us/kb/3050265)

Възстановяване на хранилището на данни на агент:

За да възстановите Windows Update Agent хранилището за данни, изпълнете следните стъпки:

  1. Спрете услугата Windows Update стартирайки net stop wuauserv от командния ред.
  2. Преименувайте папката C:\Windows\SoftwareDistribution на C:\Windows\SoftwareDistribution.old.
  3. Стартирайте услугата Windows Update, като изпълнява net start wuauserv от командния ред.
  4. Иницииране на софтуерна актуализация сканиране цикъл.

Обобщена информация

Обобщава, при отстраняване на неизправности на сканиране, трябва да търсите в регистрационните файлове са WUAHandler.log и WindowsUpdate.log. Тъй като WUAHandler просто доклади какво агент съобщи, грешка в WUAHandler ще бъде същата грешка, че е от Windows Update Agent себе си, затова повече информация за грешката може да се намери в WindowsUpdate.log. За да разберете как да се чете WindowsUpdate.log, вижте следната статия от базата знания:

902093 - как да прочетете файла Windowsupdate.log (https://support.microsoft.com/en-us/kb/902093)

Най-добрият източник на информация ще дойдат от регистрационните файлове и кодове на грешки в тях. За справка можете да намерите пълния списък на кодове на грешки на Windows Update тук:

938205 - Windows Update грешка код списък (http://support.microsoft.com/kb/938205)

 

След като иска, Windows Update Agent (WUA) започва сканирането му конфигуриран WSUS сървър.

Агент стартира сканиране след получаване на заявка от клиент на Configuration Manager (CcmExec). Ако тези стойности в системния регистър са зададени правилно е валиден SUP за сайта чрез правила на локалния компютър WSUS, можете да видите 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.asmxAgent ** 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}  

 

WindowsUpdate.log:

 

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] 

Отстраняване на неизправности

По време на сканиране агент трябва да комуникира с ClientWebService и SimpleAuthWebService виртуални директории на WSUS компютъра за сканиране. Ако клиентът не може да комуникира с компютъра WSUS, няма сканиране. Това може да се случи по редица причини, включително

  • Проблеми, свързани с прокси сървър
  • Грешки на активността на HTTP
  • Грешки при удостоверяване
  • Проблеми със сертификата

Ще разгледаме всеки един от тези по-долу.

Проблеми, свързани с прокси сървър

Агент използва WinHTTP сканиране за актуализации. Когато има прокси сървър между клиента и WSUS компютъра, настройките на прокси сървъра трябва да бъде конфигуриран правилно на клиентите да могат да комуникират с помощта на FQDN WSUS. При проблеми с прокси сървъра WindowsUpdate.log може да отчете грешка от следния вид:

0x80244021 or HTTP Error 502 - Bad gateway0x8024401B or HTTP Error 407 - Proxy Authentication Required0x80240030 - The format of the proxy list was invalid0x8024402C - The proxy server or target server name cannot be resolved

В повечето случаи можете да заобиколите прокси сървъра за локални адреси, тъй като WSUS компютъра вероятно се намира в интранет все пак. Обаче ако клиентът е в интернет, трябва да се уверите, че прокси сървърът е конфигуриран да позволява това съобщение. Можете да изпълните следните команди, за да видите настройките на WinHTTP прокси сървъра:

  • В Windows XP: proxycfg.exe
  • В Windows Vista или по-горе: netsh winhttp show proxy

Въпреки че настройките за прокси сървър, конфигурирани в Internet Explorer са част от настройките за прокси сървър на WinINET, WinHTTP прокси настройките не са непременно същите като прокси настройките, конфигурирани в Internet Explorer. Ако настройките на прокси сървъра са зададени правилно в Internet Explorer, можете да импортирате конфигурацията на прокси сървъра от IE да се използва като настройките на WinHTTP прокси. За да импортирате конфигурация на прокси сървъра от Internet Explorer, изпълнете следната команда:

  • В Windows XP: proxycfg.exe -u
  • В Windows Vista и по-горе: netsh winhttp прокси източник за импортиране = ie

За повече информация вижте следното:

900935 - как клиентът на Windows Update определя кой прокси сървър да се използва за свързване с уеб сайта Windows Update

934864 - Microsoft DNS и WINS използване за WPAD регистрация

DNS и DHCP поддръжка за уеб прокси сървър и Firewall Client Autodiscovery: https://technet.microsoft.com/en-us/library/cc302584.aspx

Активността на HTTP грешки

За отстраняване на грешки на активността на HTTP, първо прегледайте регистрационните файлове на IIS на WSUS компютъра да се уверите, че грешките действително се връщат от WSUS. Ако компютърът WSUS не връща грешка, вероятно проблемът е с междинна защитна стена или прокси сървър.

Ако WSUS компютърът се връща грешка, Проверете свързването с WSUS компютъра. Това са стъпките:

За да потвърдите, че клиентът се свързва с правилния WSUS сървър, намерете URL адреса на WSUS компютъра от Windows Update Agent клиент. Това може да се намери чрез проверка на ключа на системния регистър HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate или разглеждане на файла WindowsUpdate.log .

Често срещани причини, които WSUS задача е неправилна включват групови правила конфликти или добавяне на SUP вторичния сайт след инсталиране на първоначалния клиент.

Забележка: Active Directory групови правила може да замени правилата на локален WSUS

Функцията за софтуерни актуализации автоматично конфигурира настройка на локални групови правила за клиент на Configuration Manager, така че е конфигуриран с местоположение на източника на точка за актуализиране на софтуера и номера на порта. Име на сървър и порт номер се изисква за клиента, за да намерите точка за актуализиране на софтуера.

Ако настройката на правилата за групи на Active Directory е приложена към компютъра за инсталиране на клиент на точка за актуализиране на софтуера, това отменя настройката на локални групови правила. Поради това ако стойността на настройката, която се определя в правилата на групата AD е различен от този, който се намира от Диспечер на конфигурация за сканирането няма на клиента защото не може да намери правилния WSUS компютър. В този случай WUAHandler.log ще се появи следното:

Group policy settings were overwritten by a higher authority (Domain Controller) to: Server http://server and Policy ENABLED 

Точка за актуализиране на софтуер за клиентски инсталация и софтуерни актуализации трябва да бъдат едни и същи сървър и трябва да бъде зададен в настройката на Active Directory груповите правилното име формат и порт информация. Например това ще бъде http://server1.contoso.com:80 ако точка за актуализиране на софтуера е с помощта на сайта по подразбиране.

Ако приемем URL адреса на сървъра е правилна, достъп до сървъра, използвайки подобен на следния URL за проверка на връзката между клиента и WSUS компютъра:

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

За да проверите whetherthe клиентски достъп до виртуалната директория ClientWebService, опитайте да влезете в aURL, подобно на това:

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

За да проверите дали клиентът може да достъп до SimpleAuthWebService, опитайте да отворите URL, подобно на това:

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

Ако някоя от тях не успее, някои от възможните причини са:

Грешки тук може да се дължи порт конфигурационни проблеми, така че е добре да се уверите, че настройките на порта са правилни. WSUS може да бъде конфигуриран да използва някой от следните портове: 80 и 443 8530, 8531.

За клиенти, за да комуникира с компютъра WSUS съответните портове бива защитната стена на компютъра WSUS. Настройките на порта са конфигурирани при точка за актуализиране на софтуер сайт система се създава. Тези настройки на порта трябва да е същото като настройките на порта, използван от уеб сайта на WSUS или WSUS синхронизиращ диспечер няма да може да се свържете към WSUS работи на точка за актуализиране на софтуер да поиска синхронизиране. Следните процедури информация как да проверите настройките на порта, използван от WSUS и точка за актуализиране на софтуера.

Проверете настройките за порта WSUS, използвани в IIS 7.0 и по-горе

Проверете настройките на WSUS порта в IIS 6.0

Конфигуриране на портове за точка за актуализиране на софтуер

Проверете връзката към порт

За да проверите порт връзка от клиента, изпълнете следната команда:

Telnet SUPSERVER. CONTOSO.COM

Например ако ни порт е 8530 ще използваме следната команда:

Telnet SUPSERVER. CONTOSO.COM 8530

Ако портът не е достъпна, telnet ще получи съобщение за грешка, подобно на следното:

Could not open connection to the host, on port <PortNumber>

 

Тази грешка показва, че защитната стена правилата не са конфигурирани да позволяват комуникация на WSUS компютъра. Имайте предвид, че тази грешка може също да предложи междинен мрежово устройство да блокира този порт. За да проверите, опитайте същия тест от клиент на същия локалната подмрежа. Ако това работи, след което това предполага, че компютрите са конфигурирани правилно, обаче маршрутизатор или защитна стена между сегменти се блокира порт и причината за неизправността.

  1. Уверете се, че клиентът използва подходящия URL
  2. Проверка на URL
    • Име на решение проблеми на клиента. Проверете дали можете да разрешите FQDN на WSUS компютъра.
    • Проблеми с конфигуриране на прокси. Вижте стъпка 1 по-горе.
    • Други мрежови проблеми.
    • Порт конфигурационни проблеми (вж. по-долу).
    • IIS наличност проблеми.
    1. WSUS компютъра отворете диспечера на интернет информационни услуги (IIS).
    2. Разгънете сайтове, щракнете с десния бутон на сайта за WSUS компютъра и щракнете върху Редактиране на свързвания.
    3. В диалоговия прозорец Свързване на сайта HTTP и HTTPS порт стойностите се показват в колоната порт .
    1. WSUS сървъра отворете диспечера на интернет информационни услуги (IIS).
    2. Разгънете уеб сайтове, щракнете с десния бутон на сайта за WSUS компютъра, след което щракнете върху свойства.
    3. Щракнете върху раздела за уеб сайта . HTTP порт настройка се показва в TCP порт и настройката на HTTPS порт се показва в SSL порт.
    1. В конзолата на конфигурационен диспечер, отидете до прозореца управление -> Сайт конфигурация -> сървъри и сайт система роли, след което щракнете върху в десния екран < SiteSystemName > .
    2. В долния панел щракнете върху Точка за актуализиране на софтуера и след това щракнете върху свойства.
    3. Отидете на раздела " Общи " и задайте/Проверете номера на порта 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, което означава "се изисква сертификат за завършване на удостоверяване на клиента." Тази грешка трябва да се случи, само ако WSUS компютър е конфигуриран да използва SSL. Като част от конфигурацията на SSL WSUS виртуални директории трябва да бъде конфигуриран да използва SSL и е настроен на "Игнорирай" клиентски сертификат. Ако уеб сайта на WSUS или някоя от тези виртуални директории са конфигурирани неправилно "Приемам" или "Изисква" клиентски сертификати, ще получите тази грешка.

Следвайте тези стъпки за отстраняване на грешки, свързани с проблеми със сертификата:

Проверете дали точка за актуализиране на софтуер е конфигуриран за SSL

  1. В конзолата на конфигурационен диспечер, отидете до прозореца управление -> Сайт конфигурация -> сървъри и сайт роли на системата, щракнете върху < SiteSystemName > в десния екран.
  2. В долния панел щракнете върху Точка за актуализиране на софтуера и след това щракнете върху свойства.
  3. В раздела Общи щракнете върху изисква SSL съобщение на WSUS сървъра.

Проверете дали WSUS компютър е конфигуриран за SSL

  1. Отворете конзолата на WSUS на точка за актуализиране на софтуера на сайта.
  2. Щракнете върху Опции в прозореца на конзолата дърво.
  3. Щракнете върху актуализацията източник и прокси сървър в контролния екран.
  4. Проверете дали е избрано Use SSL при синхронизиране на информацията за актуализиране .

Уверете се, че сертификат за удостоверяване на сървъра се добавя WSUS администриране на сайта

За да добавите сертификат за удостоверяване на сървъра на сайта за администриране на WSUS, направете следното:

  1. WSUS компютъра отворете диспечера на интернет информационни услуги (IIS).
  2. Разгънете сайтове, щракнете с десния бутон по подразбиране уеб сайтили сайт за Администриране на WSUS ако WSUS е конфигуриран да използва потребителски сайт и след това изберете Редактиране на свързвания.
  3. Щракнете върху HTTPS записа и щракнете върху Редактиране. .
  4. В диалоговия прозорец Редактиране на свързване на сайта изберете сертификат за Удостоверяване на сървъра и след това щракнете върху OK.
  5. Щракнете върху OK в диалоговия прозорец Редактиране на сайта за свързване и след това щракнете върху Затвори.
  6. Затворете Internet Information Services (IIS) Manager.

Важно Уверете се, че FQDN, зададен в свойствата на системата на сайта съответства FQDN, указан в сертификата. Ако точка за актуализиране на софтуера приема връзки от интранет, името на субекта или алтернативно име на темата трябва да съдържа интранет FQDN. Когато точка за актуализиране на софтуера приема клиентски връзки от интернет само, сертификатът все още съдържа FQDN интернет и интранет FQDN защото WCM и WSyncMgr все още използвате интранет FQDN за свързване към точка за актуализиране на софтуера. Ако точка за актуализиране на софтуера приема връзки от интернет и интранет, FQDN интернет и интранет FQDN трябва да бъде зададена чрез амперсанд (&) символ разделител между две имена.

Проверете дали SSL е конфигурирано WSUS компютър

Следната връзка се отнася за System Center Configuration Manager 2007, но същите стъпки могат да се използват за конфигуриране на SSL на WSUS Configuration Manager 2012:

Как да конфигурирате уеб сайта на WSUS да използва SSL

Важно Не можете да конфигурирате целия сайт WSUS изисква SSL, тъй като тогава всички трафик към сайта на WSUS би трябвало да е шифрован. WSUS шифрова актуализация само метаданни. Ако компютърът се опитва да извлечете файловете за актуализация на HTTPS порт, няма прехвърляне.

WUAHandler получава резултатите от агента на Windows Update и маркира като пълно сканиране.

WUAHandler.log:

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

Отстраняване на неизправности

Проблеми тук трябва да бъдат отстранени по същия начин като сканирането грешки в предишната стъпка.

Както споменахме по-рано в това ръководство, при отстраняване на неизправности на сканиране, трябва да търсите в регистрационните файлове са WUAHandler.log и WindowsUpdate.log. Тъй като WUAHandler просто доклади какво агент съобщи, грешка в WUAHandler ще бъде същата грешка, че е от Windows Update Agent, затова допълнителна информация относно грешката е намерена в WindowsUpdate.log. За да разберете как да се чете WindowsUpdate.log, вижте следната статия от базата знания:

902093 - как да прочетете файла Windowsupdate.log

Общо казано има много причини защо може да бъде неуспешно сканиране на актуализация на софтуера. Това може да се дължи на една от посочените по-горе проблеми, или тя просто може да се комуникацията или защитна стена въпрос между клиента и точка за актуализиране на софтуера на компютъра. Най-добрият източник на информация ще дойдат от регистрационните файлове и кодове на грешки в тях. За справка можете да намерите пълния списък на кодове на грешки на Windows Update тук:

938205 - Windows Update грешка код списък

WUAHandler след анализира резултатите, което включва състоянието на приложение за всяка актуализация. Като част от този процес изместена актуализации се подрязват. Освен това състоянието на приложимост се проверява за всички актуализации, които подравняване на критерии, предоставени от CCMExec на агента на Windows Update. Важното за разбиране тук е, че трябва да видите приложимост резултати за актуализации, дали тези актуализации са в разполагане или не.

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. 

Отстраняване на неизправности

Проблеми тук трябва да бъдат отстранени по същия начин като сканирането грешки в предишната стъпка.

Както споменахме по-рано в това ръководство, при отстраняване на неизправности на сканиране, трябва да търсите в регистрационните файлове са WUAHandler.log и WindowsUpdate.log. Тъй като WUAHandler просто доклади какво агент съобщи, грешка в WUAHandler ще бъде същата грешка, че е от Windows Update Agent, затова допълнителна информация относно грешката е намерена в WindowsUpdate.log. За да разберете как да се чете WindowsUpdate.log, вижте следната статия от базата знания:

902093 - как да прочетете файла Windowsupdate.log

Общо казано има много причини защо може да бъде неуспешно сканиране на актуализация на софтуера. Това може да се дължи на една от посочените по-горе проблеми, или тя просто може да се комуникацията или защитна стена въпрос между клиента и точка за актуализиране на софтуера на компютъра. Най-добрият източник на информация ще дойдат от регистрационните файлове и кодове на грешки в тях. За справка можете да намерите пълния списък на кодове на грешки на Windows Update тук:

938205 - Windows Update грешка код списък

Актуализацията се съхранява записва състоянието и поставя състояние съобщение за всяка актуализация в WMI.

След като сканирането резултатите са налице, тези резултати се съхраняват в хранилището на актуализации. Актуализацията се съхранява записва текущото състояние на всяка актуализация и създава състояние съобщение за всяка актуализация. Тези съобщения за състоянието се изпращат на сървъра на сайта в групово в края на съобщението доклади цикъл (който е минути по подразбиране). Обърнете внимание, че изпращаме само състояние съобщение при следните обстоятелства:

  • Предишно състояние съобщение не е изпратено за актуализация (записа в регистрационния файл: не е съобщено, създаване на нов екземпляр)
  • Приложимост на състоянието за актуализация е променило след последното съобщение за състояние е изпратен

UpdateStore.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 показва състояние messaged се записва състояние ID 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 имена.

Отстраняване на неизправности

Проблеми тук трябва да бъдат отстранени по същия начин като сканирането грешки в предишната стъпка.

Както споменахме по-рано в това ръководство, при отстраняване на неизправности на сканиране, трябва да търсите в регистрационните файлове са WUAHandler.log и WindowsUpdate.log. Тъй като WUAHandler просто доклади какво агент съобщи, грешка в WUAHandler ще бъде същата грешка, че е от Windows Update Agent, затова допълнителна информация относно грешката е намерена в WindowsUpdate.log. За да разберете как да се чете WindowsUpdate.log, вижте следната статия от базата знания:

902093 - как да прочетете файла Windowsupdate.log

Общо казано има много причини защо може да бъде неуспешно сканиране на актуализация на софтуера. Това може да се дължи на една от посочените по-горе проблеми, или тя просто може да се комуникацията или защитна стена въпрос между клиента и точка за актуализиране на софтуера на компютъра. Най-добрият източник на информация ще дойдат от регистрационните файлове и кодове на грешки в тях. За справка можете да намерите пълния списък на кодове на грешки на Windows Update тук:

938205 - Windows Update грешка код списък

Когато WUAHandler успешно получи резултатите от агента на Windows Update, това маркира като пълно сканиране и регистрира следното:

WUAHandler.log:

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

Отстраняване на неизправности

Проблеми тук трябва да бъдат отстранени по същия начин като сканирането грешки в предишната стъпка, въпреки че повреди на този етап най-вероятно ще се появи във файла WindowsUpdate.log специално. За да разберете как да се чете WindowsUpdate.log, вижте следната статия от базата знания:

902093 - как да прочетете файла Windowsupdate.log

Общо казано има много причини защо може да бъде неуспешно сканиране на актуализация на софтуера. Това може да се дължи на една от посочените по-горе проблеми, или тя просто може да се комуникацията или защитна стена въпрос между клиента и точка за актуализиране на софтуера на компютъра. Най-добрият източник на информация ще дойдат от регистрационните файлове и кодове на грешки в тях. За справка можете да намерите пълния списък на кодове на грешки на Windows Update тук:

938205 - Windows Update грешка код списък

WSUS синхронизиране с Microsoft Update е посочено в следващите стъпки. Потвърдете всяка стъпка за правилно установяване къде е проблемът.

Когато се задейства синхронизацията, очакваме да видите следното в WSUS сървър SoftwareDistribution.log:

РЪЧНО:

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

ПЛАНИРАНО:

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

Отстраняване на неизправности

Ръчна синхронизация

  1. Уверете се, че theWSUS услугата е стартирана.  Ако виждате Марина ръчна синхронизация започва, но тя остава 0 %, това обикновено се дължи WSUS услугата ("Услуги за актуализиране" на WSUS 3.x; "WSUSService" в Windows Server 2012 +) е в състояние на спиране.
  2. Възстановяване на кеша на WSUS конзола MMC като изпълните следното:

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

Планирано синхронизиране

  1. Опитайте ръчна синхронизация от в конзолата на WSUS.
  2. Ако ръчна синхронизация работи добре, проверете настройките на планирана синхронизация.

След стартиране на синхронизиране на WSUS сървъра се опитва да направи HTTP връзка чрез WinHTTP. Имайте предвид следните фактори при отстраняване на връзката:

WSUS < = winhttp = > мрежови обекти <> = интернет

Обект на мрежата (прокси, защитна стена, филтър за защита и др.) съществува между WSUS хост компютъра и интернет?

Ако прокси съществува и WSUS сървъра е необходимо да използвате прокси, е прокси конфигуриран в настройките на правилното WSUS?

Отстраняване на неизправности

Ръчна синхронизация

  1. Уверете се, че се изпълнява услугата на WSUS. Ако видите ръчна синхронизация започва, но тя остава 0 %, това обикновено се дължи WSUS услугата ("Услуги за актуализиране" на WSUS 3.x; "WSUS услуга" в Windows Server 2012 +) е в състояние на спиране.
  2. Възстановяване на кеша на WSUS конзола MMC като изпълните следното:
    1. Затворете конзолата на WSUS
    2. Спрете услугата на WSUS ("Услуги за актуализиране" на WSUS 3.x; "WSUS услугата" на Windows Server 2012 +)
    3. Намерете %appdata%\Microsoft\mmc
    4. Преименувайте "wsus" да "wsus_bak"
    5. Стартирайте услугата WSUS
    6. Отворете конзолата на WSUS и опитайте друга ръчна синхронизация

Планирано синхронизиране

  1. Опитайте ръчна синхронизация от в конзолата на WSUS
  2. Ако ръчна синхронизация работи добре, проверете настройките на планирана синхронизация.

След като WSUS получава продукта и информация за класификацията и всички записания метаданни от Microsoft Update, WSUS синхронизация завърши.

Разполагане проблеми, които възникват при определени актуализации може да бъде разделен на зони по-долу. Когато започнете отстраняване, имайте предвид следните компоненти, свързани с тези области.

Области ->ИнсталиранеSupersedenceОткриване
Компоненти ->WUA актуализация Installer (CBS, MSI) CCMExecАктуализиране на метаданниWUA Update за инсталиране на актуализация на метаданни (CBS, MSI)

Какво представлява installer (CBS, MSI, други)?

CBS (компонент на обслужване):

За актуализации за операционната система Windows (Windows Vista текущите) CBS се използва за обработване на инсталацията.

  1. 1. събиране на регистрационния файл на CBS (% Windir%\Logs\Cbs\Cbs.log) и изпълнява първоначалния преглед печалба поглед причината за неизправността. Отстраняване на проблеми при инсталиране на чрез CBS регистри е извън обхвата на това отстраняване на неизправности, но може да помогне на следната статия от базата знания:947821 - определи Windows грешки от повреди чрез инструмента DISM или система Update готовност
  2. Актуализация инсталира успешно влезлият потребител? Ако той се инсталира успешно влезлият потребител, я само не инсталирано в рамките на системата? Ако е така, се фокусира върху ръчно инсталиране повреда в рамките на системата за отстраняване на неизправности.
MSI (Windows Installer):
За не Windows софтуерни актуализации MSI се използва за обработване на инсталацията.
  1. Съберете и прегледайте регистрите на MSI по подразбиране за актуализация. Проверете съответната KB статия за актуализацията за всички известни проблеми/често задавани въпроси.
  2. Разширяване на Windows Installer регистриране и възпроизвежда грешка. Вижте следната статия от базата знания за повече информация:223300 - как да разрешите регистрирането от Windows Installerпри преглед на регистрационните файлове на резултат, потърсете върната стойност 3 в регистъра и редовете преди този запис за поглед неуспех.
  3. Проверете дали същата актуализация не може да инсталирате ръчно в локалната система контекст на използване на ключовете на една и съща инсталация, грешка по време на разполагане на актуализация на софтуера. Ако не успее, проверете инсталацията като влезлият потребител със същия инсталационни параметри да разберете дали това е проблем с инсталирането в локалната система. Ако това работи, можете да след това се съсредоточите проблема как да се инсталира правилно актуализацията на използване на контекст на локалната система. Това може да изисква проверка за разполагане на административни указания в KB за актуализация или онлайн.

Опитайте да изолирате проблема, който се отнася до supersedence с помощта на следните въпроси:

  1. За въпроси относно това как да управлявате конфигурационен Диспечер на изтичане актуализация, прегледайте раздела "Supersedence правила" тук: https://technet.microsoft.com/en-us/library/gg712312.aspx
  2. Ако актуализация е изтекъл от Configuration Manager, Microsoft препоръчва, че се използват най-новите замества актуализацията. Ако трябва да разположите актуализации е изтекъл, те могат да бъдат разположени извън актуализация разполагане на софтуер чрез софтуер за управление на разпространение/приложение.
  3. Въпроси за supersedence логика на актуализация първи статията от базата знания за актуализация за повече информация. Можете също да прегледате supersedence в каталога на Microsoft Update, конзолата на WSUS или конзолата на конфигурационен диспечер.

Определете състоянието на съответствие на актуализация на клиента

  1. Преглед на актуализацията KB статия за известни проблеми с актуализацията.
  2. Изпълнение на действие "Софтуерни актуализации сканиране цикъл" клиент на Configuration Manager.
  3. Преглед на UpdatesStore.log и WindowsUpdate.log.

Прилагането на актуализацията за отстраняване на неизправности

  1. Проверете ако всички предпоставки липсват, с помощта на статията от БЗ за актуализация. Например тя изисква приложение или операционна система, като кръпка да бъдат специфични сервизен пакет ниво?
  2. Уверете се, че уникален актуализира ИД на съответната актуализация съпоставя какво е разположен. Например, е актуализация на въпросния x86 актуализация, но са насочени към x64 хост?

Поздравления! Управление на софтуерни актуализации процес проблема е решен.

За допълнителна информация относно начините на конфигуриране на софтуерни актуализации в Configuration Manager вижте следното:

Можете също да публикувате въпрос в нашия форум за поддръжка на Configuration Manager 2012 за сигурност, актуализации и съвместимост тук:

https://social.technet.microsoft.com/Forums/en-US/home?forum=configmanagersecurity

Посетете нашия блог за всички последни новини, информация и технически съвети за Microsoft System Center Configuration Manager:

https://blogs.technet.microsoft.com/configurationmgr