Normalerweise tritt der Fehler auf, wenn entweder die Java Runtime nicht installiert ist oder das Java Sicherheitszertifikat bei der ersten Anmeldung an CP Web nicht akzeptiert wurde. In diesem Fall tritt der Fehler jedoch auch dann auf, wenn beides korrekt eingerichtet ist.

Zudem sind nur Systeme mit Windows 7 oder Windows Server 2008 R2 betroffen – mit Windows XP gibt es keine Probleme. Darüberhinaus werden unmittelbar nach der Anmeldung in CP Web folgende Fehler in der Java Konsole protokolliert:

java.lang.NullPointerException
at com.corporate.planning.slider.fisimplementation.datamodel.FISModel.getNearestStartIndex(FISModel.java:289)
at com.corporate.planning.slider.framework.TimeSlider.modelReloaded(TimeSlider.java:1238)
at com.corporate.planning.slider.framework.TimeSlider.setModel(TimeSlider.java:1230)
at com.corporate.planning.slider.fisimplementation.applet.FISSliderApplet$RunnerThread.run(FISSliderApplet.java:424)

Folgendes hatte ich vergeblich getestet:

• Internet Explorer Cache gelöscht
• Internet Explorer zurückgesetzt
• Java Cache gelöscht
• Zertifikat mittels Java Systemsteuerung entfernt
• Java neu installiert

Kurzum: Das Problem entsteht durch den Aufruf von CP Web über IPv6. Unser CP Web Server läuft auf einem Windows Server 2008 R2 mit aktiviertem IPv6. Ruft man den Webserver über den Namen wie z.B. http://cp-web/ auf, findet die Kommunikation zwischen Server und Client über IPv6 statt, was die Anwendung offenbar noch nicht vollständig unterstützt.

Wird die Webseite über die IPv4 Adresse des Servers aufgerufen, werden alle Java Elemente korrekt geladen und die oben beschriebenen Java Fehlermeldungen treten nicht auf.

-----BEGIN CERTIFICATE-----
MIIDKTCCAtOgAwIBAgIJAItZm8m/4nSaMA0GCSqGSIb3DQEBBQUAMIGXMQswCQYD
VQQGEwJERTEWMBQGA1UECBMNTmllZGVyc2FjaHNlbjERMA8GA1UEBxMISGFubm92
ZXIxDzANBgNVBAoTBkxheWVyOTEPMA0GA1UECxMGTGF5ZXI5MR0wGwYDVQQDExRs
YXllcjkud29yZHByZXNzLmNvbTEcMBoGCSqGSIb3DQEJARYNbGF5ZXI5QGdteC5k
ZTAeFw0xMjAxMTkxNTIyNTVaFw0xNTAxMTgxNTIyNTVaMIGXMQswCQYDVQQGEwJE
RTEWMBQGA1UECBMNTmllZGVyc2FjaHNlbjERMA8GA1UEBxMISGFubm92ZXIxDzAN
BgNVBAoTBkxheWVyOTEPMA0GA1UECxMGTGF5ZXI5MR0wGwYDVQQDExRsYXllcjku
d29yZHByZXNzLmNvbTEcMBoGCSqGSIb3DQEJARYNbGF5ZXI5QGdteC5kZTBcMA0G
CSqGSIb3DQEBAQUAA0sAMEgCQQCmqgYLjxnRn2Ql1BTkvl+uba+jE6RvifHUv3bO
r0+9/JxAmWXAP6JEetyROgfnC+ZEZXejbqNn6DvlCgnJsAR9AgMBAAGjgf8wgfww
HQYDVR0OBBYEFOU3k7k03qMI679D0Rup/JvL1mFwMIHMBgNVHSMEgcQwgcGAFOU3
k7k03qMI679D0Rup/JvL1mFwoYGdpIGaMIGXMQswCQYDVQQGEwJERTEWMBQGA1UE
CBMNTmllZGVyc2FjaHNlbjERMA8GA1UEBxMISGFubm92ZXIxDzANBgNVBAoTBkxh
eWVyOTEPMA0GA1UECxMGTGF5ZXI5MR0wGwYDVQQDExRsYXllcjkud29yZHByZXNz
LmNvbTEcMBoGCSqGSIb3DQEJARYNbGF5ZXI5QGdteC5kZYIJAItZm8m/4nSaMAwG
A1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADQQAlQIKYF37+IbXy5QnjkXmdqm9X
y1mhbRglr9St+Gqvz2ko4aaRwsIfrxRpbvlq6IFd9PLVS/udlx//n7V+CeAk
-----END CERTIFICATE-----

Speichert man das Zertifikat als Textdatei und importiert es in den „Personal Certificate Store“ des Computerkontos, fehlt allerdings der dazugehörige private Schlüssel und das Zertifikat kann nicht genutzt werden.

