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?

Bei der Verteilung eines Microsoft System Center Data Protection Manager 2007 Agent auf einen Microsoft Windows Server 2008 gab es Probleme. Ich hatte die Firewalls untersucht, zu Testzwecken sogar ausgeschaltet (meistens steckt die Lösung zu Software-Verteilungsproblemen ja in der Firewall: irgendein Port, der nicht geöffnet ist…). Trotzdem gab es keine Besserung. Ich bekam beim Verteilen des Agent immer wieder die folgende Fehlermeldung:

Fehler bei Schutz-Agent auf dc.ConTrans.local installieren:
Fehler 313: Fehler beim Agent-Vorgang. Bei der Ausführung des Installationsprogramms auf dc.ConTrans.local ist ein Fehler aufgetreten.
Fehlerdetails: Schwerwiegender Fehler bei der Installation (0x80070643)
Empfohlene Aktion: Überprüfen Sie die Protokolldateien auf dc.ConTrans.local: [windir]\temp\msdpm*.log, und führen Sie die entsprechende Aktion durch. Wiederholen Sie den Vorgang. Wenn der Fehler weiterhin auftritt, starten Sie den Computer neu, und wiederholen Sie den Vorgang erneut.

Die Lösung

Auch die Installation verschiedener Hotfixes ergab keine Besserung. Weiter half mir hier nur die manuelle Installation des Agents auf dem Zielserver.

Die Installationsdateien befinden sich hier:

C:\\Program Files\\Microsoft DPM\\DPM\\Agents\\RA\\Versionsnummer

Versionsnummer ist hier nur ein Platzhalter, der angibt, welche Agent-Version installiert werden kann. Sie sollten hier die höchste Version wählen (aktuell: 2.0.8864.0). In den Unterordnern des Versionsnummern-Verzeichnisses sind die unterschiedlichen Versionen des Agents vorhanden:

• i386 für 32-Bit Maschinen
• amd64 für 64-Bit Maschinen

Das nächste Unterverzeichnis gibt die Sprache an (1033 für Englisch, 1031 für Deutsch) und darunter befinden sich dann die Installationsdateien. Ein Beispielpfad wäre also:

C:\\Program Files\\Microsoft DPM\\DPM\\Agents\\RA\\2.0.8864.0\\amd64\\1033

Haben Sie den Pfad gefunden, können Sie eine Freigabe darauf machen oder aber die Dateien auf die zu schützende Maschine kopieren. An der Kommandozeile geben Sie dann den folgenden Befehl ein:

• 32-Bit-Installation: DPMAgentInstaller ServerName
• 64-Bit-Installation: DPMAgentInstaller_AMD64 ServerName

Wobei ServerName den Namen den DPM-Servers enthält.

Starten Sie nach der Installation den Rechner neu.

Im letzten Schritt müssen DPM und Agent miteinander bekannt gemacht werden. Dies geht auf 2 Arten:

• Agent-Installation auf dem DPM erneut ausrollen
• DPM-Power Shell starten und folgenden Befehl eingeben:
  Attach-ProductionServer.ps1 DPMServerName ServerName BenutzerName Passwort Domäne
  Wobei
  • DPMServerName der Name des DPM-Servers
  • ServerName der Name des zu schützenden Servers
  • BenutzerName und Passwort Zugangsdaten eines Domänen-Admin Kontos
  • Domäne die Windows Domäne

  darstellen.

www.youtube.com/watch?v=eWpa2d23_WI

Wenn Sie die Ordnerumleitungen Ihrer Systeme per Gruppenrichtlinie ändern, kann es vorkommen (in meinem Fall war das bei jedem XP-System so!), dass Ihre Windows XP Systeme diese Aktualisierung nicht annehmen. Besonders, wenn Sie die Gruppenrichtlinie auf Vista/Windows 7 ausrichten. Hier die Anleitung für einen schnellen Fix.

1. Ändern Sie alle Einträge der Windows Registry, in der der alte Pfad vorkommt (Start->Ausführen, dann regedit.exe eingeben und über suchen alle Einträge zum alten Pfad suchen), so dass die Pfade auf den neuen Ort zeigen
2. Löschen Sie die File-Deployment-Dateien (.ini-Dateien) unter C:\Dokumente und Einstellungen\Benutzername\Lokale Einstellungen\Anwendungsdaten\Microsoft\Windows\FileDeployment

Danach melden Sie sich ab und wieder neu an. Das war es “schon”. Der Prozess kann je nach Maschine schon mal eine Weile dauern. Wenn aber ein System möglichst schnell wieder zum Laufen gebracht werden soll, kann man diesen Weg gehen. Diesen Prozess müssen Sie mit jedem Domänen-Benutzer, der schon mal an der Maschine angemeldet war, wiederholen….. Die elegantere (und schnellere) Lösung ist hier natürlich, auf Windows 7 wechseln… (ich sollte glaube ich mit Microsoft mal über Provisionen verhandeln )

Hoppla, da ist mir beim Umzug doch ein Fehler unterlaufen! Ich habe die Links für das neue Blog falsch eingrichtet, so dass die meisten Google-Suchanfragen auf eine fehlende Seite verlinkt waren und die berüchtigte 404-Fehler-Seite angezeigt wurde.

Ich möchte Sie hierfür um Verzeihung bitten, da mir das eben erst aufgefallen ist. Meine Statistiken hatten mir zwar angezeigt, dass einige Treffer auf die 404-Seite liefen, doch hatte ich zuerst angenommen, dass dies mit dem DNS-Umzug des Domain-Namens (blog.pmd-media.com) zu tun hatte. Ich habe die Links allerdings sofort korrigiert und sie sollten nun wieder alle funktionieren.

Also, das Blog ist wieder auffindbar und ich freue mich auf Ihre Kommentare.

Beste Grüße aus Korbach,

Frank Piotrowsky