Blog de l'équipe support IIS France -- French IIS Support Team Blog

Windows could not configure one or more system components: when upgrading from Windows 7 to Windows 8

2013-04-12T08:27:00Z

Last weekend I wanted to upgrade my home workstation from Windows 7 Utimate to Windows 8 Professional, so that I could benefit from using the new Windows 8 Hyper-V client for my virtual machines.

I chose to do an in place upgrade from Windows 7 to Windows 8, as I had already done before on other machines, keeping all my applications and my documents. This process works very well, and even apps that would not install on Windows 8 migrate without any problems from Windows 7 to Windows 8.

But when I tried to upgrade to Windows 8 I had the following behavior:

I had the 'Installing Files _%' screen complete all the way to 100%
I had the 'Configuring Components _%' screen also complete all the way to 100%

Following this I received the following cryptic error message:

Windows could not configure one or more system components. To install Windows, restart the computer and then restart the installation.

Clicking OK would roll back the Windows 8 upgrade, reboot the machine and restore it to its previous Windows 7 self.

The rest of this article deals with the how and why you might get this behavior. If you are not interested in the nitty gritty, just go down to the solution part to fix it.

So what just happened?

After spending some time looking into the matter, I was able to find out that Windows keeps a setup log (which was expected) in which it logs all the operations it attempts during the in place upgrade. The log file can be found at the following location:

C:\$Windows.~BT\Sources\panther\setupact.log

The log is not appended to, so each new attempt to upgrade from Windows 7 to Windows 8 will wipe away the old log and create a new one in its place.

Towards the end of this log, I was able to find, towards the end of the log, information that the installer was trying to install IIS 8. Searching for system32\inetserv\iissetup.exe from the bottom of the file upwards should do the trick to help you find the line. If you inspect the log file around these lines, you will see the setup tries to perform several operations for the install of IIS, all of which fail, and then the installer decides to roll back the installation all together. Hence the 'system component' that could not be configured is IIS.

Now that we know this, the question becomes why does the configuration fail? Furthermore, I did not even have IIS installed on my machine, I only had Visual Studio 2010 for Windows Phone development installed. Hence, removing IIS from the machine was not possible, since there were no IIS components physically present.

The next thing to try is to install IIS on the machine and see if this fails. And indeed after going through the IIS setup via the Windows Package Manager (Control Panel – Turn Windows Components on and off interface) I was able to see that IIS installation was indeed failing, even when I tried to install under Windows 7.

What not many people know is that IIS relies on the Windows CBS – Component Based Setup and Servicing system, which is built into the OS, to install and uninstall packages. Basically, an IIS installation just asks CBS to deploy certain installation packages to the OS. The installer also keeps a detailed install log, which can be found here:

C:\Windows\IIS7.log

Contrary to the Windows 8 upgrade log, this log gets appended to, and will contain all installation and uninstallation attempts you perform in chronological order.

Looking through the log for the keyword <!!FAIL!!>, I was quickly able to spot information indicating that the instantiation of AESProvider had failed.

[04/05/2013 19:33:37] Set ACLs on NetFrameworkConfigurationKey
[04/05/2013 19:33:37] iisWasKey key container already exists
[04/05/2013 19:33:37] Created iisWasKey user key
[04/05/2013 19:33:37] iisConfigurationKey already exists
[04/05/2013 19:33:37] iisConfigurationKey already exists
[04/05/2013 19:33:37] < !!FAIL!! > Generating AesProvider (result=0x8009000d)
[04/05/2013 19:33:37] < !!FAIL!! > Install of component SharedLibraries result=0x8009000d
[04/05/2013 19:33:37] < !!FAIL!! > COMPONENT::ExecuteCommand result=0x8009000d

AES is an encryption provider that IIS uses to encrypt sensitive data in the configuration files using specific RSA machine keys from Windows.

If the machine keys that IIS uses to encrypt the configuration store using the AESProvider are somehow corrupted, then the provider instantiation will fail, and the install will fail. Since the Window 8 installer also tries to install IIS, and this fails, the upgrade fails and is rolled back.

The solution:

The RSA machine keys in Windows 7 and Windows 2008 are found at the following location:

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

