WSUS clients failing to get updates with error 80072EE2

We recently implemented WSUS for our Windows workstations (about 90). Some of the clients seem to have no problem, while others keep returning the error "80072EE2" when attempting to manually check for updates using Windows Update.

Clients are Win7 x64 SP1, server is Win2008 x86 SP2

Our workstations use a standard image, so there is minimal difference between systems.

The process w3wp.exe on the server spikes to very high CPU for extended periods of time.

In the problem clients' WindowsUpdate.log, we see:

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

Checking the WSUS server SoftwareDistribution.log, we see:

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

What we've tried:

1. Rebooting the server
2. Changing Automatic Updates check for updates period from 1 hour to 10 hours
3. Disabling AV on-access scanning on server
4. Updating a problem client to latest WSUS client
5. Manually browsing to the URL mentioned in the client's log above. (No issues)

I'm fairly new to WSUS so I'm not really sure what else we can check. Any help would be greatly appreciated.

Solution 1:

In your affected clients check registry in

HKLM/SOFTWARE/Policies/Microsoft/Windows/WindowsUpdate

and compate the values for WUServer and WUStatusServer to your WSUS actual server name

Solution 2:

I recently came across this exact issue, with identical errors in the logs as you are seeing.

The event errors in the screenshot below turned me on to the problem:

These errors in the event log were related to the Windows Process Activation Service (a .NET component) having issues with the WSUS application pool. Uninstalling the WSUS role made these errors go away, but reinstalling the role made them come back again (that's how I knew they were caused by WSUS and not from other web services on this server).

First things first, make sure that KB2720211 is installed on the WSUS server. This is a security update for WU itself. If any of your clients updated directly from Microsoft, they will have this update already and will be unable to communicate with your WSUS server (checking for updates from Microsoft on the WSUS server will give you this update if the WSUS role is installed).

Secondly, force WSUS to reconfigure IIS. For some reason, reinstalling the role configured it improperly. From a command prompt, type the following:

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

This will reconfigure the WSUS IIS site to operate on port 80. Then type:

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

This will reconfigure WSUS back to port 8530.

If you were already on port 80, then do this process in reverse.

Forcing WSUS to reconfigure itself seems to unclog whatever problem got mis-configured with IIS.

I worked on this problem for almost a week and this is what eventually cleared it up. I hope it helps you.

Solution 3:

I experienced this issue last week when configuring a WSUS server for the first time on my network. I, too, used 2008 R2 (virtual instance) as the server and all my clients are either servers or Win 7 x64 machines.

I fought for days with it, installing various patches for WSUS itself, trying to reconfigure IIS, and pouring over log after log. The Solarwinds tool told me everything was good to go, I had no DNS issues and no problems contacting IIS on the server from anywhere. I deleted the softwaredistribution folder, forced the client to detect and report, used the Microsoft fixit tool, all that garbage. In the end I was left with more than half my hosts still not reporting in (ever) to the server and none of them able to manually check for updates without getting a bid ol' 80072EE2.

As an absolute last resort, I turned off the VM and made a new one, this time with Server 2012. I installed the WSUS roles from Server Manager and everything was working smoothly within a few minutes.