Compatibilité de métabase avec IIS 7 et versions ultérieures

par Saad Ladki

Introduction

Le système de configuration dans IIS 7 et versions ultérieures est compatible avec les interfaces de configuration héritées au niveau de l’API. Il prend en charge l’interface ABO (Admin Base Objects), également appelée IMSAdminBase, ainsi que les fournisseurs ADSI et WMI basés sur ABO dans IIS 6.0. Les applications et les scripts existants peuvent toujours appeler ces interfaces programmatiques sur IIS 7.0 et versions ultérieures et continuer à fonctionner, tant que le composant de compatibilité metabase d’IIS est installé

Installation de la prise en charge de la compatibilité metabase

Vous trouverez ce composant dans la configuration sous Internet Information Services ->Web Management Tools -> fonctionnalité de gestion IIS 6.0.

Ce composant n’est pas installé par défaut, car IIS n’est pas initialement configuré pour l’utiliser. Les interfaces héritées présentent certaines limitations et ne sont pas idéales pour utiliser des fichiers de configuration distribués (voir la section Limitations ci-dessous) ; Il est donc recommandé que, au fil du temps, et surtout lors de l’ouverture du système de configuration pour une délégation plus et plus grande (c’est-à-dire des fichiers web.config avec des paramètres IIS dans ceux-ci sont présents sur le système), les clients envisageront de porter les scripts et applications hérités vers le nouveau système et ses interfaces.

Il est également recommandé de développer de nouveaux scripts et applications à l’aide des nouvelles interfaces, afin qu’ils fonctionnent idéalement avec le nouveau système et puissent avoir accès aux nouvelles propriétés, concepts et structure du système de configuration.

Lorsque tous les scripts et applications hérités sont portés vers les nouvelles interfaces, il est recommandé de désinstaller la fonctionnalité de compatibilité metabase.

Fonctionnement de la compatibilité metabase

La fonctionnalité de compatibilité de métabase s’exécute à l’intérieur du service Metabase (IISADMIN). Il intercepte tous les appels de méthode à ABO. Si les informations contenues dans l’appel de méthode sont liées à la configuration du serveur web, elles sont mappées au nouveau système. S’il est lié à la configuration FTP, SMTP ou NNTP, il suit la logique régulière du système Metabase et se termine dans le fichier Metabase.

Notez que même les propriétés personnalisées qui se trouvent dans la configuration du serveur web sont mappées à (et conservées dans) le nouveau système.

La décision de mappage est basée sur le nœud Metabase en question. La configuration du serveur web est généralement sous LM/W3SVC, y compris les propriétés personnalisées, avec quelques ajouts tels que Mime Maps.

Le mappage est effectué pour effectuer une traduction de retour et de retour entre la vue ABO et la nouvelle vue système. Par exemple, le nouveau système a un concept d’applications, sous chaque site et surtout tous les répertoires virtuels. Le système hérité gère les applications différemment : il s’agit simplement de répertoires virtuels avec une propriété spéciale pour les marquer comme applications (AppIsolated ou AppRoot).

Lors de l’appel d’ABO pour écrire la configuration du serveur web, le composant de compatibilité metabase conserve les données dans applicationHost.config. Cela est appelé « écriture directe », car les informations ne sont pas conservées en mémoire. Lors de l’appel d’ABO pour lire la configuration du serveur web, le composant de compatibilité metabase le lit à partir d’applicationHost.config. Cela est appelé « lecture directe », car les informations ne sont plus extraites de la mémoire.

Les données incomplètes qui ne sont pas prêtes à être consommées par le runtime du serveur sont conservées dans une section spéciale dans applicationHost.config, appelée customMetadata. Cette section est utilisée comme magasin persistant pour la fonctionnalité de compatibilité metabase, et les clients ne doivent jamais modifier son contenu. Un exemple de données incomplètes est le moment où le script hérité définit l’ID de site, mais pas les liaisons de site. Dans IIS 6.0, un tel appel aurait créé un objet de site non valide dans la configuration. Dans IIS 7.0 et versions ultérieures, elle est conservée dans la section, qui n’est pas consommée par le serveur. Si un appel ultérieur est effectué pour définir les liaisons de site, l’objet de site est considéré comme terminé et conservé dans son intégralité dans la section, où il sera récupéré par le runtime du serveur. Les données temporaires seront supprimées à ce stade, de sorte que l’utilisateur n’aura pas besoin de nettoyer les restes du système. Si un tel appel ultérieur n’est pas effectué, le runtime du serveur ne verra jamais ce site non valide, mais les scripts hérités l’auront dans la vue ABO, comme ils l’ont fait dans IIS 6.0. Du point de vue du script hérité, le système est entièrement compatible ici avec IIS 6.0.