The ACLs (access control lists) for the IIS keys are incorrect, hence the failure. The keys in question are the following (files starting with the numbers indicated and ending in the machine's GUID):

6de9cb26d2b98c01ec4e9e8b34824aa2_GUID      iisConfigurationKey
d6d986f09a1ee04e24c949879fdb506c_GUID      NetFrameworkConfigurationKey
76944fb33636aeddb9590521c2e8815a_GUID      iisWasKey

The easiest solution is to remove the files from the folder, as new ones will be re-created the next time you try and install IIS. This allows the IIS installation to succeed, and hence, it allows the upgrade to complete successfully.

By Paul Cociuba
www.linqto.me

IIS 7/7.5 et la génération d’un log Handle suite à une erreur 500 provoquée par un lock que personne ne semble détenir

2013-01-14T13:46:00Z

Au cours d'un incident, nous avions un lock qui générait une erreur 500 alors que personne ne semblait détenir ce lock. Pour investiguer ce problème il nous a fallu automatiser la génération d'un log Handle sur un fichier spécifique. En théorie, cela est fort simple. Le lock provocant une erreur 500, je n'avais qu'à me baser sur l'article suivant pour exécuter l'utilitaire Handle.exe lorsqu'une erreur 500 est remontée :
http://blogs.msdn.com/b/friis/archive/2010/05/07/utiliser-freb-pour-g-n-rer-un-dump-sur-une-requ-te-longue-en-ex-cution.aspx
En pratique, cela est bien plus complexe qu'il n'y parait… Voici la marche à suivre détaillée :

Positionnement de "Handle.exe" et des scripts nécessaires à la génération du log Handle :

A la fin de cet article, vous trouverez une archive nommée "handle.zip"
Décompressez l'archive. Vous obtenez un dossier Handle à positionner sur "C:\"

Configurer une règle FREB sur le site impacté pour générer une trace sur des erreurs 500 :

Pour ce faire, vous pouvez suivre le plan d'action fourni à l'adresse suivante :
http://blogs.msdn.com/b/friis/archive/2010/04/29/le-fonctionnement-de-freb-ou-comment-investiguer-une-erreur-http-sous-iis-7-7-5.aspx

Après cette étape, le fichier Web.config de votre site devrait contenir les éléments suivants :

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <tracing>
            <traceFailedRequests>
                <add path="*">
                  <traceAreas>
                        <add provider="ASP" verbosity="Verbose" />
                        <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" />
                        <add provider="ISAPI Extension" verbosity="Verbose" />
                        <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression,Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" />
                    </traceAreas>
                  <failureDefinitions statusCodes="500" />
                </add>
            </traceFailedRequests>
        </tracing>
    </system.webServer>
</configuration>

Configurer l'ApplicationHost.config pour l'autoriser à exécuter un script à la place d'une trace FREB :

Ouvrez une invite de commande CMD en tant qu'administrateur et naviguez vers le répertoire "C:\Windows\System32\inetsrv"
Exécutez la commande suivante :

appcmd.exe set config -section:system.applicationHost/sites "/[name='NomDeVotreSite'].traceFailedRequestsLogging.customActionsEnabled:"true"" /commit:apphost

Remarque : Pensez à remplacer NomDeVotreSite dans "/[name='NomDeVotreSite'] par le nom réel du site qui est impacté.

Modifier le fichier Web.config de votre site afin d'indiquer à IIS quel script exécuter à la place de la trace FREB :

Ouvrez le fichier Web.config et remplacez la section <add path="*"> par la ligne suivante :

Changez l'identité de l'application pool à "Local System" :

Pour que le script puisse fonctionner, il faut que l'application pool tourne avec un compte ayant des privilèges élevés. Nous allons donc configurer l'application pool pour utiliser le compte "Local System" qui remplira parfaitement ce rôle. Je vous recommande toutefois de tester cette modification avant de la mettre en place sur un serveur de production.

Ajustez les droits de ce compte :

Pour permettre au compte "Local System" d'exécuter Handle.exe il faut lui donner les droits de chargement et déchargement des pilotes de périphériques.
Pour ce faire :
Ouvrez la MMC correspondant à la "Stratégie de sécurité locale" en passant via les outils d'administration
Sous "Stratégies locales > Attribution des droits utilisateur" ajoutez le compte "Local System" à la stratégie "Charger et décharger les pilotes de périphériques"

Testez la génération de la trace Handle

Pour tester le bon fonctionnement de la règle et de la génération du log Handle, vous pouvez ouvrir le fichier Web.config et modifier la ligne <failureDefinitions statusCodes="500" /> par <failureDefinitions statusCodes="100-500" />. Ceci vous permettra de générer un log quelque soit le code retour HTTP. Un log devrait alors apparaitre dans le répertoire C:\Handle portant comme nom la date et l'heure correspondant au moment de la génération du log. Si cela ne fonctionne pas, n'hésitez pas à exécuter un IISRESET et à refaire le test. Pensez à remettre la valeur normale après avoir testé la génération du script.

Modifiez le script "handlefreb.bat"

Ce script génère actuellement un log handle sur le répertoire "C:\handle".
Il va donc nous falloir le modifier pour générer la trace handle sur le bon répertoire
Pour ce faire :
Ouvrez le script avec notepad et allez à la dernière ligne qui devrait être la suivante :

c:\Handle\handle.exe -a -u -accepteula "C:\handle" > c:\handle\%_date%_%_time%.log

Modifiez la partie en jaune ci-dessus par le répertoire que vous souhaitez surveiller

Les fichiers seront générés dans le répertoire C:\Handle pour des raisons de simplicité.

En espérant que cet article vous sera utile.
Sylvain Lecerf & L'équipe du Support IIS Microsoft France

Cannot complete the installation of a certificate on IIS. Error "The signature of the certificate cannot be verified" 0x80096004

2013-01-14T13:45:00Z

J'ai récemment travaillé sur un problème d'installation d'un certificat Web Serveur dans IIS qui produisait l'erreur "la signature du certificat n'a pas pu être vérifiée".
De prime abord le certificat racine semblait être correctement installé et l'interface CertMgr ne montrait pas de problème particulier.
Après une inspection plus minutieuse nous nous sommes aperçus que le client avait au final deux root CA sur le serveur Certsrv, un expirant en 2014 et l'autre en 2016. Le certificat du serveur IIS a été généré via le root CA de 2016 alors que seul le root CA de 2014 était installé sur le serveur IIS.
La solution est donc d'importer le root CA expirant en 2016 sur le serveur IIS.

En espérant que cet article vous soit utile.
Sylvain Lecerf & L'équipe du Support IIS Microsoft France

When wrong permissions affect cipher being used for TLS connection

2013-01-14T08:47:18Z

The information from this blog POST has been compiled with the help of the following engineers:

Daniel JUE – SNCF
Mathieu CLAUDEL – KNS
Marc BOUCHARD - Microsoft Corporation

I recently worked on an interesting SSL issue which manifests itself by the inability to negotiate a TLS connection using RSA with 2048 bits key exchange when connecting to a specific set of IIS 7.5 servers. The problem's symptoms were different depending on the client computer and browser version used:

On a client computer running Windows 7 and Internet Explorer 9, SSL connection could be established but only using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) cipher suite. Under Internet Explorer's File/Properties menu, the following details were provided:

