locked
Mise à jour windows update sur deux contrôleurs de domaine ? RRS feed

  • Question

  • Bonjour,

    Nous possédons 2 contrôleurs de domaine répliqués sur 2 sites distincts.

    Quelle est la préconisation microsoft concernant les mises à jour windows update sur 2 contrôleurs de domaines ?

    Est ce un problème si les les MAJ ne sont pas installées en même temps ? L'installation des MAJ doit elle être coordonnée sur les deux DC ?

    Merci d'avance

    jeudi 11 janvier 2018 15:54

Réponses

  • Bonjour,

    Généralement, Les mises à jour se passe bien, mais il y a toujours un risque  qui peuvent créer une perte importante à votre entreprise si cette tâche est mal gérés.  par exemple le derniers rollup du mois Janvier, il y a un problème avec les systèmes AMD qui peut empêcher les serveur à booter.

    Pour cela pour les contrôleur de domaine je recommande à mes clients les recommandations suivantes:

    • Tester les mises à jour dans un environnement non-production ( comme expliquer par Romain)
    • Ne pas installer la mise à jour sur tous les contrôleur du même site, afin de laisser toujours des DCs disponible en cas de problème, pour gérer les demande authentification des utilisateurs locaux ,laisser un décalage au moins une semaine pour bien maîtriser les effets de bord.
    • Avant chaque déploiement d'une mise à jour, sauvegarder vos serveur

    WSUS est l'outil gratuit fournie par Microsft que vous permet de gérer les mises à jours de vos serveur. SCCM est plutôt dédié pour gérer les mises à jour des postes de travail.

    Ce qui concerne le transfère des rôles FSMO, je le vois pas nécessaire, l'utilisateur ne va pas sentir l’indisponibilité du rôle FSMO pendant le reboot (juste pour quelques minutes) du serveur et surtout qu'on choisit souvent des horaire hors travail pour cela je le vois pas nécessaire. 


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    jeudi 11 janvier 2018 20:04
    Auteur de réponse

