Назад | Перейти на главную страницу

Клиенты WSUS не могут получить обновления с ошибкой 80072EE2

Недавно мы реализовали WSUS для наших рабочих станций Windows (около 90). У некоторых клиентов нет проблем, в то время как другие продолжают возвращать ошибку «80072EE2» при попытке вручную проверить наличие обновлений с помощью Центра обновления Windows.

Клиенты - Win7 x64 SP1, сервер - Win2008 x86 SP2

Наши рабочие станции используют стандартный образ, поэтому разница между системами минимальна.

Процесс w3wp.exe на сервере резко загружает процессор в течение продолжительных периодов времени.

В журнале WindowsUpdate.log проблемных клиентов мы видим:

2015-12-04  11:12:33:847     968    12ac    PT    Server URL = http://server.domain.com/SimpleAuthWebService/SimpleAuth.asmx
2015-12-04  11:13:37:937     968    12ac    Misc    WARNING: Send failed with hr = 80072ee2.
2015-12-04  11:13:37:937     968    12ac    Misc    WARNING: SendRequest failed with hr = 80072ee2. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
2015-12-04  11:13:37:937     968    12ac    Misc    FATAL: SOAP/WinHttp - SendRequest: SendRequestUsingProxy failed. error 0x80072ee2
2015-12-04  11:13:37:937     968    12ac    PT    + Last proxy send request failed with hr = 0x80072EE2, HTTP status code = 0
2015-12-04  11:13:37:937     968    12ac    PT    + Caller provided credentials = No
2015-12-04  11:13:37:937     968    12ac    PT    + Impersonate flags = 0
2015-12-04  11:13:37:937     968    12ac    PT    + Possible authorization schemes used = 
2015-12-04  11:13:37:937     968    12ac    PT  WARNING: SyncUpdates failure, error = 0x80072EE2, soap client error = 5, soap error code = 0, HTTP status code = 200
2015-12-04  11:13:37:937     968    12ac    PT  WARNING: PTError: 0x80072ee2
2015-12-04  11:13:37:937     968    12ac    PT  WARNING: SyncUpdates_WithRecovery failed.: 0x80072ee2
2015-12-04  11:13:37:937     968    12ac    PT  WARNING: Sync of Updates: 0x80072ee2
2015-12-04  11:13:37:937     968    12ac    PT  WARNING: SyncServerUpdatesInternal failed: 0x80072ee2
2015-12-04  11:13:37:937     968    12ac    Agent     * WARNING: Failed to synchronize, error = 0x80072EE2
2015-12-04  11:13:37:937     968    12ac    Agent     * WARNING: Exit code = 0x80072EE2

Проверяя WSUS-сервер SoftwareDistribution.log, мы видим:

2015-12-04 16:14:36.018 UTC     Error   w3wp.18 ClientImplementation.SyncUpdat
        Syst
em.Threading.ThreadAbortException: Thread was being aborted.
   at Microsoft.UpdateServices.Internal.NativeMethods.ExtractBlobFromMemoryCab
UInt32 cbCompressed, Byte* pCompressed, UInt32& pcbUncompressed, IntPtr& ppUnc
mpressed)
   at Microsoft.UpdateServices.Internal.CabUtilities.ExpandMemoryCabToString(B
te[] src)
   at Microsoft.UpdateServices.Internal.DataAccess.ExecuteSpGetCoreUpdateXml(I
t32[] revisionIds)
   at Microsoft.UpdateServices.Internal.DataAccessCache.GetCoreUpdateXml(Int32
] revisionIds, DataAccess da, Int64 maxXmlPerRequest)
   at Microsoft.UpdateServices.Internal.ClientImplementation.GetSyncInfo(Versi
n clientProtocolVersion, DataAccess dataAccess, Hashtable stateTable, Hashtabl
 deploymentTable, Boolean haveGroupsChanged, Boolean driverSyncNeeded, Boolean
doChunking)
   at Microsoft.UpdateServices.Internal.ClientImplementation.SoftwareSync(Data
ccess dataAccess, UnencryptedCookieData cookieData, Int32[] installedNonLeafUp
ateIds, Int32[] leafUpdateIds, Boolean haveGroupsChanged, Boolean expressQuery
 Guid[] filterCategoryIds, Boolean needTwoGroupOutOfScopeUpdates)
   at Microsoft.UpdateServices.Internal.ClientImplementation.SyncUpdates(Cooki
 cookie, SyncUpdateParameters parameters)
   at Microsoft.UpdateServices.Internal.ClientImplementation.SyncUpdates(Cooki
 cookie, SyncUpdateParameters parameters)
   at Microsoft.UpdateServices.Internal.Client.SyncUpdates(Cookie cookie, Sync
pdateParameters parameters)
   at System.RuntimeMethodHandle._InvokeMethodFast(Object target, Object[] arg
ments, SignatureStruct& sig, MethodAttributes methodAttributes, RuntimeTypeHan
le typeOwner)
   at System.RuntimeMethodHandle.InvokeMethodFast(Object target, Object[] argu
ents, Signature sig, MethodAttributes methodAttributes, RuntimeTypeHandle type
wner)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invo
eAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean skipVi
ibilityChecks)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invo
eAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Web.Services.Protocols.LogicalMethodInfo.Invoke(Object target, Ob
ect[] values)
   at System.Web.Services.Protocols.WebServiceHandler.Invoke()
   at System.Web.Services.Protocols.WebServiceHandler.CoreProcessRequest()
   at System.Web.Services.Protocols.SyncSessionlessHandler.ProcessRequest(Http
ontext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpAppli
ation.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& com
letedSynchronously)
   at System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception err
