Клиенты 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
Проверяя журнал SoftwareDistribution.log сервера WSUS, мы видим:
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 часа до 10 часов
- Отключение сканирования AV при доступе на сервере
- Обновление проблемного клиента до последней версии клиента WSUS
- Переход вручную по URL-адресу, указанному в журнале клиента выше. (Нет проблем)
Я новичок в WSUS, поэтому не совсем уверен, что еще мы можем проверить. Любая помощь будет принята с благодарностью.
Недавно я столкнулся именно с этой проблемой, с теми же ошибками в журналах, что и вы.
Ошибки в журнале регистрации событий на скриншоте ниже привели меня к проблеме:
Эти ошибки в журнале регистрации событий были связаны со службой Windows Process Activation Service (компонент .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 / SOFTWARE / Policies / Microsoft / Windows / WindowsUpdate
и сравните значения для WUServer и WUStatusServer на фактическое имя вашего сервера WSUS
Я столкнулся с этой проблемой на прошлой неделе при первой настройке сервера WSUS в моей сети. Я тоже использовал 2008 R2 (виртуальный экземпляр) в качестве сервера, и все мои клиенты были либо серверами, либо машинами Win 7 x64.
Я боролся с ним несколько дней, устанавливая различные патчи для самого WSUS, пытаясь перенастроить IIS и заливка журнала за журналом. Инструмент Solarwinds сказал мне, что все в порядке, у меня нет проблем с DNS и проблем с подключением к IIS на сервере из любого места. Я удалил папку softwaredistribution, заставил клиента обнаружить и сообщить, использовал инструмент Microsoft fixit - все это мусор. В конце концов, у меня осталось больше половины моих хостов, которые все еще не отчитывались (никогда) на сервере, и ни один из них не мог вручную проверять наличие обновлений, не получив предложения 80072EE2.
В крайнем случае, я выключил виртуальную машину и сделал новую, на этот раз с Server 2012. Я установил роли WSUS из диспетчера серверов, и в течение нескольких минут все работало без сбоев.