Gestern hat mich die Verwaltungswebsite des Microsoft Virtual Server 2005 mit der HTTP-Fehlermeldung 500 (Internal Server Error -- Interner Serverfehler) begrüßt. Nach einer Weile suchen (ich habe einige Dinge ausprobiert, die ich gleich auflisten werde) habe ich dann des Rätsels Lösung gefunden. Doch hier zunächst die Dinge, die ich ausprobiert habe:

Egal welche Aktion ich versucht habe, die HTTP 500 Fehlermeldung blieb.

Die Lösung

Die Lösung ist recht einfach, aber auch nicht auf den ersten Blick logisch: Es liegt an einer Sicherheitseinstellung in den Internetoptionen. Genauer gesagt: Internet-Optionen->Sicherheit->Vertrauenswürdige Sites->Stufe anpassen…->Benutzeranmeldung->Automatisches Anmelden nur in der Intranetzone ist die Einstellung, die gesetzt sein muss. Bei der Einstellung Automatische Anmeldung mit Benutzernamen und Kennwort wird die HTTP 500er Fehlermeldung geschmissen.

Und hier ist die Anleitung:

	1. Zum Start der Microsoft Virtual Server Verwaltungswebsite klicken Sie auf Start->Alle Programme->Microsoft Virtual Server->Virtual Server-Vewaltungswebsite
	2. Dann erscheint die HTTP 500 Fehlermeldung
	3. Gehen Sie dann auf Extras->Internetoptionen
	4. Klicken Sie dann auf den Reiter Sicherheit und dann auf Vertrauenswürdige Sites. Dort klicken Sie dann auf Stufe anpassen… Sie sehen hier die Screenshots einmal auf englisch, da ich die Fehlermeldung auf einem englischen System bekommen habe, und einmal auf deutsch zum besseren Verständnis
	5. Scrollen Sie die Einstellungen soweit herunter, dass Sie die Benutzerauthentifizierungs-Eintstellungen sehen. Hier markieren Sie den Punkt Automatisches Anmelden nur in der Intranetzone
6. Schließen Sie den Browser und starten Sie die Microsoft Virtual Server Verwaltungswebsite erneut. Sie werden nun zur Eingabe Ihres Passwortes aufgefordert.

Ohne korrekte Benutzeranmeldung kann die Microsoft Virtual Server Verwaltungswebsite nicht korrekt angezeigt werden. Auch wenn Sie sich mit dem Benutzerkonto anmelden, dass Sie schlussendlich für die Verwaltungswebsite benötigen. Es findet hier keine automatische Identitätsübernahme statt.

Hier habe ich das Ganze für Sie nochmal als Video aufbereitet:

www.youtube.com/watch?v=Ao1fywZFnyE

Ich freue mich auf Ihre Kommentare. Haben Sie ähnliches erlebt?

In diesem Post reparieren wir die Berichterstellung eines Microsoft System Center Data Protection Managers 2007. Hier die Konfiguration der Maschine:

• Microsoft Windows Server 2008
• Microsoft System Center Data Protection Manager
• Microsoft Internet Information Server 7 (IIS7)
• Microsoft SQL Server Express

Bei Klick auf die Berichterstellung erscheint die folgende Fehlermeldung:

IIS-Konnektivitäts-Fehlermeldung vom SQL Server Services-Server

“Aufgrund von IIS-Konnektivitätsproblemen konnte keine Verbindung mit dem SQL Server Reporting Services-Server hergestellt werden.

Starten Sie auf dem Computer, auf dem die DPM-Datenbank erstellt wurde, den WWW-Publishingdienst neu. Klicken Sie im Menü ‘Verwaltung’ auf ‘Dienste’. Klicken Sie mit der rechten Maustaste auf ‘WWW-Publishingdienst’, und klicken Sie dann auf ‘Starten’.
ID: 3013″

Diese Fehlermeldung enthält die Anweisung, den WWW-Publishingdienst neu zu starten. Das funktioniert allerdings nicht. Im Video unten finden Sie die Fehleranalyse und Durchführung, aus Platzgründen finden Sie hier nur den Lösungsweg.

Die Lösung