r)
   at System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext c
ntext, AsyncCallback cb)
   at System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerReque
t wr, HttpContext context)
   at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntP
r managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 fl
gs)
   at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr man
gedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
   at System.Web.Hosting.UnsafeIISMethods.MgdIndicateCompletion(IntPtr pHandle
, RequestNotificationStatus& notificationStatus)
   at System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntP
r managedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 fl
gs)
   at System.Web.Hosting.PipelineRuntime.ProcessRequestNotification(IntPtr man
gedHttpContext, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)
2015-12-04 16:14:36.018 UTC     Warning w3wp.18 SoapUtilities.CreateException
Throw
Exception: actor = http://server.domain.com/ClientWebService/client.asm
, ID=9b1e3f5a-f766-4ba9-bf7e-52c7cfbe1f68, ErrorCode=InternalServerError, Mess
ge=, Client=a39b9446-c45a-4060-851d-9157a2393278

Что мы пробовали:

  1. Перезагрузка сервера
  2. Изменение автоматической проверки обновлений на период обновлений с 1 часа до 10 часов
  3. Отключение проверки AV при доступе на сервере
  4. Обновление проблемного клиента до последней версии клиента WSUS
  5. Переход вручную по URL-адресу, указанному в журнале клиента выше. (Без вопросов)

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

Недавно я столкнулся с этой конкретной проблемой с такими же ошибками в журналах, как вы видите.

Ошибки событий на скриншоте ниже привлекли меня к проблеме:

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

Перво-наперво убедитесь, что KB2720211 установлен на сервере WSUS. Это обновление безопасности для самого WU. Если какой-либо из ваших клиентов обновился непосредственно от Microsoft, у них уже будет это обновление, и они не смогут взаимодействовать с вашим сервером WSUS (проверка обновлений от Microsoft на сервере WSUS даст вам это обновление, если роль WSUS установлена).

Во-вторых, заставьте WSUS перенастроить IIS. По какой-то причине переустановка роли неправильно настроила ее. В командной строке введите следующее:

C:\Program Files\Update Services\Tools\wsusutil.exe usecustomwebsite false

Это изменит конфигурацию сайта WSUS IIS для работы с портом 80. Затем введите:

C:\Program Files\Update Services\Tools\wsusutil.exe usecustomwebsite true

Это изменит конфигурацию WSUS обратно на порт 8530.

Если вы уже были на 80-м порту, сделайте этот процесс в обратном порядке.

Принуждение WSUS к перенастройке себя, похоже, устраняет любую проблему, неправильно настроенную с помощью IIS.

Я работал над этой проблемой почти неделю, и это, в конечном итоге, помогло ее решить. Надеюсь, это вам поможет.

В ваших затронутых клиентах проверьте реестр в

HKLM / ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ / Политики / Microsoft / Windows / WindowsUpdate

и сравните значения WUServer и WUStatusServer с фактическим именем сервера WSUS.

Я столкнулся с этой проблемой на прошлой неделе при первой настройке сервера WSUS в моей сети. Я тоже использовал 2008 R2 (виртуальный экземпляр) в качестве сервера, и все мои клиенты были либо серверами, либо машинами Win 7 x64.

Я боролся с ним несколько дней, устанавливая различные патчи для самого WSUS, пытаясь перенастроить IIS и переполняя журнал за журналом. Инструмент Solarwinds сказал мне, что все в порядке, у меня нет проблем с DNS и проблем с подключением к IIS на сервере из любого места. Я удалил папку softwaredistribution, заставил клиента обнаружить и сообщить, использовал инструмент Microsoft fixit и все такое. В конце концов, у меня осталось больше половины моих хостов, которые все еще не отчитывались (никогда) на сервере, и ни один из них не мог вручную проверять наличие обновлений, не получив предложения 80072EE2.

В крайнем случае, я выключил виртуальную машину и сделал новую, на этот раз с Server 2012. Я установил роли WSUS из Server Manager, и в течение нескольких минут все работало без сбоев.