Keine Ahnung, wie oft ich im Laufe der Jahre dem Windows 7-Assistenten zum Ermitteln der Probleme des Audiodienstes zugesehen habe …

… jedenfalls ist mir bis gestern noch nie aufgefallen, daß in der Titelzeile “Wiedergeben von Audiodataeien” steht.

Auch wenn glücklicherweise nicht mehr in jedem zweiten “Ich optimiere mir mein Windows kaputt”-Beitrag zu Experimenten mit der MTU-Einstellung geraten wird, kann es trotzdem sein, daß je nach Netzwerkkonfiguration eine Änderung des aktuellen Werts notwendig ist. Wenn auch etwas “versteckt”, so kann dies problemlos mit Windows-Bordmitteln bewerkstelligt werden:

Im ersten Schritt muß die Netzwerkschnittstelle ermittelt werden, für welche die Einstellungen modifiziert werden sollen, was - genauso wie die spätere Änderung - mit dem Kommandozeilenprogramm “netsh” möglich ist.

C:\>netsh interface ipv4 show interfaces

Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  1          50  4294967295  connected     Loopback Pseudo-Interface 1
 12          10        1500  connected     LAN-Verbindung

Die wichtigen Informationen finden sich in den Spalten “MTU” sowie “Name”, in denen zum einen die aktuelle Einstellung und zum anderen der Name der zu ändernden Verbindung ausgegeben wird.

Die Änderung erfolgt durch einen weiteren Aufruf von “netsh”, wobei darauf zu achten ist, daß dieser als Administrator ausgeführt wird.

C:\>netsh interface ipv4 set interface "LAN-Verbindung" mtu=1500 store=active

Der Text “LAN-Verbindung” muß ggf. durch den im ersten Schritt ermittelten Schnittstellennamen ersetzt werden, der Wert “1500” durch den neuen Schnittstellenwert und über den Parameter “store” lässt sich steuern, ob die neue Einstellung nur bis zum nächsten Systemstart (“active”) oder darüber hinaus (“passive”) behalten wird.

In einer Domäne ist es recht einfach, einen Rechner remote heruterzufahren. Einfach an der Kommandozeile

shutdown -s -t 0 -m \\HerunterzufahrenderRechner

eingeben und sofern der ausführende Benutzer innerhalb der Domäne die benötigten Rechte hat, führt der angegebene Rechner den Befehl klaglos aus.

Nicht so trivial ist das Szenario bei Rechnern im z.B. heimischen Umfeld, wo nur selten eine zentrale Benutzerverwaltung aktiv sein dürfte:

shutdown -s -t 0 -m \\HerunterzufahrenderRechner
 HerunterzufahrenderRechner: Zugriff verweigert(5)

Als ersten Lösungsansatz stößt man meistens auf den Hinweis, sich zuerst mittels einer administrativen Netzerkverbindung gegenüber dem herunterfahrenden Rechner zu authentifizieren, wofür sich z.B. die Freigabe IPC$ anbietet:

net use \\HerunterzufahrenderRechner\ipc$
 Das Kennwort oder der Benutzername ist ungültig für \\HerunterzufahrenderRechner\ipc$

Geben Sie den Benutzernamen für "HerunterzufahrenderRechner" ein: Benutzer
 Geben Sie das Kennwort für "HerunterzufahrenderRechner" ein:
 Der Befehl wurde erfolgreich ausgeführt.

Unter Windows XP war dies schon vollkommen ausreichend, unter Windows Vista und Windows 7 wird allerdings weiterhin der Zugriff verweigert. Wie der KnowledgeBase-Artikel “Description of User Account Control and remote restrictions in Windows Vista” erklärt, handelt es sich hierbei um ein Feature und keinen Bug:

When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection by using the net use * \remotecomputer\Share$ command, for example, they will not connect as a full administrator. The user has no elevation potential on the remote computer, and the user cannot perform administrative tasks.

Um auch über das Netzwerk verbundenen, lokalen Benutzern entsprechende Berechtigungen zu erteilen, ist das setzen des Registry-Schlüssels “LocalAccountTokenFilterPolicy” innerhalb des Pfades

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

notwendig, dieser muß als DWORD mit dem Wert 1 angelegt werden.

Auch wenn viele sehr traurig über das baldige Ende des Wartungszeitraums von Windows XP sind, war nicht alles wirklich gut, was 2002 eingeführt wurde.

Eine der sinnlosen bis ärgerlichen Funktionen war die Speicherung von automatisch generierten Miniaturansichten in Dateien namens “Thumbs.db”, die standardmäßig aktiviert war und bevor man es richtig merkte, die Platte ohne Sinn und Zweck vollzumüllen begann.

Abhilfe war schnell geschaffen: einfach unter “Extras” / “Ordneroptionen” zur Registerkarte “Ansicht” wechseln und den Haken bei “Miniaturansichten nicht zwischenspeichern” setzen und es wurden zumindest keine neuen “Thumbs.db” mehr erzeugt - um die Entsorgung der bereits vorhandenen musste sich der jeweilige Benutzer noch selbst kümmern.

Auch spätere Windows-Versionen waren ähnlich in den Griff zu bekommen, bis unter Windows 7 ein neues Phänomen auftrat:

Obwohl lokal keine “Thumbs.db” mehr erzeugt und laut Synchronisationsprotokoll auch keine über das Netz bewegt wurde, waren auf einigen Netzlaufwerken diese Dateien plötzlich wieder zu finden. Unabhängig von den lokalen Einstellungen scheint Windows 7 nach Lust und Laune (wahlweise auch nach hochkomplexen Algorithmen) sich fleißig an die Generierung von “Thumbs.db” auf vebundenen Netzlaufwerken zu machen.

Da so spontan kein offensichtlicher Schalter zu finden war, half ein Blick in die Gruppenrichtlinien, aufzurufen mittels “gpedit.msc”.

Dort gibt es unter “Benutzerkonfiguration” / “Administrative Vorlagen” / “Windows-Komponenten” / “Windows-Explorer” den eigentlich selbsterklärenden Punkt “Zwischenspeicherung von Miniaturansichten in versteckten ’thumbs.db’-Dateien deaktivieren”, der von “Nicht konfiguriert” auf “aktiviert” umgestellt werden muß.

Wenn Sie diese Richtlinieneinstellung aktivieren, werden in Windows-Explorer keine thumbs.db-Dateien erstellt und keine Lese- und Schreibvorgänge für diese Dateien durchgeführt.

Selbstverständlich hat auch diese Einstellung keine Auswirkungen auf bereits erstellte “Thumbs.db”, die wieder einmal manuell entsortg werden müssen.

Während Windos XP und OpenELEC problemlos mit einem DD-WRT-basierten Samba-Server Daten austauschen konnten, wurden die Freigaben von Windows 7 aus noch nicht einmal angezeigt. Umschifft werden konnte der Fehler durch Auskommentieren der Zeile

max protocol = SMB2

in der Datei “/tmp/smb.conf” und einem Neustart des nmbd und smbds.

Dieses Verhalten widerspricht der Tatsache, daß SMB2 gerade für Windows Vista / Server 2008 und höher eingeführt wurde, so daß das Herausnehmen der Zeile vermutlich ein Herumoperieren an den Symptomen statt die Behebung der Ursache ist.

Um sachdienliche Hinweise wird gebeten!