Tech-Tipp: FileZilla XML-Fehler

Merkwürdiges Problem: Beim Start von FileZilla habe ich eine ganze Reihe von Fehlermeldungen erhalten, dass irgendwelche XML-Dateien nicht geöffnet oder geschrieben werden konnten:

Beim Aufbau von Verbindungen sowie beim Schließen kamen auch wieder eine ganze Reihe solcher Meldungen. Außerdem waren meine gespeicherten Einstellungen verschwunden.

Ursache und Lösung des Problems:
Offenbar wurde unter „C:\Program Files (x86)\FileZilla FTP Client“ die Datei fzdefaults.xml angelegt, die auf „%appdata“\filezilla\“ als Dateipfad für Konfigurationsdateien verweist. Da diese Datei ein älteres Datum hat, kann es sein, dass sie von einer älteren FileZilla-Version stammt und nun mit der aktuellen FileZilla-Version (3.9.0.2) dieses Problem verursacht. Nachdem ich die Datei gelöscht habe, sind meine gespeicherten Einstellungen auch wieder da und es kommen keine Fehlermeldungen mehr.

Tech-Tipp: Google Chrome ist schwarz

Mit mehreren Monitoren hat man unter Umständen das Problem, wenn die Grafikkarte zu schwach ist, dass Google Chrome einfach nur ein schwarzes Bild  anzeigt. Man kann Chrome in dem Fall zwar theoretisch noch bedienen, aber es bleibt ein Blindflug. Besonders ärgerlich ist es, wenn Chrome bisher funktionierte und erst nach einem Update schwarz bleibt. Chrome lässt sich mit einem Klick ganz oben rechts immer noch beenden (manchmal wird immerhin die Titelleiste mit dem X noch angezeigt) oder man schießt ihn sich über den Taskmanager ab. Aufgefallen ist das Problem erst mit der aktuellen Version 36.0.1985.125.

Man kann nun Google Chrome deinstallieren und eine ältere Version, die noch funktioniert hat, installieren, sofern man eine findet. Dann sollte man, bevor der Browser sich selbst updatet, in den Einstellungen von Chrome die Hardwarebeschleunigung ausschalten:

2014-07-21 14_20_37-

2014-07-21 14_14_53-Einstellungen

2014-07-21 14_15_17-Einstellungen

Oder man öffnet die Datei „Local State“ mit einem Texteditor (die Datei findet man unter C:\Users\[Profilname]\AppData\Local\Google\Chrome\User Data\) und sucht dort folgenden Eintrag:

