Notes
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à : Windows Server Update Services
À compter de juillet 2020, les utilisateurs ont rencontré des problèmes de synchronisation et d’importation WSUS avec les points de terminaison Windows Update (WU) ou Microsoft Update (MU).
Cet article explique comment résoudre certains problèmes courants. Vous pouvez également utiliser certaines de ces techniques de dépannage (telles que les captures réseau) pour de nombreux autres problèmes.
Points de terminaison
Wsus utilise actuellement les points de terminaison suivants pour synchroniser les métadonnées :
https://sws.update.microsoft.com
La plupart des serveurs WSUS doivent se synchroniser avec ce nouveau point de terminaison. À compter de juillet 2020, ce point de terminaison accepte uniquement les connexions TLS (Transport Layer Security) 1.2. Et certains chiffrements ont été désactivés.
https://sws1.update.microsoft.com
Cet ancien point de terminaison sera finalement mis hors service. Pour plus d’informations, consultez Fin de synchronisation pour WSUS 3.0 SP2. Ce point de terminaison prend en charge les connexions TLS 1.2, TLS 1.1 et TLS 1.0.
https://fe2.update.microsoft.com
Cet ancien point de terminaison est désactivé en tant que point de terminaison de synchronisation WSUS et les connexions à celui-ci échouent. Toutefois, les clients Windows Update configurés pour se synchroniser avec Microsoft Update peuvent continuer à utiliser ce point de terminaison.
Lorsque vous rencontrez des problèmes de synchronisation WSUS ou d’importation manuelle, vérifiez d’abord le point de terminaison avec lequel vous synchronisez :
Ouvrez une fenêtre d’invite de commandes PowerShell avec élévation de privilèges sur le serveur WSUS.
Pour rechercher le point de terminaison de synchronisation actuel, exécutez le script PowerShell suivant :
$server = Get-WsusServer $config = $server.GetConfiguration() # Check current settings before you change them $config.MUUrl
Windows Server 2012 et versions ultérieures doivent être configurés pour utiliser le https://sws.update.microsoft.com
point de terminaison. Si vous utilisez https://sws1.update.microsoft.com
toujours ou https://fe2.update.microsoft.com
si vous passez au nouveau point de terminaison en suivant les étapes de synchronisation WSUS échoue avec SoapException. Si nécessaire, résolvez les problèmes de connexion avec le https://sws.update.microsoft.com
point de terminaison.
Problème 1 : Échec de l’importation manuelle, mais la synchronisation réussit
De nombreux utilisateurs importent manuellement des mises à jour dans WSUS, et certaines mises à jour doivent être importées manuellement. Par exemple, les mises à jour en préversion publiées dans les troisième et quatrième semaines du mois doivent être importées manuellement. À partir de la fin de juillet 2020, vous avez peut-être trouvé que vous ne pouvez pas importer manuellement les mises à jour.
Toutefois, certains serveurs WSUS peuvent toujours importer des mises à jour avec succès. Et la synchronisation habituelle avec WU et MU continue de fonctionner.
Ce problème se produit sur les serveurs WSUS exécutant Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019.
Résoudre le problème 1
Exécutez le script PowerShell dans les points de terminaison pour déterminer quels points de terminaison les serveurs WSUS utilisent. Vous trouverez probablement que les serveurs de travail communiquent avec
https://fe2.update.microsoft.com
ouhttps://sws1.update.microsoft.com
, et les serveurs défaillants communiquent avechttps://sws.update.microsoft.com
.Vérifiez que le
%Program Files%\Update Services\LogFiles\SoftwareDistribution.log
fichier contient des erreurs lorsque vous importez manuellement des mises à jour. Recherchez les erreurs qui ressemblent à l’exemple suivant :ProcessWebServiceProxyException found Exception was WebException. Action: Retry. Exception Details: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size) -- End of inner exception stack trace --- ... at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async)
Le message suivant dans l’erreur indique que le serveur WSUS a essayé de se connecter avec WU/MU à l’aide de TLS, mais WU/MU a fermé la connexion :
une connexion existante a dû être fermée par l’hôte distant.
La capture d’écran suivante montre une capture réseau de la tentative de connexion.
Dans la capture réseau, la trame 874 est le paquet Client Hello qui utilise TLS 1.0. Frame 877 correspond à la réponse du serveur. La réponse inclut les indicateurs ACK (A) et RST (R). Étant donné que le https://sws.update.microsoft.com
point de terminaison prend uniquement en charge les connexions TLS 1.2, il refuse la connexion et émet une réponse de réinitialisation.
Résolution du problème 1
Ce problème se produit parce que la fonctionnalité d’importation WSUS ne peut pas utiliser TLS 1.2.
Pour résoudre ce problème, utilisez l’une des méthodes suivantes :
Configurez .NET Framework pour utiliser TLS 1.2 à l’aide de clés de Registre.
Pour définir les clés de Registre, consultez Configurer pour un chiffrement fort. Redémarrez le serveur après avoir défini les clés de Registre.
Créez ou mettez à jour le fichier w3wp.exe.config pour activer TLS 1.2.
Note
Cette modification s’applique à toutes les instances de w3wp.exe créées, qu’elles soient destinées à WSUS. W3wp.exe utilise TLS 1.2 si le côté distant prend en charge cette version. Si TLS 1.1 et TLS 1.0 sont activés, W3wp.exe négocie ces protocoles si le site cible ne prend pas en charge TLS 1.2.
Si le
%SystemRoot%\system32\inetsrv\w3wp.exe.config
fichier n’existe pas, procédez comme suit :Créez un fichier nommé W3wp.exe.config dans le
%SystemRoot%\system32\inetsrv
dossier.Ouvrez le fichier dans un éditeur de texte, tel que le Bloc-notes.
Ajoutez les lignes suivantes au fichier, puis enregistrez le fichier :
<?xml version="1.0" encoding="utf-8"?> <configuration> <runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/> </runtime> </configuration>
Si le
%SystemRoot%\system32\inetsrv\w3wp.exe.config
fichier existe déjà, procédez comme suit :Ouvrez le fichier dans le Bloc-notes ou un autre éditeur de texte.
Ajoutez les lignes suivantes immédiatement sous l’élément <de configuration> , puis enregistrez le fichier :
<runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSystemDefaultTlsVersions=false"/> </runtime>
Après avoir créé ou mis à jour le fichier W3wp.exe.config, ouvrez une fenêtre d’invite de commandes avec élévation de privilèges, puis exécutez
iisreset
pour redémarrer tous les processus de travail. Testez si l’importation manuelle fonctionne maintenant.
Problème 2 : Échec de l’importation manuelle après la désactivation de TLS 1.1 ou TLS 1.0
TLS 1.1 et TLS 1.0 sont supprimés par phase, car ils sont considérés comme non sécurisés. Après avoir désactivé ces protocoles, vous ne pouvez plus importer de mises à jour. Toutefois, la synchronisation continue de fonctionner.
Ce problème se produit sur les serveurs WSUS exécutant Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019.
Résoudre le problème 2
Les journaux WSUS sur lesquels les versions SSL/TLS sont activées au démarrage. Pour déterminer les versions SSL/TLS, procédez comme suit :
Redémarrez le service WSUS.
Exécutez
iisreset
une invite de commandes avec élévation de privilèges pour forcer WSUS à passer par la séquence de démarrage.Ouvrez la console WSUS et connectez-vous au serveur.
Ouvrez
%Program Files%\Update Services\LogFiles\SoftwareDistribution.log
, recherchez les entrées qui commencent par le protocole SCHANNEL. Vous devez voir les entrées qui ressemblent à l’exemple suivant :SCHANNEL Protocol 'TLS 1.0' disabled SCHANNEL Protocol 'TLS 1.1' disabled SCHANNEL Protocols subkey for 'TLS 1.2' not found. Protocol is enabled
Ces entrées indiquent que TLS 1.1 et TLS 1.0 sont désactivés, et TLS 1.2 est activé.
Si le processus d’importation échoue, SoftwareDistribution.log enregistre l’entrée d’erreur suivante :
ProcessWebServiceProxyException found Exception was WebException. Action: Retry. Exception Details: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
La capture d’écran suivante montre une capture réseau de la tentative de connexion.
Dans la capture réseau, les images 1518-1520 montrent l’établissement d’une liaison tridirectionnelle (SYN, SYN ACK, ACK) entre le client et le serveur. Frame 1536 est un paquet FIN ACK du serveur WSUS.
WSUS ferme la connexion, car tous les protocoles qu’il sait utiliser pour l’importation (SSL3, TLS 1.0, TLS 1.1) sont désactivés et ne peuvent pas utiliser TLS 1.2.
Résolution du problème 2
Ce problème est similaire au problème 1, dans lequel l’importation WSUS ne peut pas utiliser TLS 1.2. Pour résoudre ce problème, utilisez La résolution du problème 1.
Problème 3 : La synchronisation échoue sur les serveurs WSUS Windows Server 2012 et Windows Server 2012 R2 qui appliquent uniquement les mises à jour de sécurité uniquement
La maintenance de Windows Server 2012 et Windows Server 2012 R2 contient les pistes de mise à jour suivantes :
- Mise à jour de sécurité uniquement, qui n’est pas cumulative. Il contient uniquement des correctifs de sécurité. Par exemple, le 9 juin 2020 : KB4561673 (mise à jour de sécurité uniquement)
- Cumul mensuel, qui est cumulatif. Il contient tous les correctifs de sécurité de la mise à jour de sécurité uniquement et contient également des correctifs non liés à la sécurité. Par exemple, le 9 juin 2020 — KB4561666 (cumul mensuel).
WSUS sur Windows Server 2012 et Windows Server 2012 R2 ne peuvent pas utiliser TLS 1.2 pour la synchronisation, sauf si l’un des correctifs cumulatifs mensuels suivants ou un correctif cumulatif mensuel ultérieur est installé :
- 27 juin 2017 — KB4022721 (préversion du correctif cumulatif mensuel) pour Windows Server 2012
- 27 juin 2017 — KB4022720 (préversion du correctif cumulatif mensuel) pour Windows Server 2012 R2
La modification qui permet à WSUS d’utiliser TLS 1.2 est un correctif non sécurisé, il est inclus uniquement dans les correctifs cumulatifs mensuels.
Certains utilisateurs choisissent d’installer uniquement les mises à jour de sécurité uniquement et n’installent jamais les correctifs cumulatifs mensuels. Par conséquent, leurs serveurs WSUS n’ont pas la mise à jour qui active TLS 1.2. Une fois le https://sws.update.microsoft.com
point de terminaison modifié pour accepter uniquement les connexions TLS 1.2, ces serveurs WSUS ne peuvent plus se synchroniser avec le point de terminaison. Ce problème se produit également sur un serveur WSUS Windows Server 2012 ou Windows Server 2012 R2 qui n’a pas installé de correctif cumulatif mensuel.
Résoudre le problème 3
Si le serveur WSUS dispose des mises à jour correctes installées, WSUS journalise les versions SSL/TLS activées au démarrage. Procédez comme suit sur le serveur WSUS :
Redémarrez le service WSUS.
Exécutez à
iisreset
partir d’une invite de commandes avec élévation de privilèges pour forcer WSUS à passer par la séquence de démarrage.Ouvrez la console WSUS et connectez-vous au serveur.
Ouvrez
%Program Files%\Update Services\LogFiles\SoftwareDistribution.log
, recherchez les entrées qui commencent par le protocole SCHANNEL. Vous devez voir les entrées qui ressemblent à l’exemple suivant :SCHANNEL Protocol 'TLS 1.0' disabled SCHANNEL Protocol 'TLS 1.1' disabled SCHANNEL Protocols subkey for 'TLS 1.2' not found. Protocol is enabled
Si vous ne trouvez pas ces entrées, cela signifie que la mise à jour qui active TLS 1.2 n’est pas installée.
En cas d’échec de la synchronisation, SoftwareDistribution.log journalise le message d’erreur suivant :
WebServiceCommunicationHelper.ProcessWebServiceProxyException ProcessWebServiceProxyException found Exception was WebException. Action: Retry. Exception Details: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
La capture d’écran suivante montre une capture réseau de la tentative de connexion.
Dans la capture réseau, la trame 95 est le paquet Client Hello qui utilise TLS 1.0. Frame 96 est le paquet RST de https://sws.update.microsoft.com
. Étant donné que le point de terminaison prend uniquement en charge les connexions TLS 1.2, il refuse la connexion, puis émet une réponse de réinitialisation. Le serveur WSUS essaie plusieurs fois avant de renoncer. Par conséquent, cette séquence est répétée.
Résolution du problème 3
Pour résoudre ce problème, installez le dernier correctif cumulatif mensuel pour Windows Server 2012 ou Windows Server 2012 R2. Appliquez également la résolution du problème 1 pour empêcher l’échec de l’importation manuelle.
Problème 4 : La synchronisation échoue après juillet 2020 si WSUS est intégré à Configuration Manager
De nombreuses installations WSUS sont intégrées aux points de mise à jour logicielle Microsoft Endpoint Configuration Manager (SUPs). Après juillet 2020, vous pouvez rencontrer des échecs de synchronisation si Configuration Manager est configuré pour synchroniser les pilotes Surface.
Ce problème se produit sur les serveurs WSUS exécutant Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019.
Résoudre le problème 4
Lorsque ce problème se produit, les entrées qui ressemblent à l’exemple suivant sont journalisées Wsyncmgr.log :
Calling ImportUpdateFromCatalogSite for driver update GUIDs
Generic exception : ImportUpdateFromCatalogSite failed. Arg = 001d4517-c586-4bb1-9e66-ed6ff8e8d34f. Error =The underlying connection was closed: An unexpected error occurred on a receive.
Generic exception : ImportUpdateFromCatalogSite failed. Arg = 0037641d-bb9b-4530-9568-11e413223106. Error =The underlying connection was closed: An unexpected error occurred on a receive.
En outre, le %Program Files\Update Services\LogFiles\SoftwareDistribution.log
fichier enregistre les erreurs suivantes :
ProcessWebServiceProxyException found Exception was WebException. Action: Retry. Exception Details: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm
Ces erreurs indiquent que la connexion a été fermée. Ce problème se produit parce que Configuration Manager utilise la fonctionnalité d’importation WSUS. Par conséquent, elle présente les mêmes limitations.
Résolution du problème 4
Pour résoudre ce problème, utilisez La résolution du problème 1.
Problème 5 : Échec de la synchronisation après juillet 2020 en raison de chiffrements limités
Vous pouvez désactiver différents chiffrements pour sécuriser les connexions TLS. À compter de juillet 2020, vos serveurs WSUS ne peuvent plus se synchroniser avec WU/MU. En outre, lorsqu’elle https://sws.update.microsoft.com
est modifiée pour accepter uniquement les connexions TLS 1.2, certains chiffrements sont supprimés.
Ce problème se produit sur les serveurs WSUS exécutant Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 ou Windows Server 2019.
Résoudre le problème 5
Le %Program Files\Update Services\LogFiles\SoftwareDistribution.log
fichier enregistre les erreurs suivantes lors de la synchronisation :
ProcessWebServiceProxyException found Exception was WebException. Action: Retry. Exception Details: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
Toutefois, ces entrées ne sont pas utiles pour déterminer si vous rencontrez un problème de chiffrement.
Dans ce cas, utilisez une capture réseau ou vérifiez les objets de stratégie de groupe (GPO) appliqués. Pour vérifier les objets de stratégie de groupe appliqués, exécutez la commande suivante à l’invite de commandes avec élévation de privilèges :
gpresult /scope computer /h GPReport.html
Ouvrez GPReport.html dans un navigateur.
Recherchez l’ordre des suites de chiffrement SSL et le paramètre Suites de chiffrement SSL. En règle générale, ce paramètre n’est pas configuré. S’il est configuré, le problème peut se produire, car il n’existe aucun chiffrement commun avec WU/MU.
Depuis août 2020, https://sws.update.microsoft.com
prend en charge les chiffrements suivants :
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Note
Cette liste changera au fil du temps, car les chiffrements augmenteront progressivement à mesure que la technologie s’améliore.
Si l’objet de stratégie de groupe est appliqué et qu’il ne spécifie pas l’un de ces chiffrements, la communication avec WU/MU échoue.
La capture d’écran suivante montre une capture réseau.
Dans la capture réseau, frame 400 est le paquet Client Hello qui utilise TLS 1.2. Le détail du cadre indique les chiffrements envoyés par le client. Frame 404 est le paquet RST de https://sws.update.microsoft.com
. Étant donné qu’il n’y a pas de chiffrement commun, la synchronisation échoue.
Résolution du problème 5
Pour résoudre ce problème, effectuez les étapes suivantes :
Utilisez la sortie de l’objet de stratégie de
gpresult
groupe qui spécifie l’ordre de suite de chiffrement SSL, puis supprimez l’objet de stratégie de groupe. Ou modifiez-le pour inclure des chiffrements pris en charge parhttps://sws.update.microsoft.com
.Pour Windows Server 2016 et Windows Server 2019, incluez l’un des chiffrements suivants :
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Pour Windows Server 2012 et 2012 R2, incluez l’un des chiffrements suivants :
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384
Si les chiffrements ne sont pas définis par l’objet de stratégie de groupe, recherchez la sous-clé de Registre suivante :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002
Ajoutez l’un des chiffrements requis à la valeur Functions de la clé de Registre.
Redémarrez le serveur WSUS.
Pour éviter les échecs d’importation manuelle, appliquez également la résolution du problème 1.
Une connexion réussie
Les captures d’écran suivantes montrent une connexion réussie lorsqu’un serveur WSUS Windows Server 2016 synchronise les mises à jour.
Dans la capture réseau, l’image 191 est le paquet Client Hello qui utilise TLS 1.2. Le détail du cadre indique les chiffrements envoyés par le client. Frame 195 est le paquet Server Hello à partir du point de terminaison. TLSCipherSuite choisi par WU est TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Le certificat de serveur est également envoyé dans le paquet Server Hello.
Une configuration de connexion supplémentaire se produit dans les trames 196-203. Le transfert de données par l’application (WSUS) et le point de terminaison commencent ensuite dans l’image https://sws.update.microsoft.com
207.
Remarque sur les serveurs proxy
Si vous utilisez un serveur proxy, la capture réseau se présente différemment. Le serveur WSUS se connecte au proxy et vous pouvez voir une requête CONNECT avec la destination https://sws.update.microsoft.com
, https://sws1.update.microsoft.com
ou https://fe2.update.microsoft.com
. WSUS émet un paquet Client Hello avec les chiffrements qu’il prend en charge. Si la connexion ne réussit pas en raison d’une version TLS incorrecte ou s’il n’existe pas de chiffrement commun, vous risquez ou non de voir un paquet RST. Les proxys ont tendance à renvoyer une fin au client pour indiquer la fin de la connexion. Mais cela peut ne pas être vrai pour chaque serveur proxy. Certains serveurs proxy envoient un paquet RST ou autre chose.
Lorsque vous utilisez un proxy, vous devez connaître l’adresse IP de l’interface interne du serveur proxy, car WSUS ne communique pas directement avec les points de terminaison WU. Si vous ne pouvez pas obtenir l’adresse IP du serveur proxy, recherchez la capture réseau des requêtes CONNECT et recherchez l’URL du point de terminaison Windows Update.