Questions générales sur IIS 7.0

manuellement.

L’impact dépend de la charge du serveur. Si vous effectuez 10 000 requêtes/secondes, vous manquerez fréquemment la mise en cache du noyau ; toutefois, si vous effectuez 100 demandes/seconde, vous ne le remarquerez probablement pas. Il dépend fortement du contenu servi, IIS 5.0 n’avait pas de composant de mode noyau et fonctionnait bien pour la plupart des clients.

Il existe une prise en charge de ruby de base. Pour plus d’informations, consultez le lien suivant :

http://mvolo.com/10-steps-to-get-ruby-on-rails-running-on-windows-with-iis-fastcgi/

Si vous effectuez l'installation via l'interface graphique du gestionnaire de serveur (« Ajouter des fonctionnalités »), l'ordre d'installation n'a pas d'importance. L’Assistant Ajout de fonctionnalités vérifie toutes les dépendances et vous alerte si vous manquez des modules requis. En outre, l’Assistant Ajout de fonctionnalités connaît l’ordre correct des modules.

Si vous effectuez l’installation à partir d’une ligne de commande ou à l’aide d’une installation sans assistance, l’ordre des modules n’a pas d’importance (là encore, le programme d’installation connaît l’ordre correct des modules), mais vous êtes responsable de l’identification de toutes les dépendances. Si vous ne parvenez pas à inclure une dépendance requise, le programme d’installation de ligne de commande sans assistance échoue.

Un pool d’applications qui sert uniquement des fichiers statiques avec toutes les fonctionnalités installées aura une empreinte de 3 Mo d’octets privés, 5 Mo de fichier de page. (Il s’agit d’une taille supérieure à IIS 6.0). Windows Server 2008 gère plusieurs pools d’applications mieux que WS03. Lorsque des requêtes ASP.NET sont effectuées, nous préchargeons une petite partie du CLR pendant le démarrage (~100 kb). Le préchargement est configurable par une propriété sur ApplicationPool. Elle s’appelle managedRuntimeVersion. Le reste du CLR (~8 mb) sera chargé sur la première requête ASPX.

Access fonctionne uniquement dans les pools d’applications 32 bits. Le chargement du profil utilisateur (propriété loadUserProfile sur AppPool) est problématique lors de l’utilisation d’ASP classique car Access utilise le répertoire temporaire qui n’autorise pas l’accès à l’utilisateur anonyme lorsque le profil utilisateur est chargé.

L’édition web de Windows Server 2008 a été grandement améliorée et nous nous sommes concentrés sur la suppression des limites artificielles. La licence finale n’est pas encore terminée mais nous prévoyons de supprimer toutes les restrictions matérielles, d’autoriser les processeurs 4x et 32 Go de RAM (sur x64). SQL est autorisé et SharePoint sera installable sur la référence SKU.

FPSE ne fait plus partie de Windows Server. Nous travaillons avec un tiers pour créer un package de téléchargement pour que FPSE s’exécute sur Windows Server 2008/IIS 7.0. Il n’a pas de nouvelles fonctionnalités ou d’améliorations mais uniquement des correctifs pour le rendre compatible.

Nous recommandons d'installer une nouvelle version de Windows Server 2008 et de migrer vers cette version, ou de placer les nouveaux clients sur de nouveaux serveurs. Nous suggérons qu’une liste bien gérée des composants et configurations tiers soit documentée pour chaque serveur, afin que l’environnement actuel puisse être répliqué sur le nouveau serveur. Consultez les recommandations du document d’hébergement partagé pour la configuration du pool d’applications et du site. Un outil pour faciliter la migration sera publié prochainement.

Les mises à niveau sur place sont prises en charge dans les cas suivants :