The same client could connect without any problem to any other IIS server using TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) which could be checked in Internet Explorer:
On a client computer running Windows XP with IE6, SSL connection could just not be established and the generic "Page cannot be displayed" error was shown : the XP client was simply failing during the SSL handshake

Since the issue was only affecting a couple of servers, we first though the problem was due to bad configuration and we started to check if specific cipher suites were disabled on the affected servers (see How to Restrict the Use of Certain Cryptographic Algorithms and Protocols in Schannel.dll). It tuned out no cipher suites were disabled and the affected server were just using default SCHANNEL settings.

One interesting thing pointed by our customer is that the SSLDiag report was showing this error when trying to display the PrivateKey size :

SERVER SSL PROTOCOLS
PCT 1.0 : Enabled
SSL 2.0 : Enabled
SSL 3.0 : Enabled
TLS 1.0 : Enabled
…

#CertName :
#Version : 3
#You have a private key that corresponds to this certificate.
#Signature Algorithm : sha256RSA
Error : PrivateKey.KeyExchangeAlgorithm PrivateKey.KeySize Keyset does not exist

Unfortunately, the error above was pretty cryptic but I should have probably paid more attention to it ("Keyset" refers to the certificate's private key)…

After gathering some SCHANNEL ETL traces, my colleague Marc pointed that the KeySpec for the certificate was invalid. This could also be seen in the certutil output for the certificate :

================ Certificate 2 ================
…
Subject:
    CN=xxxxxx…

CERT_KEY_PROV_INFO_PROP_ID(2):
    …
    Provider = Microsoft Enhanced Cryptographic Provider v1.0
    ProviderType = 1
    Flags = 20
    KeySpec = 0

The expected value for a SSL Certificate is to have a KeySpec of 1 which means AT_KEYEXCHANGE as explained in the SCENARIO 3 section of this excellent article : Error HRESULT: 0x80070520 when adding SSL binding in IIS.

At this point, we tried to reimport the certificate from a PFX file but this didn't help: the certificate could be imported without error but the KeySpec was still invalid (0 value). We then tried to force the KeySpec during import using "certutil -importPFX PFXFile AT_KEYEXCHANGE" and we also started a PROCMON trace to check for potential issue during the certificate import. Bingo! We could see a couple of ACCESS_DENIED during access to C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys. After checking the permissions of this directory, we saw that the default permissions were not the same as on a working server. After fixing the permission issue, the certificate import succeeded and PROCMON didn't show any ACCESS_DENIED errors. We then stopped HTTP.SYS (net stop http) and restarted IIS (net start w3svc) and, finally, we could connect to the server using TLS 1.0 with RSA 2048 bits key exchange.

The permission issue on C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys was preventing to get the right KeySpec (AT_KEYEXCHANGE) for the RSA private key. Therefore, RSA couldn't be used for key exchange but could still be used for signature which is why TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA was used.

We hope the above blog may help other customers hitting similar issue.

Best wishes for the upcoming year from the French IIS Support team!

Emmanuel Boersma

ASP.NET Authentication test page

2013-01-08T16:27:00Z

The information contained in this blog POST has been compiled with the help of the following engineers:

Alexandre Lafargue – Microsoft

To troubleshoot authentication issues, it's generally a good idea to use a test page in order to display the current authentication method / identity used for a specific client. In our team's blog "Things to check when Kerberos authentication fails using IIS/IE", we provided a couple of links to troubleshooting pages. Unfortunately, these troubleshooting pages were lacking some features and, for this reason, our team has built its own authentication test page. Currently, our diagnosis page provides details regarding the following items:

authentication method being used
thread (request) and process identity for the application pool hosting the web application
SID and group membership
impersonation level
dump of server variables
test form

Here's a typical output of our diagnosis page:

Notes :

Authentication Method - authentication method used (Basic, NTLM, Kerberos, SSL…etc)
Identity – current authenticated user
Windows identity – windows identity for the current request. In this example, we can see that user is authenticated but impersonation is not enabled
ImpersonationLevel – this allows to see if current settings allow impersonation and delegation (if delegation is enabled, ImpersonationLevel=Delegation)

The diagnosis page also includes a couple of images (IIS8 logo) and a form. The images can be used to check client's behavior regarding request/session based authentication (using a network or HTTPREPLAY trace, you can check if HTTP authentication is request or session based. Using this method, I discovered last month that Kerberos authentication is now session based by default on IIS8/Windows Server 2012!).

The last item in the diagnosis page is a simple form element which can be used to check if pre-authentication is used (in this case, a network trace will show a 0 Content-Length header upon POST).

I hope the Authentication test page will allow you to resolve most authentication issues you may get in the future!

Emmanuel Boersma

Event ID 5188 – Source Microsoft-Windows-WAS : WAS ne démarre pas car le répertoire %SystemDrive%\inetpub\temp\appPools n'est pas trouvable

2013-01-07T15:13:00Z

Le service WAS (Windows Process Activation Service) génère un fichier de configuration temporaire pour chaque Application Pool qu'il va stocker dans le répertoire "%SystemDrive%\inetpub\temp\appPools". Il est possible que vous obteniez le message d'erreur suivant si le répertoire a été déplacé et/ou que les permissions ne sont pas correctement positionnées :

Event ID 5188 - Source Microsoft-Windows-WAS
The directory specified for the temporary application pool config files is either missing or is not accessible by the Windows Process Activation Service. Please specify an existing directory and/or ensure that it has proper access flags. The data field contains the error number.

Pour corriger ce problème vous devez vous assurer que le répertoire AppPools rencontre les prérequis suivants :

Le répertoire doit exister
Le répertoire ne peut pas être un chemin UNC
Le répertoire doit être accessible par WAS et avoir les permissions suivantes :
- SYSTEM: Full Access
- Administrators: Full Access
- IIS_IUSRS: Read

Si vous désirez plus de détails sur le sujet, vous pouvez consulter l'article technet suivant (anglais uniquement) : http://technet.microsoft.com/en-us/library/cc734935(WS.10).aspx

Sylvain Lecerf

L’authentification intégrée (Kerberos) résulte en une erreur avec une application JAVA (GSSException: No valid credentials provided (Mechanism level: Fail to create credential. (63)) - No service creds)

2013-01-07T15:08:00Z

Il est possible que certains prérequis soient nécessaires pour faire fonctionner l'authentification Kerberos avec par exemple une application de type JAVA.
Le symptôme est généralement le suivant : l'authentification Kerberos fonctionne parfaitement sur l'ensemble du site sauf quand vous accédez à une application particulière (type JAVA). Vous êtes prompté et le site n'est pas accessible.
L'application peut renvoyer l'erreur suivante : GSSException: No valid credentials provided (Mechanism level: Fail to create credential. (63)) - No service creds

Pour mon client qui a rencontré ce problème, il a fallu appliquer les trois actions suivantes pour corriger le problème :

Activer l'impersonnation
- Il suffit d'ajouter ce qui suit dans le Web.Config de votre application :
  <system.web>
  <identity impersonate="true" />
  </system.web>
Référencer le bon contrôleur de domaine dans le fichier KRB5.ini :
- Ce fichier est utilisé pour interagir avec des implémentations Kerberos tierce
Activer la clé AllowTgtSessionKey : http://support.microsoft.com/kb/837361/fr
- Cette clé permet l'échange de ticket entre différent monde (Windows, JAVA, Samba…)
- Elle est désactivée par défaut pour des raisons de sécurité
- Cette clé est entièrement utilisable sous W2K8 & W2K8 R2

En espérant que cet article vous sera utile.
Sylvain Lecerf & L'équipe de Support IIS Microsoft France

Debug Diagnostic 1.2 – Créer une règle en mode Crash suite à une exception

2013-01-07T15:05:00Z

Cet article détaille le plan d'action à mettre en place pour créer une règle dans Debug Diagnostic 1.2 afin d'automatiser la génération d'un dump lorsqu'une exception est levée au sein d'un processus relatif à IIS (par exemple un processus "W3WP.exe").

Ce plan d'action est applicable lorsque votre processus "W3WP.exe" plante ce qui, dans le contexte d'IIS, sous-entend que le processus est tué ou redémarré, suite à une exception spécifique (du type Second Chance). Ceci implique donc un arrêt du processus et s'il est relancé, un changement de PID. Il faut bien faire attention à ne pas confondre Crash et Hang, car configurer une règle en mode Crash pour un Hang ne permettra pas la génération de dumps.
Ce plan d'action peut également être utilisé pour simplement capturer une exception qui n'est pas fatale au processus (du type First Chance).

Plan d'action

Debug Diagnostic 1.2 est téléchargeable à l'adresse suivante : http://www.microsoft.com/download/en/details.aspx?id=26798
Une fois le logiciel installé et lancé sur le serveur IIS, l'assistant "Select Rule Type" se charge
Choisissez "Crash" puis cliquez sur "Suivant >"

Dans la fenêtre "Select Target Type"
- Choisissez "A specific IIS web application pool", puis cliquez sur "Suivant >"
  
  Cela aura pour conséquence de générer un dump uniquement sur le processus W3WP.exe correspondant à votre Application Pool.
  - Vous pouvez sélectionner "All IIS/COM+ related processes" si vous voulez surveiller tous les processus liés à IIS.
  - Vous pouvez également sélectionner "A specific process" pour surveiller toutes les instances d'un processus ou une unique instance (un processus spécifique avec un PID spécifique).
    
    L'inconvénient de "A specific process" pour une unique instance est qu'il faut recréer la règle à chaque redémarrage du processus étant donné qu'il va changer de PID.

Sélectionnez l'application pool rencontrant le problème de crash, puis cliquez sur "Suivant >"
Ajoutez l'exception que vous cherchez à capturer (ou celle mentionnée par l'ingénieur support) comme vous pouvez le voir dans le screenshot ci-dessous :
- Remarque : Le champ ".Net Exception Type" est Case Sensitive. Il faut donc faire attention lorsque vous rentrez le nom de l'exception
Ajoutez le breakpoint comme vous pouvez le voir dans le screenshot ci-dessous
- Ceci permet de générer un dump dès que la commande "TerminateProcess" est remontée dans un processus sans attendre son arrêt complet

