Laissez-vous les mises à jour automatiques de Windows activées sur votre serveur IIS de production?

Si vous exécutiez un site Web 24/7 sur Windows Server 2003 (IIS6). Souhaitez-vous laisser la fonction de mise à jour automatique de Windows activée ou la désactiver?

Une fois activé, vous obtenez toujours les derniers correctifs de sécurité et corrections de bugs dès qu'ils sont disponibles, ce qui est le choix le plus sûr. Cependant, la machine est parfois redémarrée automatiquement pour appliquer les mises à jour, ce qui entraîne quelques minutes d'indisponibilité au milieu de la nuit. De plus, j'ai vu de rares occasions où la machine ne redémarre pas correctement, ce qui entraîne des temps d'arrêt supplémentaires.

Si les mises à jour automatiques sont désactivées, quand appliquez-vous les correctifs? Je suppose que vous devez utiliser un équilibreur de charge avec plusieurs serveurs Web et les faire pivoter hors du site de production, appliquer des correctifs manuellement et les remettre. Cela peut être gênant sur le plan logistique lorsque l'équilibreur de charge est géré par une société d'hébergement. Vous aurez également des machines en production qui ne disposent pas toujours des derniers correctifs de sécurité et vous devez régulièrement passer du temps à décider quels correctifs appliquer et quand.

Réponse courte, non.

Dans le meilleur des cas, vous devriez au moins avoir un autre box / vm / cochon d'Inde pour tester le patch pour vous assurer qu'il ne détruit pas votre monde.

Dans le pire des cas, je le laisserais télécharger les correctifs mais pas les installer, afin que je puisse revoir ce qui est installé. Mais je suis juste un monstre de contrôle de cette façon.

J'ai bien peur de ne pas être d'accord avec le consensus.

Quiconque dit qu'une «intervention humaine est nécessaire» ne pense pas assez progressivement.

Automatisez tout.

Peut-être que cela signifie activer la mise à jour automatique (je le fais dans mes environnements à faible conséquence).

