Eine Suche im Internet ergab wenig Hilfreiches und so machten wir uns gemeinsam an die Diagnose. Der Ordner %windir%\Microsoft.NET\Framework\v2.0.50727\CONFIG enthält einen Haufen von Dokumenten, ebenso die laut Fehlermeldung korrupte Datei machine.config und eine machine.config.default.

Um hier etwas ändern zu können benötig man erhöhte Rechte und so öffneten wir eine Shell als Administrator (runas). Ein Blick in die Dokumente mit dem Programm notepad brachte auf den ersten Blick wenig Unterschiede ans Tageslicht und so machten wir die Probe aufs Exempel:

Der Befehl

rename machine.config machine.config.COPY

benennt die korrupte Datei um, mit

copy machine.config.default machine.config

erzeugt man einen neue machine.config Datei.

Der Start von PaintDotNet lief nun sauber durch und auch die anderen Programme liefen wieder.

Hinweis:

Ob der hier aufgezeigte Weg der Masterweg ist, bleibt dahingestellt. Ich bin weder .NET Experte noch ein .NET Programmierer.

Das wichtigste war, dass die Programme wieder liefen.

Ein Besucher kann die nach Extern freigegebene Seite ebenfalls per http oder per https erreichen.
Auf dem Webserver liegt ein Script, welches beim Aufruf den Besucher von einer unverschlüsselten auf eine verschlüsselte Seite umleitet (Typo3 / https_enforcer).

Beobachtung: Beim (externen) Besuch der Webseite und dem Aufruf des Scriptes wird im Firefox Browser angezeigt, dass die Webseite sich endlos neu aufruft und die Anfrage nicht beendet werden kann. Der IE (Version lädt endlos weiter.

Für ein Debugging schalteten wir auf dem Besucher das Tool Fiddler ein und beobachten die Rückmeldungen, welche vom Webserver (ISA) an den Browser gesendet wurde. Dabei stellten wir fest, dass der Webserver zwar ein “302, Moved temporarily” sendet, der Location Teil des Headers aber imm auf http://(webseite) stand.

Damit lag der Fehler irgendwo zwischen Webserver (sendet er das Richtige an den Besucher?) und ISA Firewall (Bekommt der Besucher auch die richtigen Daten ausgeliefert?).

Eine tiefere Diagnose mit Network Monitor brachte den “Schuldigen” ans Tageslicht: Der Webserver liefert zwar das richtige an den Besucher aus, der ISA verfälscht jedoch das Location Element im Header und tauscht “https” gegen “http” aus:

Nun passiert folgendes:

1. Der Browser des Besuchers greift beim ausführen des 302ers auf die http Verbindung zurück
2. Der Webserver, respektive das https_enforcer Plugin, erkennt eine unverschlüsselte Verbindung und sendet wieder den 302 mit Location https://(webseite) an den Besucher zurück
3. Der ISA modifiziert das Location Feld und ersetzt wieder https gegen http
4. Fertig ist die Ladeschleife

“Schuld” ist eine Funktion im ISA 2006, welche interne auf externe Website-Namen umschreiben kann. Die Linkübersetzung erlaubt es, interne Namen auch extern nutzen zu können, indem sie sie in gültige, im Internet erreichbare Namen übersetzt.

In diesem Fall war die Lösung relativ einfach. Da auf dem betroffenen ISA die Linkübersetzung (weder lokal noch global) benutzt wurde, reichte es, das “Linkübersetzungsfilter” unter Add-Ins zu deaktivieren.

Das Blog von MRVirtual bringt weitere Lösungen für den Fall, dass die Linkübersetzung doch benötigt wird.

Schnell war klar, dass es etwas mit Javascript zu tun haben musste denn Windows-Update lädt am Anfang gleich ein Javascript ein von dem aus die Besucher weiter geschubst werden. Genau das aber funktionierte nicht mehr.

Die Internet Explorer Sicherheitszonen auf Standardstufe zurücksetzen, die Einstellungen des Browsers zurückzusetzen oder gar den IE 8 neu zu installieren brachte auch keine Besserung.

In einem Forum fand ich dann die Lösung:

Als Administrator öffnet man eine Shell im Verzeichnis “%SYSTEMROOT%\SYSTEM32″, tippt die Befehle

regsvr32 vbscript.dll
regsvr32 jscript.dll

ein, startet den Browser neu und schon geht es wieder.

Zum Glück habe ich immer eine zweite UMTS Karte dabei (bitte nicht fragen wieso) auf der jedoch keine Flatrate gebucht ist. Also, kurz ins Netz und google angeworfen: nix. Also nix brauchbares denn die Tipps die da auftauchen haben bei mir nicht zur Problemlösung beigetragen.

Nach der x-ten Deinstallation bemerkte ich, dass die Einwahlverbindung nicht gelöscht wird, wenn ich die Mobile Partner Software deinstalliere. Also, Einwahl “Internet” gelöscht und sie von Mobile Partner nach einer Neuinstallation wieder neu einrichten lassen. Und siehe da, das Internet ist wieder da

Nun noch schnell di.fm angeworfen und das Wochenende kann kommen.

Die Exchange Integration besteht aus dem Disk-Agenten, dem Media-Agenten und der MS Exchange Integration selbst. Diese drei Komponenten wurden entsprechend der Vorgabe aus der Anleitung installiert und die Umlaufprotokollierung der Exchange Speichergruppe wurde ausgeschaltet.

Zur Vorsicht starteten wir den Exchange Server noch einmal durch. Die Meldung verschwand jedoch nicht.

In einem HP Forum wurden wir dann fündig: Dort stand zu lesen, dass man die Variable EXCHANGE_HOME mit dem Pfad zum Exchange definieren sollte – und tatsächlich.
Ein anderer Standort, eine andere Sicherungszelle – hier war auf dem Exchange-Server das “bin” Verzeichnis des Exchange-Prozesses in den Pfad eingetragen.

Anstelle eine Variable EXCHANGE_HOME zu definieren, erweiterte ich den PATH um

C:\Programme\Exchsrvr\bin

und startete den DP Prozess auf dem Exchange-Server neu.

Nun ließ sich im DP Manager Exchange auswählen und ich konnte den Job erfolgreich anlegen.