Hallo Fans,

vor einiger Zeit entschied ich mich, mir endlich mal wieder einen Gaming-PC zuzulegen, da Zocken mit dem Thinkpad X220 bzw. der integrierten Intel HD 3000 nicht mehr wirklich Spaß machte. Spiele wie Left4Dead oder Fallout 3 konnte ich nur in niedrigsten Auflösungen und Details spielen, was schon sehr frustrierte. Da ich schon länger mit dem Gedanken spielte, mir ein mini-ITX Gaming-PC zu kaufen, schaute ich auf’s Konto und bestellte folgendes:

Gehäuse: Fractal Design Core 500
Netzteil: Be Quiet! Straight Power 10 mit 600 Watt
Mainboard: Asus Z170I Pro Gaming
CPU: Intel Core i5 6600K
RAM: Corsair Vengeance 32 GB DDR4-2400 Kit in schwarz (CMK32GX4M2A2400C14)
Grafikkarte: Asus 1060 GTX STRIX GAMING mit 6 GB VRAM
CPU-Kühler: Noctua NH U12S
Gehäuse-Lüfter: Noctua NF-A14 PWM

Der Einbau ging recht fix und ohne größere Probleme, trotz des doch sehr geringen Platzes, vonstatten. Lediglich die sehr große Grafikkarte wurde von den Kabeln des Netzteils ca. 5 mm nach vorne gedrückt, was mir überhaupt nicht gefiel.

Auf dem Foto kann man vielleicht grob erahnen, was ich meine:

Also ein wenig recherchiert und probiert und dabei festgestellt, dass man die Halterung des Netzteils ausbauen kann und man somit das Netzteil ca. 1,5 cm weiter zur Gehäuseseite verschieben kann.
Problem dabei ist dann, dass das Netzteil lose im Gehäuse liegt, was ich jedoch mit vier Klettband-Streifen ziemlich gut lösen konnte:

Die Kabel des Netzteils berühren jetzt zwar noch die Grafikkarte, üben dabei aber keinen Druck auf diese aus:

Für eine ordentliche Verkabelung im Gehäuse führt man am besten alle Kabel in den Raum zwischen Frontblende und Gehäuse und zurrt diese mit viel Kabelbinder irgendwie am Gehäuse fest. Da muss es auch nicht wirklich ordentlich aussehen:

Installiert wurde Windows 10 Pro in der 64bit Variante auf einer 120 GB Samsung Evo 840 SSD. Spiele und sonstige Programme liegen aktuell noch auf einer zweiten 120 GB Evo 840, welche jedoch bald durch ein größeres Modell ersetzt werden muss.

Das System ist dabei im Desktop-Betrieb mit vielen Chrome-Tabs und sonstiger Software unhörbar leise. CPU und Gehäuse-Lüfter drehen bei ca. 500 bis 800 Umdrehungen pro Minute lautlos vor sich hin.

Selbst bei Spielen wie Left4Dead, Fallout 3 oder StarCraft II in höchsten Einstellungen springen dank Zero-Fan-Modus der Grafikkarte die Lüfter nicht an. Bei aufwendigeren Spielen oder der Mondlandung-Grafikdemo von NVidia sind die Lüfter der Grafikkarte jedoch hörbar, da das Gehäuse direkt rechts neben dem Mousepad auf dem Schreibtisch steht.

Bei Prime95 und gleichzeitigem FurMark liegt die Temperatur der Grafikkarte bei ca. 65°C, die CPU bei 50°C.

Da auf Nicht-Terminalservern das Feature der Destopdarstellung eigentlich nichts zu suchen hat, die Server aber trotzdem (hoffentlich) Updates bekommen, ist hin un wieder eine Bereinigung durch die Datenträgerbereinigung nötig.

Um die Datenträgerbereinigung ohne Desktopdarstellungs-Feature unter Server 2008 R2 nutzen zu können, müssen nur zwei Dateien an einen anderen Ort kopiert werden.

C:\Windows\winsxs\amd64_microsoft-windows-cleanmgr_31bf3856ad364e35_6.1.7600.16385_none_c9392808773cd7da\cleanmgr.exe
muss nach
c:\windows\system32\

und

