Explorer Exchange 2003 Service Pack 2
C'est le grand jour ! Microsoft Exchange Server 2003 Service Pack 2 (SP2) arrive. SP2 s’appuie sur l’excellente base de Exchange 2003 et de ses mises à jour SP1 et devrait intéresser la plupart des entreprises. Pour savoir si cette release vous intéresse, le meilleur moyen est de passer en revue les principales nouveautés de Exchange 2003 SP2.
Lire l'article
Mettre en place WSUS
La gestion des correctifs est un casse-tête pour les administrateurs de sécurité de la plupart des entreprises. En la matière, les petites entreprises s’en remettent souvent aux mises à jour automatiques en provenance des sites Web des fournisseurs, comme Windows Update. Les moyennes entreprises utilisent généralement des solutions de gestion des correctifs comme SUS (Software Update Services). Les grands comptes, eux, ont recours à des outils sophistiqués comme Microsoft SMS (Systems Management Server) 2003.Consciente des déficiences de SUS, comme l’étroitesse des produits qu’il permet de mettre à jour, Microsoft a développé et amélioré un produit de gestion des correctifs appelé WSUS (Windows Systems Management Server). WSUS bénéficie aux entreprises de toutes tailles, grâce à sa souplesse, ses fonctions avancées et sa facilité de déploiement. Nous allons donc voir ensemble comment installer et configurer WSUS pour votre entreprise, obtenir les mises à jour, et configurer les clients pour que WSUS leur procure les mises à jour.
Lire l'article
Les outils de mise à jour selon Microsoft
La mise en place, ou plus exactement le déploiement automatisé des patchs de sécurité des environnements Windows est un sujet d’actualité pour les administrateurs. Avec l’arrivée en fanfare de WSUS, la question est encore plus d’actualité et de nombreux responsables informatiques se posent la question du déploiement ou non de cette solution proposée par Microsoft, d’au tant plus que plusieurs outils Microsoft permettent le déploiement des patchs de sécurité au sein de la famille Windows.La mise en place, ou plus exactement le déploiement automatisé des patchs de sécurité des environnements Windows est un sujet d’actualité pour les administrateurs. Avec l’arrivée en fanfare de WSUS, la question est encore plus d’actualité et de nombreux responsables informatiques se posent la question du déploiement ou non de cette solution proposée par Microsoft, d’au tant plus que plusieurs outils Microsoft permettent le déploiement des patchs de sécurité au sein de la famille Windows.
Lire l'article
Tester les patchs
Automatiser le processus d’assurance de qualité des patches
Avant de déployer des patches, vous devez les tester pour voir s’ils n’ont pas d’effet négatif sur vos systèmes. Mais il existe tellement de patches pour tellement de produits et de versions qu’il faut automatiser les test au maximum.Voici quelques conseils pour scripter le test des patches afin d’éliminer rapidement les bogues avec le moins de travail manuel possible.
Des attentes déraisonnables
Le processus de patching est plein de trous
Je crois exprimer l’opinion de la plupart des administrateurs réseau en déclarant que nous avons besoin de l’aide de Microsoft pour régler le problème du patching. Au cours des dernières années, nous avons eu de la chance parce que des avertissements précédaient la plupart des événements et nous nous attendions donc à leur survenue ...Néanmoins, tenir des systèmes à jour prend beaucoup trop de temps.
Mise à jour de registre automatisée
Utilisez un script pour mettre à jour à distance les registres de machines multiples
Dans toutes sortes de situations, il est utile de pouvoir effectuer à distance des mises à jour de registres sur plusieurs ordinateurs. Quand une anicroche dans la configuration des registres compromet la sécurité, il faut procéder rapidement à leur mise à jour. La mise à jour à distance des registres de multiples ordinateurs est tout aussi utile dans deux autres cas : pour appliquer un changement d’OS personnalisé à un ensemble de systèmes ou pour appliquer une entrée de registre supplémentaire contribuant au bon fonctionnement du logiciel.Quelle qu’en soit la raison, les mises à jour de registres centralisées sont de mise dans les réseaux de taille grande et moyenne.
Le Microsoft Resource Kit Group m’a récemment demandé d’écrire une série de scripts pour le « Best Practice Guide for Securing Active Directory Installations and Day-to-Day Operations : Part II », que l’on peut télécharger à http://www. microsoft.com/downloads/details.aspx?familyid=c0dbeb7e-d476-4498-9f6c-24974 fb81f1e&displaylang=en. L’un des scripts que j’ai écrits, ApplyReg.vbs, met à jour à distance les registres de multiples ordinateurs. Bien que l’on puisse employer l’utilitaire Reg avec le paramètre Add pour mettre à jour des registres à distance, Reg ne fonctionne que pour un ensemble limité de clés de registres. Ce n’est pas le cas d’ApplyReg.vbs qui n’impose aucune limite de clé. Le script applique les mises à jour de registres à la liste d’ordinateurs que vous avez fournie, puis crée un rapport indiquant si l’ensemble des mises à jour de registres de chaque ordinateur s’est bien effectué.
ApplyReg.vbs s’appuie sur plusieurs technologies : ActiveDirectory (AD), Active Directory Service Interfaces (ADSI), Windows Management Instrumentation (WMI), Windows Script Host (WSH) 5.6, et VBScript. (Si vous voulez utiliser un script Perl pour appliquer les mises à jour de registres, voir l’article « Vérifier les registres à distance », Windows & .Net Magazine juillet-août 2002, ou sur www.itpro.fr, pour l’utilisation de Perl dans ce contexte.) Nous allons voir comment se préparer pour ApplyReg.vbs (y compris la manière de tester le script), comment exécuter le script en production et comment il fonctionne.
Exchange 2000 SP3
Tous les produits traversent un cycle de vie d’intensité variable. Au début, le rythme de changement est rapide car les ingénieurs s’évertuent à ajouter des fonctions pour obtenir le meilleur produit. Au fil du temps, on ajoute moins de fonctions. Les ingénieurs corrigent des bogues, mais le produit se stabilise sous une forme qui perdure jusqu’au moment où l’on est prêt à lancer une nouvelle génération du produit. Et le cycle redémarre.Microsoft Exchange 2000 Server est la deuxième génération d’Exchange et il présente beaucoup de différences par rapport à la première (d’Exchange Server 4.0 à Exchange Server 5.5). Le Store est divisé en partitions, un nouveau moteur de routage SMTP remplace le MTA (Message Transfer Agent) basé sur X.400, et AD (Active Directory) offre des services de répertoire. Exchange 2000 Service Pack 1 (SP1) et SP2 affinent le produit en corrigeant des bogues apparus à l’usage et en ajoutant de nouvelles fonctions comme le Mailbox Manager en SP1 et un composant d’accès au répertoire réécrit (DSAccess) en SP2.
Lire l'article