• Windows Server 2003 peut être mis à niveau vers WS2K8 Beta3, WS2K8 RC0, WS2K8 RC1 et WS2K8 RT
• Windows Server 2008 Beta3 peut être mis à niveau vers WS2K8 Beta3 et WS2K8 RC0
• Windows Server 2008 RC0 peut être mis à niveau vers WS2K8 RC0, WS2K8 RC1 et WS2K8 RTM
• Windows Server 2008 RC1 peut être mis à niveau vers WS2K8 RC1 et WS2K8 RTM

Si le serveur est en mode Configuration partagée, il doit être rétabli en configuration autonome avant l’exécution de la mise à niveau. Pour ce faire, désactivez la configuration partagée, copiez les clés applicationhost.config et les clés chiffrées sur l’ordinateur local, exécutez la mise à niveau sur chaque serveur puis réactivez la configuration partagée.

Les fichiers journaux que le programme d’installation écrit et les iis7.log sont toujours activés. Il n’y a pas de granularité sur ce qui est journalisé.

Nous ne fournissons aucun moyen de configurer des modules autres que les modules Windows lors de l’installation. Il peut y avoir un moyen d’exécuter une configuration générique sans assistance pour exécuter quelque chose après l’installation, et dans ce cas, un utilisateur peut effectuer du codage.

Le suivi de toutes les requêtes à <1 000 requêtes/seconde doit être de <5 % du processeur. Il est possible de configurer une règle de suivi globale pour tous les sites. Le suivi peut être activé pour tous les sites en modifiant la section <siteDefaults>.

Non, mais il existe un recyclage basé sur la mémoire qui recycle les AppPools qui dépassent les limites de mémoire configurées.

Chiffrements effectués avant la perte de sysprep après sysprep. Il n’existe aucune possibilité pour contourner ce problème.

Vous pouvez exporter les clés de l’ordinateur et les importer dans tous les serveurs afin que le déchiffrement fonctionne. L’interface utilisateur du serveur bêta 3 inclut une fonctionnalité appelée Configuration partagée qui vous permettra de le faire. Cliquez sur Exporter... et pour chiffrer les clés de l’ordinateur, copiez-les avec applicationHost.config et administration.config dans un chemin d’accès. Ensuite, à partir de tous les autres ordinateurs, vous pouvez sélectionner « Importer... » et cela importera les clés de l’ordinateur et pointera la configuration vers la configuration partagée.

Différents AppPools peuvent avoir des valeurs différentes pour ce paramètre. Les applications peuvent être affectées à différents AppPools

Le fichier par défaut pour la gestion de cette erreur est contenu dans \inetpub\custerr\en-us. Le pied de page de l’erreur contient « Server Version Information : Internet Information Services 7.0 », qui peut bien sûr être supprimé ou modifié directement à partir du fichier .htm.

L’API managée (Microsoft.Web.Administration) a accès à tous les paramètres que l’API native effectue et prend en charge la communication à distance DCOM à l’aide de la méthode statique ServerManager.OpenRemote. Vous pouvez définir n’importe quel paramètre de configuration, mais pour la version bêta 3, il n’existe aucune prise en charge des informations d’exécution telles que l’état d’un AppPool ou la liste des requêtes ou workerprocess.

Dans les versions précédentes d’IIS, vous deviez contrôler l’accès via les listes de contrôle d’accès du système de fichiers. Cela est fastidieux et il n’y a pas d’interface web pour le faire. Avec l’autorisation d’URL, vous pouvez contrôler l’accès aux URL à l’aide de l’interface utilisateur IIS ou à l’aide de web.config directement. En outre, vous pouvez utiliser des identités autres que Windows, par exemple les utilisateurs d’appartenance et les rôles fournis par l’authentification par formulaire.

Toutes les données de la section applicationPool pertinentes pour ce pool d’applications (par conséquent, dans applicationPoolDefaults ou spécifiques à ce pool d’applications) entraînent la recyclage de WAS. Le processus Worker peut demander au WAS de recycler les pools d’application en fonction de certains changements de configuration. Actuellement, le seul pour lequel nous le faisons est globalModules, mais ce n'est pas une liste fermée (car les modules peuvent demander un recyclage en fonction d'un changement de configuration).