Les propriétés de serveur web personnalisées définies par le biais de scripts hérités et d’applications sont toujours conservées dans la section. Ils peuvent être récupérés via l’interface héritée comme dans IIS 6.0, de sorte que le système est entièrement compatible. Évidemment, cela est très différent de la méthode recommandée pour étendre le système de configuration IIS, d’où une autre raison d’envisager de porter ces applications, au fil du temps, d’utiliser de nouvelles interfaces et de nouvelles fonctionnalités offertes par le système de configuration IIS 7.0 et versions ultérieures.

Autres données de configuration de métabase

Notez que la configuration FTP, SMTP et NNTP est toujours conservée dans le système metabase et n’a pas été transférée vers les nouveaux systèmes de configuration IIS. Les paramètres de configuration pour ceux-ci peuvent toujours être gérés via des interfaces programmatiques héritées et la modification directe du fichier metabase.xml.

Vue d’ensemble

La plupart des opérations sur les clés et propriétés metabase fonctionnent en toute transparence et l’utilisateur est présenté avec ces concepts et noms hérités, et non les nouveaux concepts IIS tels que les sections de configuration et les propriétés nommées (ABO continue de fonctionner avec les ID de propriété ; ADSI continue de fonctionner avec les noms de propriétés hérités.

Les utilisateurs hérités peuvent toujours utiliser le schéma ADSI et même l’étendre comme ils l’ont utilisé sur IIS 6.0.

Compatibilité des fichiers XML

La configuration du serveur web, y compris la configuration personnalisée qui étend le serveur web, est conservée dans system32\inetsrv\applicationHost.config, et non metabase.xml. Par conséquent, la prise en charge héritée est au niveau de l’API, et non au niveau du format de fichier (et c’est également pourquoi certaines fonctionnalités héritées ne sont pas prises en charge). L’appelant d’interface hérité obtient la « vue ABO » de la configuration comme elle l’a fait sur IIS 6.0, et non le nouveau format de fichier, le nommage ou les concepts.

L’une des implications est que les concepts tels que les ACL metabase ne sont pas pris en charge. Cela est dû au fait qu’ils sont étroitement liés au format de fichier Metabase. Le système de configuration IIS utilise des listes de contrôle d’accès de fichiers standard sur les fichiers de configuration. Le système ne fournit pas de mappage entre les listes de contrôle d’accès metabase et les listes de contrôle d’accès de fichier standard.

Les fonctionnalités telles que les fichiers d’historique, la sauvegarde/restauration et l’importation/exportation fonctionnent différemment, car elles s’appuient sur le nouveau système de configuration. Les appels ABO à la configuration de sauvegarde sont donc ignorés.

Fonctionnalités de métabase héritées

L’audit de configuration a été ajouté à IIS 6.0 dans Windows Server® 2003 Service Pack 1. Il n’est actuellement pas pris en charge par IIS 7.0 ou version ultérieure, car le nouveau système de configuration est conçu différemment (par exemple, IIS 7.0 et versions ultérieures utilisent le système de configuration in-proc, IIS 6.0 utilise un service NT dédié qui est encapsulé à partir du code utilisateur dans d’autres processus).

Propriétés de métabase héritées

Seules les propriétés héritées sont prises en charge. Les propriétés de configuration IIS 7.0 et ultérieures ne sont pas retournées à l’utilisateur hérité, et aucune des propriétés de configuration du .NET Framework n’est pas retournée.

Limitations de mappage

L’algorithme de mappage doit prendre en charge les différences entre les systèmes de configuration IIS 6.0 et IIS 7.0 et versions ultérieures. Par exemple, IIS 6.0 n’exigeait pas que les sites aient des noms (« commentaires serveur ») ; et s’ils ont été donnés des noms, il n’était pas nécessaire que ces noms soient uniques. Dans IIS 7.0 et versions ultérieures, chaque site doit avoir un nom unique. Par conséquent, le mappage de l’ancienne propriété ServerComment à la nouvelle propriété Name n’est pas trivial. L’algorithme de mappage force les noms à être uniques par site, car il s’agit d’une exigence du système de configuration IIS 7.0 et versions ultérieures ; il le fait en ajoutant des nombres aux commentaires du serveur pour créer unicité. Le résultat final est que la valeur définie pour le commentaire serveur est différente de celle spécifiée par le script.

Configuration distribuée

Seule applicationHost.config est prise en charge par la fonctionnalité de compatibilité metabase. La configuration dans les fichiers web.config n’est pas retournée à l’utilisateur hérité. Les balises d’emplacement sont utilisées dans applicationHost.config pour prendre en charge la configuration par URL.