Cliquez sur "Suivant >"

Choisissez un nom et emplacement pour les dumps, puis cliquez sur "Suivant >"
- Mettre ces dumps sur un autre emplacement que le C:\ ne pose pas de problème
- Vérifiez qu'il y ait suffisamment d'espace disque disponible car la taille d'un dump d'un processus est égale à la taille consommée en mémoire par ce dernier

Dans la fenêtre "Rule Completed", sélectionnez "Activate the rule now", puis cliquez sur "Terminer"
- La règle est maintenant configurée et prête à générer des dumps

Vérifiez que son statut est "Active"
- Si ça n'est pas le cas, le service "DbgSvc" n'est surement pas démarré
- Allez dans "Outils d'administration > Services" et démarrez le
Quand un dump sera généré, vous verrez la colonne "UserDump Count" s'incrémenter

Les dumps sont situés par défaut dans "C:\Program Files\DebugDiag\Logs\Crash rule for all IIS_COM+ related processes" ou dans "C:\Program Files\DebugDiag\Logs\Nom_De_La_Règle "

Pour retourner à l'article d'introduction sur Debug Diagnostic 1.2 cliquez ICI.

En espérant que cet article vous sera utile.

@ Bientôt

Sylvain Lecerf et L'équipe de support IIS Microsoft France