Peut-être que cela signifie quelque chose de plus rigoureux (où vous mettez automatiquement à jour un environnement de transfert, le faites valider automatiquement pour un fonctionnement correct, puis déclenchez la mise à jour automatique dans l'environnement de production). Des rapports ou des notifications par e-mail doivent être utilisés afin que les administrateurs aient une visibilité sur l'état du processus.

Il existe un certain nombre de façons d'accomplir cette automatisation, des scripts PowerShell aux services de mise à jour logicielle (SUS) ... et surtout depuis que vous avez posé cette question sur stackoverflow et non sur la défaillance du serveur, je vous recommande de développer des routines pour automatiser autant de processus de mise à jour possible.

Sinon, vous risquez de ne pas appliquer les mises à jour ou de les appliquer de manière incorrecte. De plus, si vous êtes comme moi, vous préféreriez vous réveiller à 3h du matin une fois dans une lune bleue lorsque les mises à jour échouent (et vous êtes paginé par vos routines de mise à jour), et ne pas vous réveiller à 3h du matin chaque mois pour installer les mises à jour pendant les heures à faible conséquence.

Bien sûr, YMMV. Concevez un processus qui vous convient le mieux, mais essayez de ne pas vous faire trop de travail inutile.

Pour un serveur Windows de production, je ne recommanderais pas de configurer Windows Update pour télécharger et installer les mises à jour automatiquement. Une meilleure approche consiste à télécharger les mises à jour automatiquement mais à les installer manuellement.

Les avantages de cette approche sont:

1. Vous pouvez consulter les mises à jour proposées avant l'installation et, si nécessaire, rechercher les implications de l'installation de la mise à jour. Cela peut sembler plus de travail - ça l'est! mais au moins vous aurez le contrôle. Microsoft propose également une liste de diffusion gratuite qui vous informe rapidement du type de mises à jour à publier dans le prochain lot de mises à jour Windows.
2. Vous pouvez décider d'une heure de redémarrage qui a un impact minimal sur les visiteurs de votre site Web. Il semblerait que votre site Web fonctionne à partir d'un seul serveur, il pourrait donc être utile d'afficher une bannière sur votre site Web qui avertit vos visiteurs d'un redémarrage imminent. J'ai implémenté quelque chose de similaire qui apparaît une heure avant un redémarrage et affiche un message disant «Le site Web fermera dans x minutes pour la maintenance. La maintenance ne devrait pas prendre plus de 10 minutes.
3. Étant donné que vous avez lancé manuellement un redémarrage du serveur, vous pouvez vérifier que le serveur a réussi à redémarrer après le redémarrage. Si ce n'est pas le cas, vous pouvez parler à votre hébergeur et régler le problème.

Fondamentalement, il s'agit de contrôle et avec des téléchargements et une installation automatiques, vous n'obtenez pas grand-chose !!

J'autorise les mises à jour automatiques, mais je le fais via WSUS. Cela vous permet de choisir et de choisir la classe de mises à jour que vous souhaitez appliquer automatiquement afin que vous n'ayez pas d'interruptions pour des anecdotes qui ne vous intéressent pas, mais que vous obteniez des correctifs pour les exploits du jour 0 dès que possible.

Je ne pense pas que ce soit une question de «permettre les mises à jour» et de «ne pas leur permettre» d'avoir raison ou de mal, soit dit en passant, il s'agit simplement de choisir les risques et les inconvénients que vous êtes prêt à prendre. Il y a des risques à autoriser les mises à jour à s'exécuter automatiquement et il y a des risques si vous ne le faites pas. Équilibrez-les et faites un choix éclairé.

Vous pouvez envisager un déploiement par étapes - les correctifs publiés mardi sont installés immédiatement sur un environnement de test et programmés pour être installés jeudi sur les serveurs de production, par exemple, ce qui vous donne deux jours pour que des problèmes apparaissent dans l'environnement de test qui indiquent un blocage ou retarder un patch particulier.

Si la haute disponibilité est un problème majeur, vous devez de toute façon utiliser le clustering ou l'équilibrage de charge, ce qui devrait couvrir les temps d'arrêt dus aux correctifs de toute façon. Après tout, pourquoi les temps d'arrêt dus aux correctifs sont-ils magiquement pire que les défaillances matérielles qui peuvent survenir à tout moment sur n'importe quelle boîte?

Nous n'activons jamais les mises à jour automatiques sur notre serveur. Il est hébergé dans un centre de données, nous avons donc regardé les statistiques dans Google Analytics pour voir à quel moment le trafic était au plus bas, puis programmé les techniciens pour installer des mises à jour à ce moment-là sur site. De cette façon, si un redémarrage était nécessaire, ou si quelque chose allait terriblement mal, cela n'affecterait pas autant de personnes que si Windows avait téléchargé une mise à jour au milieu de la journée.

Comme tout le monde ici a déjà répondu: NON! Nous utilisons Systems Centers Essentials pour envoyer des mises à jour aux serveurs Web de production, seulement APRÈS leur installation sur des serveurs de test.

Nous recevons également les e-mails de mise à jour mensuelle de MS afin que nous sachions exactement à quoi sert chaque mise à jour et à quoi elle sert. Il est beaucoup plus facile de dépanner si vous savez exactement ce qui a été mis à jour et quand.

Définitivement pas. On a appris trop souvent à la dure à ne pas laisser cette absurdité se produire. Malheureusement, cela signifie que l'on est un peu plus paresseux quant à l'application de correctifs et de mises à jour. Mais jusqu'à présent, je n'ai pas encore d'avoir un serveur divisé en parce que je n'ai pas appliqué une pièce particulière tout de suite, mais je l' ai eu beaucoup de maux de tête causés par un redémarrage du serveur à un moment inopportun, ou en redémarrant et de ne pas démarrer un service essentiel après l'installation d'un correctif.

Sur un sidenote, nous venons de recevoir un nouveau cluster de cinq machines via notre fournisseur de services, un FAI très grand et bien connu de cette partie du monde. Lorsque nous avons obtenu les comptes d'administrateur et que nous avons pu nous connecter et commencer à configurer notre logiciel, j'ai été très heureux de voir que cette première tâche habituelle avait déjà été prise en charge par les administrateurs système du réseau. :)

Appliquer des mises à jour == redémarrages aléatoires de votre système, hors de votre contrôle. Cela donne les ruches de SA. De plus, il y a eu des incidents de cassures de correctifs dans le passé, vous devez donc rarement les appliquer si vous ne les avez pas essayés dans le passé.

Une approche que j'ai étudiée consiste à passer à un environnement d'hébergement virtualisé. Cela vous permet de tester la mise à jour sur une instance hors production, ou même d'appliquer une mise à jour à une instance hors ligne et de l'échanger en production une fois que vous êtes sûr que c'est bon.

Absolument pas. Les mises à jour doivent être appliquées aux serveurs en dehors des heures d'ouverture et avec des plans d'urgence en place, ce qui signifie suffisamment de temps pour annuler la mise à jour en cas d'échec.

En tant qu'administrateur système, vous souhaitez avoir autant de variables que possible sous votre contrôle. C'est déjà assez dur sans arriver le matin sur un serveur mort! ;-)

Notez qu'il est possible de définir une heure spécifique pour les mises à jour et que la plupart des mises à jour ont lieu le mardi. De cette façon, vous pouvez planifier du temps pour passer en revue les mises à jour à venir et téléchargées, et savoir quand des problèmes potentiels surviendront.

Une bonne question à vous poser est de savoir si quelque chose ne va pas, qu'est-ce que mon VP / CIO / etc va me dire? L'automatiser peut vous faciliter la vie, mais s'il y a un problème, vous allez être celui qui ratisse les charbons et cela pourrait rendre les choses beaucoup plus difficiles.

J'automatise le diable des PC, avec quelques centaines vous devez. Les serveurs bien que je le planifie et que je l'autorise, donc si quelque chose ne va pas, mon @ $$ est couvert. N'oubliez pas que nous travaillons avec les données d'autres personnes et avec les ressources des entreprises, ils doivent toujours être informés des risques.