Toutes les réponses

  • Bonjour,

    Au contraire... Il faut en mettre un à jour, puis l'autre (une fois que le premier a donc repris du service) et je préconise de ne pas le faire sur le master (celui qui détient tous les rôles) en premier...

    Idéalement, transférer les rôles FSMO si vous n'avez pas le droit à un "downtime" ou alors scheduler l'update out-of-business hour ;-)

    jeudi 11 janvier 2018 15:58
  • J'ajouterai : déphaser le patch d'au moins une semaine (sauf les zero day) pour avoir du recul sur les BSOD. Ensuite, examiner bien ce que fait chaque patch : si cela touche au réplications ou à kerberos par exemple, il faut patcher les 2 DCs dans un laps de temps assez court (le risque étant que les deux ne communiquent plus ou mal).
    jeudi 11 janvier 2018 16:02
  • +1 pour ce que Loic a rajouté. Pour les DCs, nous les mettons toujours à jour avec 2 semaines d'écart. Les patches sont d'abord "testé" sur nos serveurs en DEV/UAT (puis PROD et ensuite les DCs; donc 3 groupes différents dans WSUS)
    jeudi 11 janvier 2018 16:07
  • Comme expliqué il n'est pas nécessaire d'appliquer les mises à jour en même temps, il est même préférable de les décaler. 

    Il est important de suivre l'état des DCs régulièrement notamment après la mise à jour.

    Des services comme Wsus ou SCCM permettent de gérer le déploiement par groupe de machine différentes afin de garantir la continuité du service.

    Il est possible de mettre des scripts de contrôle régulier afin de détecter les anomalie dans l'AD par exemple.

    jeudi 11 janvier 2018 19:31
  • Bonjour,

    Généralement, Les mises à jour se passe bien, mais il y a toujours un risque  qui peuvent créer une perte importante à votre entreprise si cette tâche est mal gérés.  par exemple le derniers rollup du mois Janvier, il y a un problème avec les systèmes AMD qui peut empêcher les serveur à booter.

    Pour cela pour les contrôleur de domaine je recommande à mes clients les recommandations suivantes:

    • Tester les mises à jour dans un environnement non-production ( comme expliquer par Romain)
    • Ne pas installer la mise à jour sur tous les contrôleur du même site, afin de laisser toujours des DCs disponible en cas de problème, pour gérer les demande authentification des utilisateurs locaux ,laisser un décalage au moins une semaine pour bien maîtriser les effets de bord.
    • Avant chaque déploiement d'une mise à jour, sauvegarder vos serveur

    WSUS est l'outil gratuit fournie par Microsft que vous permet de gérer les mises à jours de vos serveur. SCCM est plutôt dédié pour gérer les mises à jour des postes de travail.

    Ce qui concerne le transfère des rôles FSMO, je le vois pas nécessaire, l'utilisateur ne va pas sentir l’indisponibilité du rôle FSMO pendant le reboot (juste pour quelques minutes) du serveur et surtout qu'on choisit souvent des horaire hors travail pour cela je le vois pas nécessaire. 


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    jeudi 11 janvier 2018 20:04
    Auteur de réponse
  • WSUS est l'outil gratuit fournie par Microsft que vous permet de gérer les mises à jours de vos serveur. SCCM est plutôt dédié pour gérer les mises à jour des postes de travail.

    Je ne vois pas trop pourquoi ... SCCM permet de gérer les mises à jour des postes et des serveurs, il permet des groupes, des plages horaires et SCCM s'appuie sur WSUS. 

    Avant chaque déploiement d'une mise à jour, sauvegarder vos serveur

    Il est recommander de sauvegarder les serveurs même s'il n'y a pas de déploiement de mise à jour. Selon la fréquence des sauvegardes je ne suis pas sur qu'il y ait besoin de faire des sauvegardes supplémentaires.

    Je ne vois pas non plus l'importance de déplacer les rôles FSMO. AD est en mesure de supporter une absence ponctuelle des rôles. Les DC avec des rôles FSMO n'ont pas plus d'informations que les autres, il est donc possible de les transférer en cas de nécessité.

    jeudi 11 janvier 2018 21:19
  • Merci à tous pour vos réponses.
    vendredi 12 janvier 2018 08:17
  • @Philippe: utiliser les mêmes outils et aussi la même équipe pour gerer les serveurs et les postes de travail en même n’est pas conseillé. Il y a toujours un risque d’erreur humaine qui peut créer des interruptions de services dans certains cas .
    J’ai eu un client qui utilise les mêmes outils, pour les mises à jour et le déploiement des packages sur les postes de travail et les serveurs. L’équipe qui maîtrise cet outil est partie et la nouvelle équipe par erreur ont déployé des packages destinés aux postes de travail sur les serveurs. Et pour le désinstaller il fallait rebooter tous les serveurs. 

    Ce qui concerne les rôles fsmo, il faut pas s’amuser de les transférer à chaque reboot. Surtout dans un environnement où les flux ne sont pas totalement ouverts entre les DC sachant le PDC a besoin de communiquer avec tous les dc du domaine donc le choix de l’emplacement du pdc n’est pas évident. Un reboot n’est pas une nécessité pour transférer les rôles fsmo, il faut juste bien planifier le reboot.

    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/


    vendredi 12 janvier 2018 11:19
    Auteur de réponse
  • @Philippe: utiliser les mêmes outils et aussi la même équipe pour gerer les serveurs et les postes de travail en même n’est pas conseillé. Il y a toujours un risque d’erreur humaine qui peut créer des interruptions de services dans certains cas . 

    Je ne comprends toujours pas. Il existe des rôles et des droits dans SCCM, il n'y a pas de lien entre le fait d'utiliser SCCM (qui est juste du WSUS contrôlé par une console), utiliser WSUS directement  et le fait de séparer les rôles d'administrations.

    Ton risque humain est exactement le même ...

    Pour le reste, toutes les entreprises n'ont pas la possibilité de séparer les activités.

    https://docs.microsoft.com/fr-fr/sccm/core/understand/fundamentals-of-role-based-administration

    vendredi 12 janvier 2018 13:12
  • @Philippe: utiliser les mêmes outils et aussi la même équipe pour gerer les serveurs et les postes de travail en même n’est pas conseillé. Il y a toujours un risque d’erreur humaine qui peut créer des interruptions de services dans certains cas . 

    Je ne comprends toujours pas. Il existe des rôles et des droits dans SCCM, il n'y a pas de lien entre le fait d'utiliser SCCM (qui est juste du WSUS contrôlé par une console), utiliser WSUS directement  et le fait de séparer les rôles d'administrations.

    Ton risque humain est exactement le même ...

    Pour le reste, toutes les entreprises n'ont pas la possibilité de séparer les activités.

    Le niveau du risque dépend du niveau de compétence de l'équipe qui gère l'infra (SCCM,WSUS,desktop et serveurs), généralement ceux qui maîtrise les serveurs n'ont pas le même niveau au niveau de compétence sur desktop mais cela dépend  bien sur de la personne.
    Le fait de séparer les activités et les environnement d'administration (droit,VLAN,outils) permet de minimiser le risque.
    Pour les petits comptes je suis d'accord avec toi ils n'ont pas généralement les moins pour séparer les activités et même pour protéger leur INFRA ( redondance des serveurs, séparation des rôles)  mais cela nous n'empêche pas de les rappeler les risques. 

    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    vendredi 12 janvier 2018 13:37
    Auteur de réponse
  • Pour être dans le débat avec les copains : SCCM coûte très cher, ont a donc des équipes en face qui sont en général splittée sur des compétences propres (et ce, même dans le mode à Gilles).

    Philippe à raison : les rôles sont sécable sur SCCM et doivent l'être, que ce soit une ou plusieurs équipes qui soit en charge du patching.



    vendredi 12 janvier 2018 14:34
  • On sort un peut du débat mais bon, c'est aussi un peu ça un forum, un échange d'opinion.

    @Thameur

    Encore une fois, tu peux séparer les activité, les équipes dans la gestion de rôle de SCCM sans que les équipes qui gèrent les postes de travail et les équipes qui gèrent les serveurs ne se marche sur les pieds. 

    Je ne te rejoins pas sur la limitation des risques, multiplier les outils n'est pas plus intéressant que de gérer la sécurité des outils.

    @Loïc

    SCCM a un prix, il coûte plus ou moins cher en fonction de ce que tu en fais. Techniquement pour moi, il nous faudrait sans doute plus de personnes pour gérer la même charge sans outil comme SCCM. Aujourd'hui déployer un PC représente 5 minutes pour entrer la MAC adresse dans SCCM et 10 minutes pour poser le poste. 

    Le déploiement des applications est automatisé en fonction de l'affectation des utilisateurs / machine et de groupe AD.

    La création des compte dans l'AD, des boites mails, des listes de distributions, la désactivation des comptes des agents partis etc... et automatisé par script powershell. Techniquement je peux donc simplement avec une table de correspondance indiquer que les membres d'un service ont automatiquement une imprimante, un logiciel etc... 

    La migration  d'OS est automatisé (j'ai juste à consulter les mails pour suivre l'évolution car les séquences de tâches m'envoient des mail en auto), les outils d'assistance nous permettent d'aider les utilisateurs situés sur d'autres sites, les inventaires et rapports permet de suivre les licences ...

    Du coup cela libère du temps pour des tâches un peu plus intéressante et productive.

    Un logiciel est cher lorsqu'il n'est pas rentabilisé. 10€ pour un truc qui sert à rien c'est déjà cher ...

    vendredi 12 janvier 2018 18:28
  • Bonsoir 

    Discussion intéressante comme d'habitude avec Philippe et Loic :).

    Mais faut pas s'éloigner beaucoup de la question principale :) , on est dans le cas de deux DC , même Windows update peut faire l'affaire. 


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    samedi 13 janvier 2018 01:24
    Auteur de réponse