UrlScan RemoveServerHeader Property Vs HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parpameters\DisableServerHeader

2013-01-07T14:53:00Z

Cela fait plusieurs fois qu'une incompréhension résulte en l'ouverture d'un incident au support Microsoft. Il est avéré que la clé "HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parpameters\DisableServerHeader" est sensée supprimer le header "Server" renvoyé par IIS. Or, cette clé ne permet pas de supprimer les headers positionnés au niveau User-Mode mais seulement ceux positionnés au niveau du driver HTTP.sys.

De manière plus précise, lorsqu'une requête arrive sur un serveur IIS, elle est d'abord prise en charge par le driver HTTP.sys qui est le driver Kernel de IIS qui gère toutes les connexions entrantes sur le serveur. En fonction de la requête, elle peut être soit directement traitée par HTTP.sys, soit être envoyée vers le User-Mode de IIS (processus W3WP.exe pour simplifier). Quand elle passe par le User-Mode, le header renvoyé est "Server: Microsoft-IIS/7.5". C'est ce header que la plupart des gens cherchent à supprimer. Cependant, lorsqu'elle passe uniquement par le Kernel-Mode, le header qui est normalement renvoyé est "Server: Microsoft-HTTPAPI/2.0". En positionnant la clé "DisableServerHeader" à 1, c'est ce header que vous allez supprimer.