Um den privaten Schlüssel zu importieren, generiert man mittels OpenSSL einfach ein PKCS#12 Zertifikat, das neben dem Zertifikat auch den privaten Schlüssel enthält:

srv:/# openssl pkcs12 -export -in certificate.pem -inkey privatekey.pem \
-out certfinal.pfx

Ob Private Key und Zertifikat zueinander passen, lässt sich im Zweifel durch das Vergleichen der Prüfsummen von Schlüssel und Zertifikat feststellen. Beide Zahlen müssen identisch sein:

srv:/# openssl x509 -noout -modulus -in certificate.pem | openssl md5 \
19d0a008c19152777ded2b757f26e5c5
srv:/# openssl rsa -noout -modulus -in privatekey.pem | openssl md5 \
19d0a008c19152777ded2b757f26e5c5

Durch den Import der PFX-Datei lassen sich Zertifikat und Schlüssel dann in einem Rutsch hinzufügen.

• Während der Navigation auf Netzlaufwerken frohr der Explorer ein und auch der Zugriff auf andere UNC-Pfade via „Ausführen“ war nicht mehr möglich. Der Prozess explorer.exe ließ sich im Task Manager erst nach einigen Minuten beenden und neu starten. Nach dem Neustart des Explorers funktionierte der Zugriff auf das Netzwerk wieder.
• Beim Speichern in Excel und Word 2010 kam es sporadisch zu folgender Fehlermeldung, obwohl der Pfad verfügbar war:
  
  [DATEINAME] kann nicht gefunden werden. Überprüfen Sie die Rechtschreibung,
  oder verwenden Sie einen anderen Pfad.
• Das Öffnen und Speichern von auf Netzlaufwerken gespeicherten Dateien schlug mit diversen Fehlermeldungen fehl.

Die Probleme traten völlig sporadisch und auf diversen Rechnern mit unterschiedlichen Windows 7 Images auf, Windows XP war überhaupt nicht betroffen. Die Neuerstellung des Benutzerprofils half genausowenig wie Zuverlässigkeitsupdate 2515325, das Abstürze im Zusammenhang mit dem Windows Explorer beheben soll. Das Scannen von Netzlaufwerken im Virenscanner war ebenfalls deaktiviert und auch neue Windows Updates wurden zuvor nicht verteilt.

Dann ging ich alle Änderungen durch, die in den letzten Wochen stattfanden und möglicherweise im Zusammenhang mit den Problemen stehen konnten.

Die einzige größere Änderung war der Austausch des letzten Windows Server 2003 Domänencontrollers durch Windows Server 2008 R2. Wobei das Active Directory und dazugehörige Dienste wie DNS problemlos funktionierten – schließlich gab es bei den Servern und Windows XP keinerlei Auffälligkeiten.

Im Rahmen des Serverwechsels von 2003 auf 2008 R2 fand allerdings auch eine kleine Änderung am DFS statt: Der für die Netzlaufwerke verwendete DFS Namespace besteht aus drei Root-Targets bzw. DFS Namespace Servern. Einer dieser Server war der alte Domänencontroller, der durch den 2008 R2 Server ersetzt wurde.

Natürlich hatte ich das Root-Target nach dem Wechsel auf den neuen Server angepasst und den Status geprüft – offenbar kam es nach einigen Tagen aber zu einem Fehler, der dazu führte, dass das Root-Target nicht mehr funktioniert. Beim Entfernen des Root-Targets aus dem DFS Namespace kam es nämlich zu folgender Fehlermeldung:

Kurze Zeit nach dem Entfernen des defekten Eintrags traten alle oben genannten Probleme nicht mehr auf. Das erklärt auch, warum die Probleme nur sporadisch aufgetreten sind: Bei mehreren DFS Root-Targets bzw. Namespace Servern wird nicht immer derselbe Pfad verwendet, sondern zwischen den Pfaden gewechselt:

War der fehlerhafte Pfad ausgewählt, kam es zu den genannten Problemen. War einer der funktionierenden Pfade aktiv, traten die Probleme nicht auf.

Nicht erklären lässt sich dagegen, warum das Problem unter Windows XP überhaupt nicht auftrat. Möglicherweise ist das Einfrieren des Explorers aber auch einem bislang unbekannten Fehler in Windows 7 geschuldet – schließlich darf es nicht vorkommen, dass bei Nicht-Verfügbarkeit eines Pfades der gesamte Explorer nicht mehr funktioniert und auch keine anderen Freigaben im Netzwerk mehr aufgerufen werden können.

Mittlerweile gibt es von Microsoft mit KB2640148 aber auch schon wieder ein neues Zuverlässigkeitsupdate für Windows 7, das abermals Probleme mit dem Windows Explorer und Netzlaufwerken beheben soll.