Par Brett Hill
Toutes les mises à niveau du serveur web Microsoft semblent s'accompagner du passage à un nouvel OS. Il n'est donc pas étonant que tant d'ateliers Microsoft IIS 4.0 veuillent garder le status quo. Cependant, la version 5.0 semble présenter certains avantages ...
Tout d'abord, IIS 5.0 n'est plus un territoire inconnu. La version a fait ses preuves face à de gros volumes dans des entreprises comme Microsoft, Dell, Nasdaq et Ford Motor. Ensuite, IIS 5.0 est plus sûr et plus stable (particulièrement après l'installation de IIS 5.0 Service Pack 2 - SP2), plus rapide, et plus riche en fonctions que IIS 4.0. Enfin, comme IIS 5.0 ne fonctionne que sur Windows 2000, en migrant on obtient aussi les avantages de cet OS, du point de vue sécurité et stabilité. Quatrième et dernier point - et le plus déterminant - Microsoft ne va pas maintenir le bateau à l'arrêt pour vous : elle a fixé le cap sur IIS 6.0. Bien sûr, vous pourriez garder l'installation IIS 4.0 jusqu'à ce que les packs de service IIS 6.0 commencent à apparaître, mais en retardant ainsi la migration, le saut technologique sera plus important et compliquera les choses. (Pour un aperçu de quelques-unes des améliorations de IIS 6.0, voir l'encadré intitulé « IIS 6.0 : la prochaine génération »). Il vaut donc mieux passer dès à présent à IIS 5.0 et simplifier ainsi le passage ultérieur à IIS 6.0.Des études menées par Netcraft ont révélé que, bien que des milliers d'organisations utilisent encore IIS 4.0, le nombre de sites Web actifs qui utilisent IIS 5.0 sur Win2K a augmenté. Si votre site envisage une migration, il semble que le moment soit venu. Ceux qui se posent des questions sur le passage de IIS 4.0 à IIS 5.0 trouveront des réponses dans l'encadré « Questions fréquentes (FAQ) sur la migration d'IIS ».
Une fois la décision de basculement prise, il faut choisir une stratégie de migration (c'est-à -dire une mise à niveau sur place ou une mise à niveau par migration). Il faut aussi analyser les avantages et les inconvénients des diverses méthodes de migration d'une machine Windows NT sous IIS 4.0 à une machine Win2K sous IIS 5.0. Il faut réfléchir à tous les aspects de la migration, y compris la transition des utilisateurs et des groupes, le contenu Web (c'est-à -dire les fichiers HTML, les ASP (Active Server Pages) et les fichiers graphiques que le serveur Web délivre), la structure du serveur Web, les bases de données IIS, les certificats, et les applications Web. Pour conserver la maîtrise de la migration, il faut bien connaître les idées reçues erronées et les problèmes potentiels.
Comme IIS est lié inextricablement à l’OS, le passage à IIS 5.0 (ou à IIS 6.0 quand il arrivera) suppose l’adoption d’un OS entièrement nouveau. Et ce n’est pas une petite affaire. Il existe deux méthodologies : une mise à niveau sur place (aussi appelée mise à niveau directe) ou une mise à niveau par migration. Dans le premier cas, on charge simplement Win2K sur le serveur NT 4.0 existant et on suit les indications d’installation pour mettre à niveau l’OS existant. Pour effectuer une mise à niveau par migration, on installe Win2K sur un serveur séparé avec un disque dur nouvellement formaté, puis on migre le contenu et la configuration IIS du serveur NT 4.0 sur le nouveau serveur.
Mise à niveau sur place. La mise à niveau directe de NT 4.0 et IIS 4.0 à Win2K et IIS 5.0 est commode. Comme on ne change pas de machines, on n’a pas à se soucier de la migration des utilisateurs et des groupes locaux, des autorisations NTFS, des connexions ODBC, des certificats, de la structure de serveur Web, des applications Web ou des autorisations basées sur le Web (que l’on définit au moyen de la console Microsoft Management Console – MMC – Internet Information Services). Mais la commodité a un prix : si le serveur IIS 4.0 est en service depuis longtemps, une mise à niveau sur place entraîne des années d’historique accumulées : registres accumulés, profils utilisateurs périmés, patches de sécurité obsolètes, installations de logiciels bâclées, etc. Ces débris numériques ne peuvent que compliquer une mise à niveau par ailleurs rapide et simple.
Les mises à niveau sur place peuvent également laisser perdurer des défauts de sécurité dont l’existence était peut-être inconnue sur le système NT 4.0. Ce type de migration préserve les utilisateurs, les groupes, et les autorisations NTFS associés ; par conséquent, si l’on n’examine pas d’abord ces points particuliers, les mots de passe faibles, les comptes périmés, et les autorisations inappropriées peuvent se glisser dans la migration. Pis encore, on pourrait refuser sans le savoir des améliorations de sécurité propres à IIS 5.0. C’est ainsi qu’une mise à niveau directe conserve la vulnérabilité Absent Directory Browser Argument. Autre risque de sécurité potentiel : le répertoire virtuel IISADMPWD, que IIS 4.0 installe par défaut et qui pointe sur les fichiers .htr dans le répertoire C:\winnt\system32\inetsrv\iisadmpwd. Des utilisateurs malicieux peuvent utiliser ces fichiers pour modifier les mots de passe des comptes utilisateurs et causer d’autres dégâts. (Pour plus d’informations sur ces vulnérabilités, voir l’encadré « Articles de Microsoft à propos des vulnérabilités d’IIS 4.0 »). Des installations nettes d’IIS 5.0 n’installent pas le répertoire virtuel IISADMPWD pendant la configuration (setup), réduisant ainsi le risque de voir quelqu’un mal utiliser les fichiers .htr. (Pour plus de détails, voir l’article de Microsoft « IISADMPWD Virtual Directory Is Not Created During Clean Install of IIS 5.0 » à l’adresse http://support .microsoft.com/support/kb/articles/q269/0/82.asp). Toutefois, une mise à niveau sur place conserve le répertoire déjà installé.
Malgré ces inconvénients, on peut estimer que la commodité d’une mise à niveau sur place est plus importante qu’un démarrage de zéro sur un nouvel OS. Par exemple, des installations IIS relativement simples sans configurations complexes se prêtent bien à une mise à niveau sur place. Comme Microsoft a testé intensivement ce genre de mises à niveau de IIS 4.0 à IIS 5.0, ces opérations se passent souvent sans ennui. Mais si des problèmes se présentent, leur détection peut être plus difficile que pendant une mise à niveau par migration.
Si vous choisissez la mise à niveau sur place, assurez-vous d’abord qu’il existe au moins deux bonnes sauvegardes d’image du système existant. Mieux encore, faites deux sauvegardes en utilisant la méthode de sauvegarde primaire (image d’unité (drive imaging), par exemple) et une troisième sauvegarde par une méthode différente (sur bande, par exemple). Ainsi, si le processus d’image ne se passe pas bien, vous aurez encore une sauvegarde.
Mise à niveau par migration. Passer à une installation Win2K et IIS 5.0 propre et nette est la meilleure méthode de migration. C’est en tout cas celle qui donne le serveur Web IIS 5.0 le plus stable et le plus sûr possible. Ce genre de migration nécessite davantage de planning et de migration des composants individuels comme les comptes utilisateurs et groupes, les mots de passe NTFS, la structure de serveur Web (sites Web virtuels, répertoires virtuels, par exemple), les bases de données, les certificats, et les applications Web. Cependant, dans le processus de planification, vous trouverez probablement des moyens d’améliorer la sécurité, l’administration et les performances du serveur Web. Pour chaque composant à faire migrer, je propose des recommandations et des mises en garde qui faciliteront la mise à niveau et vous aideront à créer une installation IIS 5.0 stable et sûre.
Mais avant de commencer à déplacer ces composants individuels, il est bon de supprimer les éventuelles Microsoft FrontPage Server Extensions existantes des sites Web et du serveur NT Web, particulièrement si l’on migre également de FrontPage 98 à FrontPage 2000 ou ultérieur. (Ces extensions peuvent s’avérer délicates.) Par défaut, Win2K installe le FrontPage Server Extensions 2000, de sorte que, après avoir effectué la migration à IIS 5.0, on puisse réinstaller les extensions sur les sites Web. Le respect de cette procédure garantit que les clients de FrontPage 2000 ou antérieur peuvent accéder aux sites Web validés pour FrontPage après la migration. Quelle que soit la méthode de migration, il faut mettre à jour FrontPage Server Extensions avec la release de service la plus récente, téléchargeable à http://msdn.microsoft.com/workshop/c-frame.htm#/workshop/languages/fp/default.asp.
Téléchargez cette ressource
Guide inmac wstore pour l’équipement IT de l’entreprise
Découvrez toutes nos actualités à travers des interviews, avis, conseils d'experts, témoignages clients, ainsi que les dernières tendances et solutions IT autour de nos 4 univers produits : Poste de travail, Affichage et Collaboration, Impression et Infrastructure.