Pour supprimer le header "Server: Microsoft-IIS/7.5", il faut utiliser UrlScan. UrlScan est un excellent outil pour renforcer la sécurité d'un serveur web et généralement la suppression de ce header fait partie de cette optique. Il suffit donc de positionner le paramètre RemoveServerHeader à 1 comme ci-dessous dans le fichier UrlScan.ini (C:\Windows\System32\inetsrv\urlscan) :

RemoveServerHeader=1 ; If 1, remove the 'Server' header from
; response. The default is 0.

Toutefois, si actuellement vous n'utilisez pas UrlScan, il est possible que la configuration par défaut modifie le comportement de votre serveur et empêche ainsi le bon fonctionnement de certaines applications. Ayant déjà rencontré ce problème, vous trouverez à la fin de cet article le fichier UrlScan.txt (à renommer en UrlScan.ini) qui devrait avoir pour conséquence de "désactiver" l'ensemble des paramètres d'UrlScan sauf le RemoveServerHeader. Si vous le désirez, vous pouvez tester ce fichier et vérifier qu'il correspond bien à vos attentes.

Note 1 : Avant d'effectuer le test :

Quelques modifications vont devoir être apportées au fichier. En particulier les points 8 & 10 qu'il vous faudra adapter à vos besoins.
Pensez à sauvegarder le fichier UrlScan.ini d'origine afin de pouvoir effectuer rapidement un retour arrière si quelque chose ne se passe pas correctement.

Note 2 : Je vous conseille de redémarrer le serveur après avoir remplacé le fichier UrlScan.ini afin d'être certain que l'ensemble des paramètres ont bien été appliqués.

Avertissement :Je tiens à souligner que désactiver l'ensemble des fonctionnalités n'est pas une idée judicieuse pour la sécurité du serveur IIS. Cette procédure n'est fournie qu'à titre de test afin de vérifier la suppression du header "Server: Microsoft-IIS/7.5" sans impacter le fonctionnement du serveur IIS. Il n'est bien entendu pas recommandé de faire tourner un serveur IIS en production avec cette configuration d'UrlScan. Si vous décidez d'utiliser cette procédure en production et qu'un incident survient à cause de cette dernière, le support Microsoft ne pourra pas en être tenu responsable.

En complément, voici quelques explications sur ce que j'ai fait au niveau de la configuration d'UrlScan :

1- UseAllowVerbs

If 1, use [AllowVerbs] section, else use the [DenyVerbs] section. The default is 1.

Si ce paramètre est activé, UrlScan ne va autoriser que les verbes présents dans la section [AllowVerbs]. Afin d'éviter de lister tous les verbes qui existent dans cette section, j'ai positionné le paramètre à 0 et commenté l'ensemble des verbes contenus dans la section [DenyVerbs]. Ainsi nous laisserons passer tous les verbes qui ne sont pas listés, et comme il n'y en a pas, on laissera tout passer.