Die Lösung des Problems liegt im IIS 7 begraben.

	Starten Sie den Internetinformationsdienste Manger
	Überprüfen Sie dann das Verzeichnis des SQL Server Report Services Server, um den Pfad dorthin zu bestimmen. Befindet er sich unterhalb der Default-Website dann lautet er in etwa so: http://localhost/ReportServer$MS$DPM2007$
	Nehmen Sie dann den im vorherigen Schritt bestimmten Pfad und geben Sie ihn im Internet-Explorer des Servers ein. Sie erhalten daraufhin die links erscheinende Fehlermeldung.
	In den Handlerzuordnungen verstecken sich die Ausführungsberechtigungen, die sich im IIS6 noch auf dem Reiter Basisverzeichnis befanden. Klicken Sie also Handlerzuordnungen an.
	Dann sehen Sie eine Übersicht über die erlaubten bzw. verweigerten Ausführungsberechtigungen.
	Dort klicken Sie dann rechts im Menü auf Featureberechtigungen bearbeiten…
	Sie sehen, dass die Ausführungs- bzw. Featureberechtigungen fehlen
	Setzen Sie sie alle (Lesen, Skript und Ausführen)
	Nachdem Sie die Report-Server Website im Internet-Explorer aktualisiert haben (Taste F5 drücken), sollten Sie nun die folgende Fehlermeldung sehen: “Die dem Benutzer ‘Domäne\Benutzer’ erteilten Berechtigungen reichen zum Ausführen des Vorgangs nicht aus. (rsAccessDenied)” Diese Fehlermeldung ist ok, da Sie in der Regel mit dem Benutzerkonto, mit dem Sie angemeldet sind, keinen Zugriff auf die SQL Server Datenbank haben. Wenn Sie diese Meldung sehen, funktionieren die Reporting Services wieder korrekt.
	Wechseln Sie in der DPM-Verwaltungskonsole auf den Reiter Verwaltung und dann wieder zurück zu Berichterstellung und Sie sehen das Bild links. (Sie können natürlich auch einen anderen Reiter wählen, ich hatte Verwaltung nur vorgeschlagen, weil er direkt neben der Berichterstellung liegt und man so die Maus nicht unnütz lang bewegen muss )

Im folgenden Video sehen Sie die Vorgehensweise, wie ich bei der Fehleranalyse vorgegangen bin.

www.youtube.com/watch?v=Q5oXarVPODI

Hinterlassen Sie einen Kommentar, wie Ihnen der Artikel gefallen hat, ob Sie selbst dies oder ein ähnliches Problem hatten, ob Sie einen weiteren Lösungsweg kennen, etc. Wir schauen uns das denn gemeinsam an. Ich freue mich auf das Gespräch mit Ihnen.

Ich habe wirklich hart kämpfen müssen, obwohl die Lösung ganz einfach war…. Hinterher ist man immer schlauer .

Konfiguration

• Microsoft Windows 7
• Microsoft Visual Studio 2010 Beta 2
• Parallels 4.0
• Apple MacBook

Vorgehensweise

Nachdem die Software auf der virtuellen Maschine installiert war, habe ich den Remotedebugger auf dem Server mit den ASP.NET-Anwendungen installiert und als Dienst gestartet.

Firewallkonfiguration

In der Windows-Firewall muss auf dem Host das Progamm Microsoft Remotedebugger, auf dem Client das Programm Microsoft Visual Studio als Ausnahmen deklariert sein, bzw. in einer Firewall müssen die folgenden Ports geöffnet sein:

• TCP 139
• TCP 445
• UDP 137
• UDP 138

Sollten Sie IPSec benutzen müssen, benötigen Sie auch die folgenden Ports:

• UDP 4500
• UDP 500

Fehlermeldung

Als ich brav alles eingestellt hatte, quittierte mir das System meine Debugging-Bemühungen mit folgender Fehlermeldung:

Unable to start debugging on the web server. The Visual Studio
debugger cannot connect to the remote computer. A firewall may
be preventing communication via DCOM to the remote computer.
Please see Help for assistance.

Remotedebugging - Unable to start debugging on the web server

Diese Fehlermeldung blieb mir selbst bei der Ausschaltung sämtlicher Firewalls erhalten.

Lösung

Der Trick: Mein Netzwerk-Adapter in der Parallels-Maschine war auf “Shared” einstellt und hatte so eine IP, die in einem anderen Netzwerkbereich lag. Da der Domänencontroller diesen nicht kannte, konnte der Microsoft Visual Studio Remotedebugger keine Verbindung zu der Client-Maschine aufbauen.
Setzen Sie den Modus für den Adapter auf “Bridged”. Dann wird es als eigenständige Netzwerkkarte betrachtet und bekommt vom DHCP-Server der Domäne eine eigene IP. Mit dieser kann sich der Remotedebugger dann auch connecten.

Wenn Sie Fragen, Anregungen oder Wünsche zu weiteren Themen in diesem Bereich haben, nutzen Sie bitte die Kommentare. Ich freue mich auf Ihre Feedback…

Die ASP.NET-Anwendungen eines Microsoft Internet Information Server 7.0 (IIS 7) ließen sich in der Domäne nicht remote debuggen. Es kam die Meldung:

Unable to Start Debugging on the Web Server. Das System kann die
angegebene Datei nicht finden.

Die Meldung (halb englisch, halb deutsch) wurde vom Microsoft Visual Studio 2010 Beta 2 Remotedebugger ausgegeben. Daher wahrscheinlich der Sprachenmix.

Lösung

Der IIS muss die Integrierte Windows-Authentifizierung aktiviert haben. Danach lief alles so, wie es sollte.