Au cours des derniers mois, les systèmes se sont mis à niveau de manière aléatoire, la mise à jour n’est pas approuvée par WSUS et est obtenue directement à partir des serveurs Miccrosoft.
La mise à niveau vers 1709/1703 n'est pas gérée par WSUS et doit être contrôlée. Et la mise à niveau vers la prochaine mise à jour doit être correctement exécutée dans l’ensemble de la minisérie, quel que soit le temps mort.
La configuration du GPO "Différer les mises à niveau des fonctionnalités" a arrêté la mise à niveau directe vers la version 1709 - mais pas la mise à niveau vers 1703 car ...
"Maintenant que Microsoft, euh, recommande la version 1703 build 15063.483, votre paramètre" Différer les mises à jour des fonctionnalités "a expiré, et vous obtenez la version prête à l'emploi de Win10 Creators Update. (Ceci, malgré le fait qu'il existe une énorme quantité de corrections de bugs en attente dans les coulisses pour 1703.) Il n’existe plus de «succursale actuelle pour les entreprises», mais cette puce «recommande de Microsoft» s’applique à sa place. Si vous reportiez des mises à jour, votre report était épuisé (voir capture d'écran). " - c'est nouveau pour moi!
La source: https://www.computerworld.com/article/3211375/microsoft-windows/win10-machines-with-defer-feature-up ....
Voici ma configuration actuelle de Windows Update sous:
DeferQualityUpdates REG_DWORD 0x0 (not enabled)
DeferFeatureUpdates REG_DWORD 0x1 (enabled)
BranchReadinessLevel REG_DWORD 0x20 (set to current branch for business)
DeferFeatureUpdatesPeriodInDays REG_DWORD 0xb4 (180 days)
ElevateNonAdmins REG_DWORD 0x0 (Users in the Users security group are allowed to approve or disapprove update )
WUServer REG_SZ http://WSUS:8530 (Specified intranet source)
WUStatusServer REG_SZ http://WSUS:8530
La mise à niveau vers 1703 n'est pas gérée par WSUS et doit être contrôlée. Et la mise à niveau vers la prochaine mise à jour doit être correctement exécutée dans l’ensemble de la minisérie, quel que soit le temps mort.
Y a-t-il un moyen de?
- Identifier les serveurs auxquels un système se connecte lors de l'extraction de la fonctionnalité mettre à jour et bloquer les communications? (c.-à-d. arrêter les connexions à Microsoft Serveurs via le contrôle de contenu de point final ou le pare-feu Boundary - sans effectuer de mises à jour Office 365)
Ce que j'ai fait jusqu'à présent
Compris, le 1703 est maintenant recommandé pour les affaires (mais je ne le fais toujours pas le veux)
Tentative de configuration "Ne vous connectez à aucun réseau Windows Update Internet GPO "Emplacements", mais il a également bloqué l'accès à WSUS, malgré le remarque suivante: cette politique ne s'applique que lorsque ce PC est configuré se connecter à un service de mise à jour intranet à l'aide de l'option "Spécifier intranet" "Emplacement du service de mise à jour Microsoft" - c'est déjà configuré au niveau de la stratégie de groupe mais ignoré
Considéré mettre en liste noire les applications / fichiers suivants sur le noeud final console de gestion pour empêcher l’assistant de mise à niveau Windows de en cours d'exécution - mais vous n'avez pas eu le temps de tester:
la source
DeferFeatureUpdatesetDeferFeatureUpdatesPeriodInDays. Si ces 2 systèmes ne sont pas configurés, vos systèmes clients ne communiqueront jamais avec le monde extérieur et resteront en communication uniquement avec WSUS pour les mises à jour!Réponses:
Répéter la même réponse pour Windows 10 contourne WSUS , que j’avais donné à Server Fault ici aussi car le PO commet la même erreur.
La solution est très simple. Assurez-vous que votre copie de Windows 10 n’a aucun des noms de valeur suivants répertoriés sous
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, si vous utilisez Windows 10 - version de l’impact: 1511 & amp; 1607.Citer plus loin du même article "Pourquoi les clients gérés WSUS et SCCM se tournent-ils vers Microsoft Online" :
REMARQUE: Soyez averti que la liste des noms de valeur de registre de l'article Microsoft mentionné comporte des fautes de frappe.
la source
I do ask you verify this answer applies to 1607 because that is indeed what the author is using.dans ma réponse. Voulez-vous que je rajoute le même message ou souhaitez-vous modifier le texte suggéré?Si je comprends bien la question, vous voulez gérer TOUTES les mises à jour, y compris les mises à niveau de fonctionnalités, via WSUS?
On dirait que vous vous heurtez au problème de la «double analyse», où les ordinateurs locaux vont directement à Windows Update pour obtenir des mises à niveau de fonctionnalités. À partir de 1607, vous devriez pouvoir arrêter ce comportement avec cette stratégie de groupe:
Configuration de l'ordinateur & gt; Politiques & gt; Modèles d'administration & gt; Composants Windows & gt; Windows Update & gt; Ne laissez pas les stratégies de report de mise à jour provoquer des analyses par rapport à Windows Update
Détails: https://blogs.technet.microsoft.com/wsus/2017/08/04/improving-dual-scan-on-1607/
Je suis juste en train de l'installer moi-même, donc je n'ai pas encore d'expérience directe. Si je lis correctement cet article et que cette stratégie est activée, Windows ne se connectera pas automatiquement à WU pour les mises à jour de fonctionnalités et si utilisateur demande des mises à jour directement à WU, toute politique de report sera respectée.
la source