2- UseAllowExtensions

If 1, use [AllowExtensions] section, else use the [DenyExtensions] section. The default is 0.

Même principe que le précédent, paramètre à 0 et on commente ce qu'il y a dans la section [DenyExtensions].

3- NormalizeUrlBeforeScan

If 1, canonicalize URL before processing. The default is 1. Note that setting this to 0 will make checks based on extensions, and the URL unreliable and is therefore not recommend other than for testing.

Le principe est de décoder une URL qui a été encodée avant de l'analyser. Par exemple, le caractère d'espacement sera encodé avec un %20. Une URL du type "http://myserver/My%20Dir/My%20File.htm" sera décodée par UrlScan comme "http://myserver/My Dir/My File.htm" et une fois cette opération effectuée, UrlScan l'analysera. Laisser ce paramètre à 1 ne devrait pas impacter l'application. Cependant, j'ai passé le paramètre à 0 car cela devrait arrêter le procédé de décodage qui est inutile dans le scénario que vous souhaitez mettre en place. On gagnera certainement en temps de traitement.

4- VerifyNormalization

If 1, canonicalize URL twice and reject request if a change occurs. The default is 1.

Même principe que précédemment, sauf qu'ici une deuxième tentative de décodage est effectuée au cas où un élément de l'URL serait doublement encodé. Si à la deuxième tentative de décodage l'URL est la même, l'accès est autorisé, sinon la requête est rejetée. J'ai mis ce paramètre à 0 étant donné que la première vérification est désactivée.

5- AllowHighBitCharacters

If 1, allow high bit (ie. UTF8 or MBCS) characters in URL. The default is 0.

Si ce paramètre est à 0, il va bloquer les requêtes qui contiennent un caractère non-ASCII. Cela peut avoir un impact pour des fichiers tout à fait normaux comme par exemple ceux avec des noms non-Anglais. Je l'ai passé à 1 pour le désactiver.

6- AllowDotInPath

If 1, allow dots that are not file extensions. The default is 0. Note that setting this property to 1 will make checks based on extensions unreliable and is therefore not recommended other than for testing.

Si ce paramètre est à 0, il va bloquer les requêtes qui contiennent plusieurs points (.) afin d'éviter des tentatives d'accès à des mauvais fichiers masqués dans une URL vers un fichier tout à fait sûr. Par exemple : http://servername/BadFile.exe/SafeFile.htm. Je l'ai passé à 1 pour le désactiver.

7- RemoveServerHeader

Je vais passer sur ce paramétrage car vous savez parfaitement ce qu'il implique. Je l'ai positionné à 1 pour l'activer.

8- EnableLogging

If 1, log UrlScan activity. The default is 1. Changes to this property will not take effect until UrlScan is restarted.

Par défaut UrlScan génère un fichier de log de toutes les requêtes qui ont été bloquées dans "%WINDIR%\System32\inetsrv\URLScan". Je vous recommande de le laisser activé dans un premier temps afin de vérifier qu'aucune requête n'est bloquée par UrlScan. Je l'ai toutefois désactivé dans le fichier afin qu'il ne soit pas oublié à 1 inutilement.

9- PerProcessLogging

This property is deprecated for UrlScan 3.0 and later. UrlScan 3.0 and later can safely log output from multiple processes to the same log file. Changes to this property will not take effect until UrlScan is restarted.

Comme indiqué ce paramètre est déprécié à partir d'UrlScan 3.0. Je l'ai donc laissé désactivé.

10- AllowLateScanning

If 1, then UrlScan will load as a low priority filter. The default is 0. Note that this setting should only be used in the case where there another installed filter is modifying the URL and you wish to have UrlScan apply its rules to the rewritten URL. Changes to this property will not take effect until UrlScan is restarted.

Ici, il s'agit de définir la priorité à apporter au filtre ISAPI UrlScan. Si vous laissez le paramètre à 0, ce filtre ISAPI sera exécuté en premier. Si vous passez le paramètre à 1, il passera après que des filtres ISAPI comme les FPSE ou URLRewritte aient modifiés la requête. C'est donc à vous de définir si ce paramètre doit être à 0 ou à 1. J'ai laissé la valeur par défaut dans le fichier qui est 0.

11- PerDayLogging

If 1, UrlScan will produce a new log each day with activity in the form 'UrlScan.010101.log'. If 0, UrlScan will log activity to urlscan.log. The default is 1. Changes to this setting will not take effect until UrlScan is restarted.

