Arrêtez les mises à niveau de fonctionnalités et gérez-les correctement via WSUS

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:

$C:\Windows10Upgrade$

— IT Apprentice
source

S'il vous plaît vérifier cette solution - & gt; serverfault.com/questions/891295/windows-10-circumvents-wsus/…

— Am_I_Helpful

@Am_I_Helpful, cela aurait été utile si vous avez commenté plutôt que de me lier à un article. Cela ne génère que plus de questions. Je viens de lire: La solution est très simple (LOL): assurez-vous que la copie de Windows 10 1703 ne comporte aucun des noms de valeur suivants répertoriés sous HKEY_LOCAL_MACHINE \ SOFTWARE \ Policies \ Microsoft \ Windows \ WindowsUpdate

— IT Apprentice

J'en ai plusieurs configurés comme indiqué ci-dessus pour tenter d'arrêter ces mises à jour ... Je suis terriblement confus, j'ai mis ces mesures en place pour arrêter les mises à jour .. maintenant je dois les supprimer ..?

— IT Apprentice

Il semble que vous venez de parcourir la réponse, sans même vous rendre compte que cela répond également à votre question. Ne configurez aucune politique comme DeferFeatureUpdates et DeferFeatureUpdatesPeriodInDays. 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!

— Am_I_Helpful

@Am_I_Helpful - S'il vous plaît soyez gentil. L'auteur est clairement confus. Tout ce que vous avez à dire est de vous assurer que ces stratégies sont conservées et non configurées.

— Ramhound

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.

 DeferFeatureUpdates
 DeferFeatureUpdatesPeriodInDays
 DeferQualityUpdates
 DeferQualityUpdatesPeriodInDays
 PauseFeatureUpdatesStartTime
 PauseQualityUpdatesStartTime
 ExcludeWUDriversInQualityUpdate

Citer plus loin du même article "Pourquoi les clients gérés WSUS et SCCM se tournent-ils vers Microsoft Online" :

Qu'est-ce qui vient de se passer ici? Ces stratégies de mise à jour ou de report ne sont-elles pas mises à jour?

Pas dans un environnement géré. Ces stratégies sont destinées à Windows   Mise à jour pour les entreprises (WUfB).

Windows Update for Business, également appelé WUfB, active les technologies de l'information   les administrateurs à garder les périphériques Windows 10 dans leur organisation   toujours à jour avec les dernières défenses de sécurité et Windows   fonctionnalités en connectant directement ces systèmes à Windows Update   un service.

Nous vous recommandons également de ne pas utiliser ces nouveaux paramètres avec WSUS / SCCM.

Si vous utilisez déjà une solution sur site pour gérer Windows   mises à jour / mises à niveau, l'utilisation des nouveaux paramètres WUfB permettra à vos clients   également contacter Microsoft Update en ligne pour récupérer les mises à jour en contournant   votre point final WSUS / SCCM.

Pour gérer les mises à jour, vous avez deux solutions:

Utilisez WSUS (ou SCCM) et gérez comment et quand vous souhaitez déployer des mises à jour et des mises à niveau vers des ordinateurs Windows 10 dans votre environnement (en   votre intranet).

Utilisez les nouveaux paramètres WUfB pour gérer comment et quand vous souhaitez déployer des mises à jour et des mises à niveau vers des ordinateurs Windows 10 de votre environnement.   se connecter directement à Windows Update.

- "Pourquoi les clients gérés WSUS et SCCM se tournent-ils vers Microsoft Online" : Cet article a été rédigé par Shadab Rasheed, Conseiller technique, Périphériques Windows et amp; Déploiement (9 janvier 2017), Équipe Microsoft Windows Server .

REMARQUE: Soyez averti que la liste des noms de valeur de registre de l'article Microsoft mentionné comporte des fautes de frappe.

— Am_I_Helpful
source

Je supprime ce que je pensais être une action passive-agressive, en particulier le "LOL" dans votre réponse, du moins ce n'était pas professionnel. J'ai également amélioré la phrase qui la suit et l'ai combinée avec une autre déclaration. Je vous demande de vérifier que cette réponse s’applique à 1607 car c’est bien ce que l’auteur utilise.

— Ramhound

@Ramhound - Merci encore pour l'édition; mais je ne vois pas cette ligne 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é?

— Am_I_Helpful

Non, je vous demande de vérifier que votre réponse s'applique à 1607. Vous appelez spécifiquement 1703 dans votre réponse.

— Ramhound

@Ramhound - OK, merci pour le conseil. J'ai restauré le contenu d'origine de l'article de blog qui mentionne que cela s'applique à la version 1511 et à la version 1607 (même si personnellement, je l'ai également vérifié pour la version 1703).

— Am_I_Helpful

Si cela fonctionne pour 1703 et que vous avez vérifié que cela fonctionne, mentionnez-le dans la réponse. Assurez-vous de corriger les fautes de frappe, car vous n’avez pas d’appareil où je peux comparer facilement le contenu.

— Ramhound

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.

— Mark Berry
source