C:\Windows\winsxs\x86_microsoft-windows-cleanmgr.resources_31bf3856ad364e35_6.1.7600.16385_de-de_b4bbf0180b1c4f68\cleanmgr.exe.mui
muss nach
c:\windows\system32\de-de\

Nun kann man ganz normal die cleanmgr.exe über „Ausführen“ öffnen. Yay.

Hallo Fans,

Ich hatte vor Wochen bei einem Kunden das Problem, dass sich die verbundenen Standard-Drucker von verschiedenen (aber natürlich nicht allen) Benutzern mit Terminalserver-Profil nach Ab- und Wiederanmeldung auf den lokalen Standard-Drucker des Servers änderten.

Ca. 20% der betroffenen Benutzer meldeten zusätzlich, dass zuvor installierte Drucker nicht reproduzierbar nach Ab- und Wiederanmeldung verschwunden waren.

Im Anwendungs-Eventlog wurde parallel dazu bei der Abmeldung eines betroffenen Users die Warnung mit ID 1530 protokolliert:

Es wurde festgestellt, dass Ihre Registrierungsdatei noch von anderen Anwendungen oder Diensten verwendet wird. Die Datei wird nun entladen. Die Anwendungen oder Dienste, die Ihre Registrierungsdatei anhalten, funktionieren anschließend u. U. nicht mehr ordnungsgemäß.

DETAIL –
1 user registry handles leaked from \Registry\User\S-FAKE-USER-SID:
Process 564 (\Device\HarddiskVolume2\Windows\System32\svchost.exe) has opened key \REGISTRY\USER\S-FAKE-USER-SID\Printers\DevModePerUser

Irgendwas verhinderte also das korrekte Zurückschreiben von HKEY_CURRENT_USER in HKEY_USERS, sodass bei der nächsten Anmeldung des Benutzer falsche Werte aus HKEY_USERS geladen wurden.
Die Einstellungen unterhalb von HKCU\Software\Printers\ und HKCU\Software\Microsoft\Windows NT\CurrentVersion\, in denen die User-Druckereinstellungen gespeichert sind, sahen jedoch in einem Vorher-Nachher-Vergleich vollkommen identisch aus.

Jedoch fiel auf, dass zum Teil seit mehreren Jahren außer Betrieb genommene Drucker laut Registry immer noch verbunden sein sollten.

Die manuelle Bereinigung durch Löschung aller Einträge unterhalb der folgenden Schlüssel (falls vorhanden) brachte schließlich den Erfolg:

– HKCU\Printers\Connections
– HKCU\Printers\DevModes2
– HKCU\Printers\DevModePerUser
– HKCU\Printers\Settings

– HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Devices
– HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\PrinterPorts
– HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
– HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\Devices

Anschließend musste eine noch eine Abmeldung des Users vom Terminalserver erfolgen.
Nach erneuter Anmeldung war nun kein freigegebener Drucker mehr installiert, da alle korrekt aus der Registry gelöscht worden waren.
Zuletzt konnten die freigegebeben Drucker erneut installiert und dieses Mal auch nach Ab- und Wiederanmeldung des Benutzers genutzt werden. Hurra.

Vor einiger Zeit fiel mir auf, dass sich die AMD Turion CPU meines baremetal Domainencontroller laut Taskmanager nicht mehr runtertaktete. Ich konnte mich jedoch defintiv daran erinnern, dass sie das in der Vergangenheit getan hatte. In der Zwischenzeit hatte ich eigentlich „nur“ Veeam und die Hyper-V-Rolle installiert, also musste es irgendwie damit zusammenhängen.

Auch mein Hyper-V-Host zeigte dieses Phänomen und so langsam glaubte ich daran, dass das CPU-Throttling durch die Installation der Hyper-V-Rolle deaktiviert wurde und bekam ob des astronomischen Stromverbrauchs ein klitzekleines bisschen Panik.

Beruhigen konnte mich erst CPU-Z, was mir dann den korrekten CPU-Takt anzeigte:

Also alles halb so wild. Es handelt sich offenbar um einen Bug in Server 2012 R2 in Kombination mit der Hyper-V-Rolle. Mal sehen, was Server 2016 in den nächsten Monaten mit sich bringt.

Um einen Kunden vor drive-by Crypto-Locker-Infektionen (wie hier bei heise.de beschrieben) zu schützen, beschäftigte ich mich neulich mit dem integrierten AdBlocker im Internet Explorer ab Version 9.

