IIS Insider - April 2004
Die häufigsten Fragen und Antworten zu Internetinformationsdiensten
Topantworten auf Topfragen gibt der IIS Insider wieder in dieser Ausgabe seiner Kolumne. Die Themen diesmal: "So verwenden Sie COM und COM-Objekte zusammen mit IIS", "Alte Kennwörter sind nach der Änderung noch gültig" und "Bei der Abfrage gültiger ASP-Seiten wird der Fehler "Seite nicht gefunden" angezeigt".
DownloadArtikel im Word-Format
Artikel im PDF-Format
|
Auf dieser Seite
 | Verwenden von COM und COM-Objekten zusammen mit IIS |
| Alte Kennwörter nach Änderung noch gültig |
| Fehler "Seite nicht gefunden" bei der Abfrage gültiger ASP-Seiten |
| Weitere Informationen |
(Engl. Originaltitel: IIS Insider - April 2004)
Verwenden von COM und COM-Objekten zusammen mit IIS
Da wir in unserem Unternehmen eine wichtige Anwendung implementieren möchten, arbeiten wir mit einer ASP-Anwendung unter IIS 5, die COM-Objekte einsetzt. Die COM-Objekte wurden mit Visual Basic erstellt, die Anwendung funktioniert aber offenbar nicht zuverlässig. Wir finden hierfür keine Erklärung. Die Anwendung läuft zunächst ordnungsgemäß, dann friert sie ein. Können Sie Benutzern von COM und IIS einen Rat geben?
Ich kann Ihnen nur empfehlen, sich eingehend mit dem Thema zu befassen. Für die, die es vielleicht nicht wissen: COM (Component Object Model) ist ein Microsoft-Standard zur Erstellung von ausführbaren Dateien (DLL-Dateien), die von einer COM-fähigen Anwendung aufgerufen werden können. IIS kann mit Hilfe von ASP oder einer anderen Skriptsprache bzw. einer entsprechenden Sprache auf COM-Basis webbasierte Anwendungen bereitstellen. Die so genannten "COM-Objekte" können mit Microsoft-Sprachen wie etwa Visual Basic oder Visual C++ erstellt werden. COM-Interaktionen mit IIS sind manchmal sehr komplex und daher schwierig zu verstehen. Ich habe mich lange Zeit mit IIS befasst, und obwohl ich kein Entwickler bin, habe ich das Zusammenspiel von COM und IIS eingehend untersucht.
Wie bereits erwähnt können COM-Objekte mit einer Reihe von Sprachen erstellt werden. Sie sollten als IIS-Administrator wissen, ob COM-Objekte in Visual Basic 6 geschrieben werden. Es gibt in diesem Fall zwei sehr wichtige Features, die für die Kompilierung der Komponenten aktiviert werden müssen: "In Speicher erhalten" und "Unbeaufsichtigte Ausführung". (Siehe http://support.microsoft.com/default.aspx?scid=kb;EN-US;241896 (englischsprachig). Wenn der Entwickler diese Optionen bei der Erstellung der COM-Objekte nicht festgelegt hat, führt ihre Ausführung in IIS zu Problemen.
Daneben können bei der Verwendung von COM Schwierigkeiten im Zusammenhang mit Threading auftreten, auf die hier nicht näher eingegangen werden kann. In dem weiter oben erwähnten KB-Artikel finden Sie einige Informationen hierzu.
Wenn Sie mehr über COM und IIS erfahren möchten, kann ich das Buch "Programming Windows Security" von Keith Brown empfehlen. Ausführliche Informationen erhalten Sie zudem auf den MSDN-Webseiten - zum Beispiel in den Artikeln COM Components for ASP und Designing COM Components for ASP (beide englischsprachig). Abschließend ist zu sagen, dass sich in Bezug auf das Zusammenspiel von IIS 6 und COM viel geändert hat.
Alte Kennwörter nach Änderung noch gültig
Um unsere Webanwendung im Internet bereitzustellen, verwenden wir sowohl IIS 4- als auch IIS 5-Server. Benutzer müssen zur Anmeldung eine Standardauthentifizierung über SSL verwenden. Wir haben festgestellt, dass sich der jeweilige Benutzer nach der Änderung eines Kennworts eine gewisse Zeit lang weiterhin mit dem alten Kennwort anmelden kann. Warum nimmt IIS die Kennwortänderung durch den Benutzer nicht an?
Sowohl bei der Standardauthentifizierung als auch bei der anonymen Authentifizierung werden die Anmeldeinformationen des Benutzers in IIS 15 Minuten lang zwischengespeichert. Wenn Sie das Kennwort eines Benutzers ändern und sich der Benutzer innerhalb dieser 15 Minuten bei IIS anmeldet, akzeptiert IIS das alte Kennwort, bis der Zwischenspeicher aktualisiert wird. Das Problem kann auch auftreten, wenn Sie einer Gruppe einen Benutzer hinzufügen und die Gruppenmitgliedschaft vor der Aktualisierung des Zwischenspeichers nicht aktualisiert wird. Sie können eine Aktualisierung des Zwischenspeichers erzwingen, indem Sie IIS beenden und neu starten.
Durch die Zwischenspeicherung dieser Anmeldeinformationen gewährleistet IIS eine optimale Leistung. Ohne Zwischenspeicher müsste bei jedem Zugriff eine Authentifizierung stattfinden. Die Leistung würde dadurch deutlich beeinträchtigt.
Sie können festlegen, wie lange die Anmeldeinformationen zwischengespeichert werden sollen. In bestimmten Fällen kann es von Vorteil sein, die Standardeinstellung von 15 Minuten nach oben oder unten anzupassen. Folgen Sie hierzu den Anweisungen im Microsoft Knowledge Base-Artikel Changing the Default Interval for User Tokens in IIS (englischsprachig).
Der Mindestwert für IIS 4 beträgt 30 Sekunden. Bei Eingabe des Wertes 0 wird dieser daher durch den Wert 30 ersetzt. Bei IIS 5 ist der Mindestwert 1 Sekunde. Wird der Wert 0 eingegeben, wird dieser in den Wert 1 geändert. Sie müssen IIS neu starten, damit die Änderungen wirksam werden.
Bei IIS 6 wird durch den Wert 0 der Zwischenspeicher deaktiviert. In diesem Fall müssen Sie den entsprechenden Anwendungspool wiederherstellen, um den Zwischenspeicher zu aktualisieren. Ein Neustart des Servers ist nach den Registrierungsänderungen nicht erforderlich.
Fehler "Seite nicht gefunden" bei der Abfrage gültiger ASP-Seiten
Ich möchte ASP-Anwendungen auf meinem Windows XP Professional-Computer lokal testen können, bevor ich sie auf meiner öffentlichen Website bereitstelle. Ich habe IIS 5.1 installiert. Wenn ich jedoch versuche, ASP-Seiten aufzurufen, erhalte ich die Fehlermeldung "Seite nicht gefunden". Mein lokaler Computer hat den Namen "localhost", und ich möchte auf die folgende URL zugreifen: http://localhost/directory/filename.asp. Die Datei ist vorhanden und in dem Ordner "\inetpub\wwwroot" gespeichert, der der Standardwebsite zugeordnet ist.
Wenn der Fehler "Seite nicht gefunden" angezeigt wird, hat IIS die Anforderung erhalten und darauf reagiert. Daher liegt die Schwierigkeit woanders. Es handelt sich auch nicht um ein Berechtigungsproblem. Andernfalls würden Sie die Meldung "Zugriff verweigert" oder eine Authentifizierungsaufforderung erhalten. Bleiben einige Punkte zu überprüfen. Wenn URLSCAN installiert ist, verweigert es möglicherweise den Zugriff auf die ASP-Erweiterungen. Andernfalls müssen wir davon ausgehen, dass IIS lediglich den Dateinamen nicht finden kann. Die häufigste Ursache hierfür ist, dass Dateierweiterungen nicht angezeigt werden. Dies ist die Standardeinstellung. Nehmen wir beispielsweise an, Sie erstellen in Editor eine Datei und speichern sie als "default.asp". Der Dateiname lautet in diesem Fall "default.asp.txt". Wenn Sie nach der Datei "default.asp" fragen, kann IIS sie daher nicht finden. Wenn Sie sich die Datei jedoch in Windows Explorer ansehen, wird sie als "default.asp" angezeigt. Sie können Windows XP und andere Microsoft-Betriebssysteme so konfigurieren, dass Dateierweiterungen stets angezeigt werden. Öffnen Sie dazu "Arbeitsplatz", klicken Sie auf "Extras" und anschließend auf "Ordneroptionen". Wählen Sie nun die Registerkarte "Ansicht" aus. Deaktivieren Sie hier das Kontrollkästchen "Erweiterungen bei bekannten Dateitypen ausblenden" (wie weiter unten für Windows XP Professional gezeigt).
Weitere Informationen
Schicken Sie Ihre Fragen in englischer Sprache an den IIS Insider. Ausgewählte Fragen sowie die dazugehörigen Antworten werden in einer der nächsten Ausgaben von IIS Insider veröffentlicht.
Eine Liste der Fragen und Antworten in den IIS Insider-Kolumnen früherer Monate finden Sie hier (englischsprachig).
Weitere Informationen
Das Team der Microsoft Corporation hofft, dass die Informationen in diesem Dokument für Sie von Nutzen sind. Die Verwendung der in diesem Dokument enthaltenen Informationen erfolgt jedoch auf eigene Gefahr. Alle Informationen werden wie besehen bereitgestellt, ohne jede Gewährleistung, sei sie ausdrücklich oder konkludent, für die Richtigkeit, die Vollständigkeit, die Eignung für einen bestimmten Zweck, den Eigentumsvorbehalt oder die Nichtverletzung von Rechten Dritter, und keine der in diesem Dokument genannten Drittanbieterprodukte oder Informationen von Dritten wurden/werden von der Microsoft Corporation verfasst, empfohlen oder unterstützt, und die Microsoft Corporation übernimmt keine Garantie dafür. Die Microsoft Corporation kann nicht für Schäden haftbar gemacht werden, die aus der Verwendung dieser Informationen entstehen, ungeachtet dessen, ob es sich um direkte oder indirekte, spezielle, zufällig entstandene oder Folgeschäden handelt, selbst dann nicht, wenn die Microsoft Corporation auf die mögliche Entstehung solcher Schäden hingewiesen wurde.
 | Brett Hill (Engl. Originaltitel: IIS Insider - January 2004) Eine Beschreibung zu den IIS Insider Kolumnen von Brett HIll finden Sie hier (engl.). |