Ce paramètre permet à UrlScan de générer un fichier de log par jour. J'ai positionné le paramètre à 0. Normalement vous ne devriez pas avoir de logs générés, cependant si cela été le cas, on évitera d'avoir plein de petits fichiers.

12- UseFastPathReject

If 1, then UrlScan will not use the RejectResponseUrl. On IIS versions less than 6.0, this will also prevent IIS from writing rejected requests to the W3SVC log. UrlScan will log rejected requests regardless of this setting. The default is 0.

Que ce paramètre soit à 0 ou à 1, cela ne changera rien pour l'application étant donné que celui-ci s'applique uniquement une fois qu'il a été décidé de bloquer la requête. La différence principale réside dans la manière dont va être bloquée l'URL. Je vous recommande de laisser ce paramètre à 0 car si une requête est rejetée, vous obtiendrez certainement plus d'informations que si le paramètre est à 1 pour comprendre le pourquoi du blocage.

13- LogLongUrls

This property is deprecated for UrlScan 3.0 and later. UrlScan 3.0 and later will always include the complete URL in its log file.

Comme indiqué ce paramètre est déprécié à partir d'UrlScan 3.0. Je l'ai donc laissé désactivé.

14- UnescapeQueryString

If 1, UrlScan will perform two passes on each query string scan, once with the raw query string and once after unescaping it. If 0, UrlScan will only look at the raw query string as sent by the client. The default is 1. Note that if this property is set to 0, then checks based on the query string will be unreliable.

Comme le but n'est pas de scanner de la manière la plus sûre possible les requêtes avec query string mais de n'avoir que le paramètre RemoveServerHeader d'activé, j'ai désactivé ce paramètre en le passant à 0.

J'ai ensuite commenté le contenu des sections pour lesquelles nous n'avons pas fait de traitement :

RequestLimits
DenyHeaders
DenyUrlSequences
DenyQueryStringSequences

Les paramètres restants peuvent être ignorés car inutilisés ou inutiles dans le cas d'une désactivation complète des tous les paramètres d'UrlScan sauf le RemoveServerHeader:

RejectResponseUrl=
LoggingDirectory=Logs
- Ici vous pouvez changer l'emplacement par défaut des logs si vous le désirez
AlternateServerName=
RuleList

En espérant que cet article vous soit utile.
Sylvain Lecerf

ASP.NET & consommation mémoire au démarrage du processus W3WP.exe

2013-01-02T13:27:00Z

Une question revient régulièrement au support Microsoft au sujet de la consommation mémoire d'ASP.NET au démarrage d'un processus W3WP.exe.
En effet, ASP.NET va se réserver une certaine quantité de mémoire virtuelle dès que le processus démarre (Pour comprendre la différence entre mémoire virtuelle et mémoire privée je vous invite à lire l'article suivant : http://blogs.msdn.com/b/friis/archive/2008/10/13/m-moire-recyclage-sous-iis-6.aspx).

La taille de cette allocation mémoire varie en fonction de l'architecture x86/x64 et de la version du Framework ASP.NET.
La répartition est la suivante :

ASP.NET 2.0 x86 = 64 MB par processeur pour le "small object segment" et 32 MB par processeur pour le "large object segment", soit 96 MB par processeur.
ASP.NET 2.0 x64 = 512 MB par processeur pour le "small object segment" et 128 MB par processeur pour le "large object segment", soit 640 MB par processeur.
ASP.NET 4.0 x86 = 64 MB par processeur pour le "small object segment" et 32 MB par processeur pour le "large object segment", soit 96 MB par processeur.
ASP.NET 4.0 x64 = 1024 MB par processeur pour le "small object segment" et 256 MB par processeur pour le "large object segment", soit 1280 MB par processeur.

Les Frameworks 3.0 & 3.5 ne sont pas mentionnés car ils reposent entièrement sur le runtime (la CLR) du Framework 2.0. En ce sens on peut les considérer comme un Service Pack du Framework 2.0.

A titre d'exemple, si vous avez une architecture x86 avec 16 processeurs, vous démarrez directement à la limite de l'out-of-memory étant donné que 1536 MB de mémoire virtuelle seront directement réservés sur les 2 GB disponibles par processus. Il reste alors environ 500 MB pour le code natif, les fichiers systèmes… Il est donc préférable pour des machines avec de nombreux processeurs, dans le cadre d'un serveur IIS/ASP.NET, de passer sur une architecture x64 pour éviter cette problématique.

Sylvain Lecerf