- Betrifft: IIS 7.0 und IIS 7.5
- System: Microsoft Windows Server 2008 x64, Windows Server 2008 R2 x64
- Problem: beim Zugriff auf ASP.NET 32-Bit Anwendungen unter IIS 7.x auf einem 64-Bit Windows Server erhält man eine Internal Server Error. Die Windows Server Update Services 3.0 sind am gleichen Server installiert.
Hintergrund
Ab IIS 7.0 ist es unter Windows Server möglich nicht mehr den gesamte Webserver im 32-Bit Modus zu setzen, sondern nur die vereinzelten ASP.NET Anwendungen. Dies geht jeweils pro Anwendungspool.
Immer wieder ist dies notwendig, da manche Webanwendungen nur im 32-Bit Modus verfügbar sind. Also nichts leichter als den Anwendungspool unter erweiterte Einstellungen zu ändern.
Nachdem umstellen erhält man beim Aufruf der Webseite eine Fehlermeldung. In meinem Fall mit den “Informationsdiensten 7.5” unter Windows Server 2008 R2:
| HTTP-Fehler 500.19 – Internal Server Error
Auf die angeforderte Seite kann nicht zugegriffen werden, da die zugehörigen Konfigurationsdaten für die Seite ungültig sind. Ausführliche Fehlerinformationen Modul: DynamicCompressionModule Wahrscheinlichste Ursachen:
Mögliche Vorgehensweise:
Links und weitere Informationen Dieser Fehler tritt auf, wenn beim Lesen der Konfigurationsdatei für den Webserver oder die Webanwendung ein Problem vorliegt. In bestimmten Fällen finden Sie weitere Informationen über die Ursache dieses Fehlers in den Ereignisprotokollen. |
Auf dem gleichen Webserver sind die Windows Server Update Services 3.0 (=WSUS) installiert. Das zugehörige Installationsprogramm installiert ein Komprimierungsmodul um die Verteilung der Updates Hotfixes, Feature Packs und ähnliches mittels komprimierter Daten durchführen zu können.
Beim Installationsvorgang wird auf einem 64-Bit System jedoch nur die 64-Bit Version des Komprimierungsmodules “suscomp.dll” unter “C:\WINDOWS\system32\inetsrv” installiert.
Zwischenschritt
In diesem konkreten Fall ist entgegen der Angabe in der Fehlermeldung keine Konfigurationsdatei ungültig und auch die Berechtigung wird höchstwahrscheinlich stimmen. Viel wahrscheinlicher ist das fehlen einer 32-Bit Variante des Komprimierungsmodules.
Der Fehlercode 0x8007007e bedeutet “ERROR_MOD_NOT_FOUND” bzw. “The specified module could not be found” – also das spezifizierte Modul kann nicht gefunden werden.
Dieses Modul ist in der Datei “suscomp.dll” und wird als “Xpress Compression” bezeichnet. Dieses müsste unter “C:\WINDOWS\SysWOW64\inetsrv” liegen. Dort ist aber die “suscomp.dll” Datei nicht zu finden. Die 64-Bit Variante kann nicht verwendet werden. Beim WSUS 3.0 x64 Setup wird keine 32-Bit Variante mitgeliefert.
Behebung
Mir sind drei Möglichkeiten bekannt. Die ersten zwei Lösungen habe ich selber getestet – hierbei ist meine Empfehlung die 2. Variante.
1.) Komprimierung deaktivieren
Die Konfiguration der Komprimierung ist leider global und betrifft immer den gesamten Webserver. Ein deaktivieren beeinträchtigt somit auch den WSUS. Dieser kann dann keine komprimierten Dateien mehr ausliefern, was das Datenvolumen erhöht (womöglich aber die Prozessorlast verringert).
Nachfolgende Befehle einfach über die Command Shell (=> “cmd”) ausführen.
Deaktivieren:
| %windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name=’xpress’] |
Aktivieren:
| %windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /+[name=’xpress’,doStaticCompression=’false’,dll=’%windir%\system32\inetsrv\suscomp.dll’] |
2.) 32-Bit Version des Komprimierungsmoduls besorgen
Einfach die “suscomp.dll” Datei von einem 32-Bit Windows Server mit installiertem WSUS kopieren und in “C:\WINDOWS\SysWOW64\inetsrv” einfügen. Beim nächsten Aufruf wird die Webseite normal funktionieren. Darüber hinaus bleibt die Komprimierungsfunktion erhalten und es können keine Nebenerscheinungen auftreten.
Bei Bedarf kann ich gerne die 32-Bit Variante per Email zusenden. Einfach über Kontakt mit mir in Verbindung treten. Ich konnte bis dato nicht abklären, ob ein direkter Download dieser geschützten Datei erlaubt ist.
Update 06.12.2013:
=> Dies ist eigentlich die meist genutzte Variante. Je nach Monat treffen zwischen 4 und 8 Anfragen betreffend dieser Datei bei mir ein. Laut meinen Informationen dürfte es bei allen funktioniert haben. Leider erhalte ich nicht immer eine Rückmeldung als Kommentar oder per Email. Jedenfalls zeigt dies 3 Jahre nach Erstellung dieses Artikel, dass das Thema nach wie vor aktuell ist!
3.) 64-Bit Modul nur bei 64-Bit Anwendungspools laden
Eine dritte Variante ist mir zwar bekannt, konnte diese aber nicht nachvollziehen. Hierbei wird das 64-Bit Modul per “precondition=64bitness” nur bei 64-Bit Anwendungspools gesucht und geladen. Wenn jemand eine Anleitung oder ansonsten nähere Informationen kennt, so bitte ich um Info per Kommentar oder Kontakt.