"hardware_acceleration_mode": {
 "enabled": true

Den Wert true ändert man einfach auf false. Die Datei speichern und schon läuft Google Chrome wieder.

[Tech-Tipp] Windows Server 2012 Firewall und Linux Server LDAP-Abfrage

Ausgangssituation: In unserer Serverumgebung haben wir als Domain-Controller Windows Server 2012 im Einsatz. Einige Dienste (bspw. Confluence, Jira, Fisheye) laufen auf Linux-Servern und rufen die User-Credentials per LDAP-Anbindung von den Domain-Controllern ab. In den Log-Dateien der Linux-basierten Dienste haben wir regelmäßig Timeouts bzw. fehlgeschlagene LDAP-Verbindungen gefunden. Außerdem war es häufiger nötig, die Linux-Dienste neu zu starten, damit eine Benutzeranmeldung (wieder) möglich war.

Lösung: nach einiger Recherche bin ich darauf gestoßen, dass die Firewall der Windows Server seit Windows Server 2008 einen so genannten Stealth-Mode besitzt. Soweit ich das verstanden habe, werden dadurch Verbindungen von Clients zum Server kurz verzögert oder bei zu vielen Anfragen (automatisierte Anfragen) abgelehnt. Dieser Stealth-Mode kann nur über eine Änderung an der Registry ausgeschaltet werden. Weitere Infos: http://technet.microsoft.com/en-us/library/dd448557%28WS.10%29)

HKLM\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile

Hier einen neuen DWORD-Eintrag mit dem Namen „DisableStealthMode“ (Groß- und Kleinschreibung beachten) und dem Wert „1“ anlegen. Nach einem Neustart des Servers ist der Stealth-Mode für das Domänen-Profil der Firewall deaktiviert. Unter Umständen kann es notwendig sein, dass auch in den anderen Firewall-Profilen (falls angelegt und in Benutzung) dieser Eintrag gemacht werden muss.

Fazit: Seit der beschriebenen Änderung an den Domain-Controllern kommt es zu keinen Fehlermeldungen mehr und keiner der Linux-Server bzw. Linux-Dienste musste seitdem neugestartet werden.

[Tech-Tipp] Windows 8.1 Ruhezustand Monitor-Bug

In den letzten Tagen beschäftigte mich ein merkwürdiges Problem bei einem DELL Inspiron 15 mit Windows 8.1. Ging der Laptop nach 15 Minuten in den Ruhemodus, konnte das Display nicht reaktiviert werden. Eine Verbindung per RDP konnte nicht wirklich hergestellt werden (das Bild blieb schwarz), aber bspw. mit mmc, psexec oder über die administrativen Freigaben konnte ich auf den Laptop zugreifen. Um wieder richtig mit dem Gerät arbeiten zu können, war ein Hard-Reset nötig.

Nachdem ein Update aller Grafikkartentreiber nichts brachte, musste ich die Lösung an anderer Stelle suchen. Da ich die Original-Festplatte gegen eine (auch von DELL bezogene) SSD getauscht hatte, wollte ich nun ein eventuelles Kompatibilitätsproblem ausschließen und baute die ursprüngliche Platte wieder ein. Dort war noch der Werkszustand vorhanden, also Windows 8 ohne weitere Updates. In diesem Zustand funktionierte der Ruhemodus tadellos. Auch nach der Installation sämtlicher verfügbarer Windows-Updates inklusive der von Windows Update bereitgestellten Treiberupdates funktionierte der Ruhemodus so, wie er sollte.

Nach dem Upgrade auf Windows 8.1 war das Problem plötzlich da. Die meisten in Internetforen erwähnten Tipps (Treiber aktualisieren, Kennwortabfrage bei Reaktivierung deaktivieren usw.) haben nicht geholfen. Da sich das Problem doch relativ gut auf die Grafikkarte und somit genauer auf die verbaute ATI-Grafikkarte eingrenzen ließ (das Catalyst Control Center konnte nicht gestartet werden), habe ich es sogar mit den aktuellen Beta-Treibern von ATI ausprobiert, doch auch hier gab es keine Änderung am Verhalten. Ebenso half auch kein Update der Intel Chipsatz-Treiber und der Treiber für die integrierte Intel-Grafikkarte.

Der letzte Schritt, nämlich die Deaktivierung des Ruhemodus durch „powercfg -h off“ (hierzu muss die Kommandozeile mit Admin-Rechten gestartet werden; danach ein Neustart), konnte das Problem mehr oder weniger beseitigen. Es ist zwar nur ein Workaround, weil der Ruhemodus anschließend ja ausgeschaltet ist, wichtiger ist aber, dass man den Laptop wieder reaktivieren kann, wenn die Energiespar-Optionen greifen. Vermutlich hilft es auch, den Energie-Plan auf „Höchstleistung“ zu setzen und den Bildschirm nie ausschalten zu lassen.

Offenbar betrifft dieses Problem hauptsächlich Laptops, die neben der integrierten Intel-Grafik noch eine zusätzliche ATI-Grafikkarte verbaut haben. Jedenfalls konnte ich das soweit durch Internetrecherche eingrenzen. Sehr wahrscheinlich ist der ATI-Treiber an diesem Problem schuld. Auf allen anderen Laptops (ohne ATI-Grafik), die ich hier getestet habe, tritt das Problem nicht auf. Andererseits kann es auch sein, dass Windows 8.1 Probleme damit hat, wenn zwei Grafikkarten unterschiedlicher Hersteller verbaut sind. Letztendlich kann man nur abwarten, ob es dafür irgendwann einen Windows-Patch oder einen passenden ATI-Treiber gibt.

Tech-Tipp: Rechtsklick auf Startbutton unter Windows 8.1

Wahrscheinlich bin ich nicht der einzige Admin, der an folgendem Problem fast verzweifelt (wäre):

Nach der Aufnahme eines Windows 8.1-PCs in die Domäne funktioniert bei den Domänenbenutzern der Rechtsklick auf den Startbutton nicht.

Ok, das ist nicht ganz zutreffend formuliert. Besser: Bei Domänenbenutzern, die sich an einem Windows 8.1-PC das erste Mal anmelden, funktioniert der Rechtsklick auf den Startbutton nicht. Lokale Benutzer haben das Problem nicht. Auch nicht die Benutzer, die vor dem Upgrade schon mal angemeldet waren. Es ist also prinzipiell unerheblich, ob der PC vor oder nach dem Upgrade auf Windows 8.1 in die Domäne aufgenommen wurde.

Die Lösung ist mehr oder weniger ein Workaround, aber immerhin gibt es hier eine Lösung. Und zwar wird beim Anlegen des lokalen Profils des Domänenbenutzers der Ordner „C:\Users\[Benutzer]\AppData\Local\Microsoft\Windows\WinX“ nicht erstellt. Dieser ist jedoch maßgeblich dazu da, das Kontextmenü für den Startbutton anzuzeigen. Den Ordner (mit seinen Unterordnern) kann man jedoch problemlos aus einem anderen Benutzerprofil (oder am besten aus dem Profil des Default-Benutzers) kopieren. Ein Neustart oder eine erneute Anmeldung des Benutzers ist nicht nötig. Der Rechtsklick auf den Startbutton funktioniert direkt nach dem Kopiervorgang.

Vor allem, weil der fehlende Ordner im „Local“-Bereich liegt, ist es ärgerlich, da man den Vorgang für jeden Benutzer erneut durchführen muss, sofern er sich an einem anderen Windows 8.1-PC anmeldet. Denn dieser Teil wird auch bei einem servergespeicherten Profil nicht auf dem Server gespeichert (da es sich hier ja nur um eine lokale Einstellung handelt).

Das ist eine Sache, die Microsoft nachbessern muss.

[Update 25.04.2014] Weil es mich nervte, habe ich ein kleines Batch-Script erstellt, welches ich über Gruppenrichtlinien im Benutzer-Kontext (Benutzerkonfiguration -> Richtlinien -> Windows-Einstellungen -> Skripts -> Anmelden) laufen lasse:

@echo off
ver | findstr /i "6\.3\." > nul
IF %ERRORLEVEL% EQU 0 goto WIN8START

:WIN8START
if not exist %localappdata%\microsoft\windows\winx\ (
 xcopy %homedrive%\users\default\appdata\local\microsoft\windows\winx %localappdata%\microsoft\windows\WinX /E /I /H /Q
)

Zur Erklärung:
Mit ver | findstr … suche ich in der Ausgabe von ver nach dem String 6.3 (Windows 8 hat Version 6.3.x). Wenn dies zutrifft, erhalte ich den Fehlercode 0 (also keinen Fehler) und sage dem Script, dass es nun zum Abschnitt WIN8START gehen soll. Ist der Fehlercode ein anderer, bedeutet dies, dass kein 6.3 in der Versionsnummer von Windows gefunden wurde und es sich damit nicht um Windows 8 handelt. An der Stelle hört das Script dann auf.

Im Abschnitt WIN8START prüfe ich zunächst, ob das Verzeichnis WinX beim angemeldeten Benutzer existiert. Ist dies nicht der Fall (if not exist) kopiert das Script mit xcopy (copy geht nicht – vermutlich weil es sich um ein verstecktes Verzeichnis handelt) den WinX-Ordner vom Default-Benutzer in das Verzeichnis des angemeldeten Benutzers.