ADSI Query contre IIS n’est pas d’accord avec IIS Manager, sous Vista

Question

Utilisation de Vista ...

J'ai un script qui utilise ADSI pour définir ScriptMaps sur un site Web IIS. C'est javascript, exécuté dans cscript.exe, et le code ressemble à ceci:

var web = GetObject("IIS://localhost/W3SVC/1");
var maps = web.ScriptMaps.toArray();
map[maps.length] = ".aaa,c:\\path\\to\\isapi\\extension.dll,1,GET,POST";
web.ScriptMaps = maps.asDictionary();
web.SetInfo();

Lorsque je regarde dans le gestionnaire IIS après avoir exécuté le script, je peux voir la nouvelle entrée dans la liste des mappages de gestionnaires. Il porte un nom étrange & "AboMapperCustom-43155 &"; Je crois comprendre qu'il provient de la couche de compatibilité IIS7 pour ADSI.

Si, dans le Gestionnaire IIS, je supprime ensuite ces mappages de gestionnaires, puis exécutez un autre script ADSI pour interroger la propriété ScriptMaps, les ScriptMaps récupérés dans le script répertorient toujours l'entrée qui vient d'être supprimée. Les résultats du script ADSI ne concordent pas avec la liste de & Quot; Handler Mappings & Quot; indiqué dans le gestionnaire IIS.

Cela persiste même après un démarrage / arrêt d'IISADMIN et de W3SVC.

Ce comportement est-il attendu? ADSI est pris en charge en tant que & Mode de compatibilité & Quot; dans IIS7. Est-ce un artefact de cela?

Je pense que si le mappage de gestionnaires est supprimé de IIS MAnager, il est vraiment parti, même s'il est toujours renvoyé par une requête ADSI.

Quelqu'un peut-il apporter des éclaircissements à ce sujet?

Answer 1

Lorsque vous ajoutez une "scriptmap" en utilisant les bits de compatibilité ADSI (en utilisant le site Web par défaut pour des raisons d’argument), un mappage de gestionnaire est ajouté au fichier applicationHost.config du site à l’adresse

.

<location path="Default Web Site">
  <system.webServer>
    <handlers>
        <add name="AboMapperCustom-12345678" ... />
    </handlers>
  </system>
</location>

Lorsque vous supprimez le mappage du gestionnaire dans le gestionnaire IIS7, au lieu de le supprimer du fichier web.config et de la section présentée ci-dessus, un fichier Microsoft.Web.Administration est ajouté à la racine du site avec les éléments suivants:

<configuration>
  <system.webServer>
    <handlers>
        <remove name="AboMapperCustom-12345678" />
    </handlers>
  </system>
</configuration>

Lorsque vous obtenez la configuration d'un site Web à l'aide du nouvel <add/> .NET API géré, vous pouvez lire la configuration à différents niveaux, par exemple:

1: lisez la configuration au niveau <remove/> ou APPHOST

.

ServerManager serverManager = new ServerManager();
var site = serverManager.Sites.Where(s => s.Id == 1).SingleOrDefault();
Configuration siteConfig = serverManager.GetApplicationHostConfiguration();
ConfigurationSection handlersSection = 
     siteConfig.GetSection("system.webServer/handlers", site.Name);
ConfigurationElementCollection handlersCollection = 
     handlersSection.GetCollection();

foreach (var item in handlersCollection)
{
    Console.WriteLine(item.Attributes["name"].Value);
}

Dans l'exemple ci-dessus, même si vous avez supprimé le mappage, il sera toujours répertorié lors de l'itération de la collection de mappages du gestionnaire. Ceci parce que vous avez demandé la configuration au niveau de l'hôte de l'application. Tous les fichiers <=> présents dans la racine du site ou dans le répertoire inférieur ne seront pas lus et leurs directives de gestionnaire <=> et <=> ne seront pas incluses.

2: vous pouvez lire la configuration propre à un site (ou à un sous-dossier d'un site):

ServerManager serverManager = new ServerManager();
Configuration siteConfig = serverManager.GetWebConfiguration("Default Web Site");    
ConfigurationSection handlersSection = 
    siteConfig.GetSection("system.webServer/handlers");
ConfigurationElementCollection handlersCollection = 
    handlersSection.GetCollection();

foreach (var item in handlersCollection)
{
    Console.WriteLine(item.Attributes["name"].Value);
}

Ceci lira également le fichier <=> du site et renverra une liste de mappages de gestionnaires qui prend en compte les directives <=> et <=> spécifiées dans <=>.

C’est ce que fait le gestionnaire IIS7 lorsque vous affichez et modifiez des mappages de gestionnaires. Pour ajouter et supprimer des gestionnaires, créez (si nécessaire) un fichier <=> dans le dossier racine du site (ou des sous-dossiers) et ajoutez les éléments <=> et <=> requis à ce niveau.

La couche de compatibilité IIS6 semble fonctionner uniquement au niveau <=> APPHOST (option 1 ci-dessus), raison pour laquelle vous constatez ces différences.

Est-ce un bug? Je ne suis pas sûr que ce soit parce qu'ADSI, en fin de compte, n'était jamais au courant. MS devrait également ajouter une nouvelle méthode ou un nouvel indicateur pour vous permettre de spécifier le niveau auquel vous souhaitez réellement apporter ces modifications «scriptmap», ce qui peut impliquer de casser et de tester les composants ADSI, ce qui peut entraîner des erreurs. Le comportement permet de simuler la modification de l'ancienne métabase IIS6. <=> est en fait analogue à la métabase, ce qui vous permet de dire, à tort ou à raison, que c'est la bonne chose à faire.