L’équilibrage de la charge réseau fait partie de Windows Server 2008. Il est essentiellement identique à celui de Windows 2003. Pour installer l’équilibrage de la charge réseau, allez dans Gestionnaire de serveur >« Ajouter des fonctionnalités »>, puis sélectionnez « Équilibrage de la charge réseau » dans la liste. Pour configurer l’équilibrage de la charge réseau, vous devez ouvrir une invite de commandes et exécuter nlbmgr. Il s’agit de la même interface utilisateur que dans Windows 2003.

Si le processeur à l’échelle du système dépasse un seuil dynamique, la compression cesse de se produire, ce qui libère le processeur qu’elle utilise. Si le processeur à l’échelle du système tombe en dessous d’une autre limite, la compression dynamique reprend, ce qui permet d’économiser de la bande passante.

Les utilisateurs ont des avis différents sur l'utilisation optimale de l'unité centrale. Certains pensent qu’une moyenne de 20 % est parfaite, d’autres penchent pour 75 %. Si vous souhaitez X et que vous êtes constamment au-dessus de X, vous pouvez également supprimer complètement la compression dynamique car elle ne sera jamais utilisée.

Elle prend en compte l’utilisation moyenne sur la fenêtre de 30 secondes depuis le dernier échantillon. Par conséquent, même avec des pics irréguliers, vous aurez une compression dynamique pendant maximum 30 secondes après le pic, et si vos pics sont instantanés (et donc n’affectent pas beaucoup l’utilisation moyenne du processeur sur 30 secondes), ils n’affecteront pas la compression dynamique.

Définir loadUserProfile=false dans applicationPoolDefaults est une bonne idée pour les scénarios d’hébergement partagé. Le temps de démarrage d’un AppPool sera beaucoup plus rapide et vous éviterez tout problème d’autorisation d’annuaire temporaire.

L’erreur 500.19 est due au mode de délégation de fonctionnalité IIS 7.0. Lorsqu’une fonctionnalité est déléguée aux propriétaires de site et que les propriétaires de site modifient la fonctionnalité, leurs modifications sont conservées dans web.config. Si l’administration du serveur révoque la gestion déléguée sur cette fonctionnalité, le propriétaire du site web a la responsabilité de nettoyer les détails de la fonctionnalité à partir de web.config. Dans le cas contraire, tous les sites qui avaient modifié cette fonctionnalité déléguée affichent immédiatement un message « Erreur Http : 500.19 : Erreur du serveur interne ». Pour éviter ce problème, nous vous recommandons de ne pas révoquer les fonctionnalités déléguées une fois publiées pour les clients finaux.

Si le site hébergé n’a pas de web.config, IIS 7.0 en crée un. Si le site a un web.config, IIS 7.0 le modifie. Si le fichier web.config est modifié, les propriétaires de site ont la responsabilité de fusionner les modifications et de s’assurer que les modifications sont fusionnées et conservées manuellement.

L’installation du service de gestion ne modifie en aucun cas AppHost.config ou Administration.config. Les seules modifications qui doivent apparaître sont les nouveaux fichiers binaires (wmsvc.exe). Un certificat d’auto-signature sera créé et quelques clés de Registre seront ajoutées. Cela signifie que, en théorie, rien ne devrait s’arrêter.

La plupart du temps, il fonctionne hors de la boîte de dialogue, car nous utilisons les paramètres redirection.config pour lire apphost/admon.config. Toutefois, si l’on répond à cette question avec plus de détails, cela dépend des scénarios que vous utiliserez :