Der IE bringt dafür die Funktion des Tracking-Schutzes im Menü unter Extras -> Tracking-Schutz mit. Dabei handelt es sich um einen (sehr simplen) AdBlocker, der anhand von TPLs (Tracking Protection List, die eigentlich nur mit dem IE kompatible AdBlock Listen sind) Werbung blockt, wie es auch Add-ons wie AdBlock Plus oder uBlock tun.

Microsoft selbst bietet unter https://www.microsoft.com/de-de/iegallery verschiedene Listen an, die über einen simplen Klick installiert und aktiviert werden können. Interessant war jetzt die Anforderung, dass ganze unternehmensweit auszurollen. Folgende Registry-Schlüssel müssen dafür unter HKCU erstellt werden, damit das ganze funktioniert:

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE
– Name: Filtering Mode
– Type: REG_DWORD
– Value: 0

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: Enabled
– Type: REG_DWORD
– Value: 1

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: Name
– Type: REG_SZ
– Value: EasyList Germany und EasyList

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: Path
– Type: REG_SZ
– Value: %AppDataDir%\Local\Microsoft\Internet Explorer\Tracking Protection\{8C91C7B9-F137-456B-B662-E789A9E86528}.tpl

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: Url
– Type: REG_SZ
– Value: http://easylist-msie.adblockplus.org/easylistgermany+easylist.tpl

– HKCU\SOFTWARE\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{8C91C7B9-F137-456B-B662-E789A9E86528}
– Name: TTL
– Type: REG_DWORD
– Value: 2

Wichtig ist dabei, dass andere Filterlisten andere URLs und IDs haben, über die sie in der Registry gesteuert werden können.
In meinem Beispiel wird die Easylist + Easylist Germany alle 2 Tage von adblockplus.org heruntergeladen und in AppData des Users unter der listeneigenen ID gespeichert.

Das ganze sollte dann in der GPO ungefähr so aussehen:

Es gibt (wie es leider fast zu erwarten war) keinerlei weitere Konfigurationsmöglichkeit des Tracking-Schutzes. Keine Ausnahmen, kein manuelles Hinzufügen. Einzig kann der komplette Adblocker über das Menü aktiviert bzw. deaktiviert werden.

Wie bereits hier angekündigt, wollte ich noch erläutern, wie ich auf meinem Bare Metal DC das Problem mit der fehlenden SYSVOL bzw. NETLOGON Freigabe löste.

In diesem KB-Eintrag erläutert Microsoft, was zu tun ist, damit wenigstens das SYSVOL freigeben wird:

1. Regedit nach HKLM\System\CurrentControlSet\Services\Netlogon\Parameters

2. Den Parameter SysvolReady einmal auf 0 und kurze Zeit später wieder auf 1 setzen.

3. Freuen, dass das SYSVOL wieder da ist.

Leider war das SYSVOL zwar nun da, jedoch fluchte das Ereignisprotokoll über Event-ID 5706 vom Netlogon:

Nachdem ich manuell die Ordner „Scripts“ und „Policies“ unterhalb von „C:\Windows\Sysvol\domänen-fqdn“ freigegeben und den Netlogon-Dienst neustartete, melde nun auch Dcdiag keine Probleme mehr.

Yay.

Versucht man auf eine VHD(X), welche auf einem ReFS-Volume liegt (auf einem solchen aber nicht erstellt wurde), mit Hyper-V schreibend zuzugreifen, so bekommt man folgende Fehlermeldung:

Im Ereignisprotokoll wird Event-ID 12140 des Hyper-V SynthStor protokolliert, die besagt, dass auf ReFS das Integritätsbit für virtuelle Festplatten nicht gesetzt sein darf.

Die Meldung erscheint, da ReFS endlich Mechanismen gegen Bit Rot (Silent Data Corruption oder Bitfäule) mitbringt, sodass nun auch große RAID-Volumes sicherer genutzt werden können. Alternative Dateisysteme wären hier ZFS bzw. BtrFS unter Linux. Zum Hintergrund zu Bit Rot sei der Wikipedia-Artikel empfohlen, der die ganze Thematik und die Herkunft des Bit Rots erläutert.

Leider kann Hyper-V mit so gekennzeichneten Dateien nichts anfangen, sodass kein Zugriff auf die Datei möglich ist.

