Nous avons récemment implémenté WSUS pour nos postes de travail Windows (environ 90). Certains clients semblent n'avoir aucun problème, tandis que d'autres continuent de renvoyer l'erreur "80072EE2" lors de la tentative de vérification manuelle des mises à jour à l'aide de Windows Update.
Les clients sont Win7 x64 SP1, le serveur est Win2008 x86 SP2
Nos postes de travail utilisent une image standard, il y a donc une différence minimale entre les systèmes.
Le processus w3wp.exe sur le serveur pointe vers un processeur très élevé pendant de longues périodes.
Dans le WindowsUpdate.log des clients à problème, nous voyons:
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
En vérifiant le serveur WSUS SoftwareDistribution.log, nous voyons:
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
Ce que nous avons essayé:
Je suis assez nouveau sur WSUS, donc je ne sais pas vraiment quoi d'autre nous pouvons vérifier. Toute aide serait grandement appréciée.
J'ai récemment rencontré ce problème exact, avec des erreurs identiques dans les journaux que vous voyez.
Les erreurs d'événement dans la capture d'écran ci-dessous m'ont mis sur le problème:
Ces erreurs dans le journal des événements étaient liées au service d'activation de processus Windows (un composant .NET) ayant des problèmes avec le pool d'applications WSUS. La désinstallation du rôle WSUS a fait disparaître ces erreurs, mais la réinstallation du rôle les a fait revenir (c'est ainsi que je savais qu'elles étaient causées par WSUS et non par d'autres services Web sur ce serveur).
Tout d'abord, assurez-vous que KB2720211 est installé sur le serveur WSUS. Il s'agit d'une mise à jour de sécurité pour WU elle-même. Si l'un de vos clients est mis à jour directement à partir de Microsoft, il disposera déjà de cette mise à jour et ne pourra pas communiquer avec votre serveur WSUS (recherche de mises à jour de Microsoft sur le serveur WSUS vous donnera cette mise à jour si le rôle WSUS est installé).
Deuxièmement, forcez WSUS à reconfigurer IIS. Pour une raison quelconque, la réinstallation du rôle l'a mal configuré. À partir d'une invite de commandes, tapez ce qui suit:
C:\Program Files\Update Services\Tools\wsusutil.exe usecustomwebsite false
Cela va reconfigurer le site WSUS IIS pour fonctionner sur le port 80. Tapez ensuite:
C:\Program Files\Update Services\Tools\wsusutil.exe usecustomwebsite true
Cela reconfigure WSUS sur le port 8530.
Si vous étiez déjà sur le port 80, faites ce processus à l'envers.
Forcer WSUS à se reconfigurer semble déboucher tout problème mal configuré avec IIS.
J'ai travaillé sur ce problème pendant près d'une semaine et c'est ce qui l'a finalement résolu. J'espère que ça t'aide.
J'ai rencontré ce problème la semaine dernière lors de la configuration d'un serveur WSUS pour la première fois sur mon réseau. J'ai également utilisé 2008 R2 (instance virtuelle) comme serveur et tous mes clients sont des serveurs ou des machines Win 7 x64.
J'ai combattu pendant des jours avec, en installant divers correctifs pour WSUS lui-même, en essayant de reconfigurer IIS et en déversant journal après journal. L'outil Solarwinds m'a dit que tout allait bien, je n'ai eu aucun problème DNS et aucun problème pour contacter IIS sur le serveur de n'importe où. J'ai supprimé le dossier softwaredistribution, obligé le client à détecter et signaler, J'ai utilisé l'outil Fixit de Microsoft, toutes ces ordures. Finalement, plus de la moitié de mes hôtes ne se sont toujours pas rapportés au serveur et aucun d'entre eux n'a pu vérifier manuellement les mises à jour sans obtenir une offre de 80072EE2.
En dernier recours, j'ai désactivé le VM et en ai créé un nouveau, cette fois avec Server 2012. J'ai installé les rôles WSUS à partir du Gestionnaire de serveur et tout fonctionnait sans problème en quelques minutes.
Dans vos clients concernés, enregistrez le registre
HKLM/LOGICIEL/Stratégies/Microsoft/Windows/WindowsUpdate
et comparez les valeurs de WUServer et WUStatusServer à votre nom de serveur WSUS réel