• Configuration partagée à l’aide du contenu local : les utilisateurs Windows ou IIS réguliers se connectent pour modifier leur contenu local et leurs web.config. Il n’y a rien à faire, tout doit fonctionner hors de la boîte de dialogue.
• Configuration partagée à l’aide du contenu distant à l’aide des utilisateurs Windows : elle doit fonctionner, à condition que les comptes Windows aient accès à leur contenu.
• Configuration partagée à l’aide du contenu distant à l’aide des utilisateurs IIS : pour ce scénario, vous devez modifier l’identité du service (WMSVC) en un compte qui a accès au contenu distant car l’identité de processus est utilisée pour accéder au contenu. Notez que apphost.config/admon.config fonctionnera car nous utilisons redirection.config
• Administrateur Windows gérant une connexion serveur : il doit fonctionner, à condition que votre administrateur Windows dispose d’un accès en écriture à la configuration partagée.

Consultez le lien suivant pour plus d’informations sur la création de sites dans IIS 7.0.

Un pool d’applications qui sert uniquement des fichiers statiques avec toutes les fonctionnalités installées occupe 3 Mo d’octets privés, soit 5 Mo de fichier de page. Lorsque des requêtes ASP.NET sont effectuées, nous préchargeons une petite partie du CLR pendant le démarrage (~100 kb). Le préchargement est configurable par une propriété sur ApplicationPool. Elle s’appelle managedRuntimeVersion. Le reste du CLR (~8 mb) sera chargé sur la première requête ASPX.

Http.sys crée automatiquement ces dossiers s’ils n’existent pas. Si vous remplacez les autorisations par un autre élément, elle doit conserver les nouvelles autorisations.

Nous l’avons testé en interne et il semble fonctionner correctement si ISAPI et Metabase sont installés. Il existe également des blogs en ligne qui donnent des instructions sur la manière de procéder. Pour plus d’informations, consultez le lien suivant :

https://blogs.iis.net/bills/archive/2007/03/06/coldfusion-on-iis7.aspx.

Le serveur est configuré en mode création de compte AD. Le mode de création AD est une fonctionnalité déconseillée qui est toujours prise en charge, mais qui sera supprimée dans V4. Au lieu d’autoriser WSS à créer automatiquement des utilisateurs dans AD, il est recommandé d’effectuer l’approvisionnement d’utilisateurs en dehors de WSS.

Pour plus d’informations sur la configuration globale centralisée, consultez : Le système de configuration dans IIS 7.0

Il n’existe actuellement aucun FPSE pour x64. Notre hébergement recommandée pour l’hébergement partagé est un système d’exploitation 64 bits avec appPools 32 bits. Malheureusement, il existe actuellement un bogue qui empêche l’installation de FPSE sur 64 bits pour ce scénario.

Vous pouvez re armer votre système trois fois en effectuant les étapes suivantes :

Pour exécuter slmgr /rearm, ouvrez regedit.exe et accédez à HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL. Vérifiez que la valeur « skiprearm » est définie sur « 0 ». Si cette valeur n’est pas définie sur zéro, la fonction re-arm ne réinitialise pas les minuteurs d’activation du système.

Après avoir vérifié que la valeur de Registre « skiprearm » est égale à zéro (0), exécutez slmgr /rearm à partir d’une invite de commandes avec élévation de privilèges. Attendez le message indiquant que le processus s’est terminé. Cela peut prendre une ou deux minutes. Une fois terminé, suivez l’invite pour arrêter l’ordinateur. Lors du redémarrage, l’ordinateur s’exécute dans OOB Grace et aura 30 jours supplémentaires pour s’activer. Ce processus n’apporte aucune autre modification au système.

IIS. CertObj COM-object est toujours présent dans IIS 7.0 et nous pensons qu’il reste la meilleure option pour déployer des certificats sur plusieurs serveurs web. Ce comportement de composant reste le même, donc tous les anciens scripts doivent fonctionner (si ABOMapper est activé).

set iiscertobj = CreateObject("IIS.CertObj")

iiscertobj.InstanceName = "0.0.0.0:443"

iiscertobj. Importer pfxfile, pfxfilepassword, true, true

Un tel script ne dépend pas d’ABOMapper.