Das Integritätsbit einer Datei kann jedoch folgendermaßen deaktiviert werden:

Get-Item ‚Pfad-zur-Datei\Datei.Endung‘ | Set-FileIntegrity -Enable $False

In meinem Homelab bemerkte ich nach Inbetriebnahme des Bare Metal Domaincontrollers, dass die Synchronisation der SYSVOL bzw. NETLOGON Shares über DFS-R wohl noch nie funktioniert hat.

Da natürlich nichts im Ereignisprotokoll geloggt wurde, recherchierte ich bestimmt vier Stunden, bis ich diesen Blogpost von iSiek fand, der eine au­to­ri­ta­tive Wiederherstellung der über DFS-R synchronisierten SYSVOL bzw. NETLOGON Freigaben beschreibt. Eine Wiederherstellung über Burflags, wie noch bei Server 2003, ist ab Server 2008 dank DFS-R nicht mehr möglich.

Hier noch einmal kurz die Vorgehensweise. Ich empfehle jedoch sehr sehr genau den Blogpost von iSiek zu lesen, da es auch bei mir erst nach dem dritten mal funktionierte.

1. Auf dem PDC-Emulator, der mit „net dom query fsmo“ ermittelt werden kann, wird zunächst der DFS-R-Dienst angehalten.

2. Auf dem PDC-Emulator werden per ADSI-Edit die Einträge des PDC-Emulators „msDFSR-Enabled = FALSE“ und „msDFSR-Options = 1“ gesetzt.

3. Auf allen anderen DCs wird jetzt per ADSI-Edit nur der Eintrag „msDFSR-Enabled = FALSE“ des jeweiligen DCs geändert und erst anschließend der DFS-R-Dienst beendet.

4. Auf dem PDC-Emulator kann nun der DFS-R-Dienst erneut gestartet werden. Event-ID 4114 der DFS-Replikation sollte protokolliert werden, die aussagt, dass die Synchronisation von C:\Windows\Sysvol\domain durch das zuvor gesetzte msDFSR-Enabled = FALSE deaktiviert wurde.

5. Durch ein erneutes Umstellen von „msDFSR-Enabled = TRUE“ auf dem PDC wird nun das Verzeichnnis wieder durch DFS-R synchronisiert.

6. Diese Änderung muss nun als erstes auf dem PDC und anschließend auf allen anderen DCs mit dem Befehl „repadmin /syncall /AdP“ ins AD synchronisiert werden.

7. Durch Eingabe von „dfsrdiag PollAD“ auf dem PDC zwingt man nun das DFS-R die zuvor im AD replizierten Änderungen zu akzeptieren. Unter Umständen müssen die DFS Management Tools noch als Feature der Dateidienste hinzugefügt werden. In der Ereignisanzeige vom DFS-R sollte Event-ID 4602 protokolliert werden, die besagt, dass die au­to­ri­ta­tive SYSVOL Wiederherstellung initiiert wurde.

8. Bevor nun weitere Arbeiten auf den übrigens DCs gemacht werden, sollte dort zunächst das SYSVOL gesichert und anschließend geleert werden, um eventuelle Konflikte mit unterschiedlichen Dateiversionen zu vermeiden. Anschließend kann DFS-R auf den übrigen DCs wieder gestartet werden. Event-ID 4114 sollte erneut protokolliert werden, die wie zuvor nun meldet, dass die Replikation von C:\Windows\Sysvol\domain deaktiviert wurde.

9. Auf allen übrigen DCs kann nun bei gestartetem DFS-R-Dienst per ADSI-Edit „msDFSR-Enabled = TRUE“ erneut gesetzt werden. Durch „dfsrdiag PollAD“ wird nun erneut DFS-R gezwungen, die unter Punkt 6 ins AD replizierten Änderungen zu akzeptieren.

Nach kurzer Zeit sollte nun in allen SYSVOL Freigaben nun wieder der gleiche Inhalt vorhanden sein. Mir hat es jedenfalls geholfen.

Als nächstes berichte ich darüber, wie ich auf dem Bare Metal Domaincontroller das SYSVOL und NETLOGON Verzeichnis manuell freigab, da dieses nicht automatisch bei Hochstufen als DC funktionierte. Ja, ich hatte ein sehr arbeitsreiches Wochenende.